There is a new module under development that allows you to pipe VGA (640x480) video from the hires camera at 30fps via MPA so that it can be streamed with voxl-streamer using RTSP while simultaneously saving 4k HD video at 30fps encoded as h265 into a file, preferably on the SD card on voxl. This module is now available in beta and will be officially released in upcoming releases of the voxl SDK for voxl, rb5-flight, and voxl 2. The beta package is available using wget https://storage.googleapis.com/modalai_public/modal_packages/archive/voxl-hires-server_0.0.1.ipk. It is meant for use on voxl only and is compatible with voxl platform release 3-3-0-0.5.0-a. In order to use it with voxl-camera-server, reconfigure voxl-camera-server to not use the hires camera. For example, call voxl-configure-cameras and choose option 1 Tracking + Stereo to allow voxl-camera-server to access the tracking and stereo cameras but not the hires camera. Then you can use voxl-hires-server for the hires camera. Use voxl-hires-server -h to see the available options. More documentation will be available upon official release of this new package.

@kitkatSG Yes, we have enabled most resolutions in that sensor now and are preparing a release to address this issue.

@JoeC Seems like it is an SD card issue. I was able to recreate the problem when using a SanDisk Extreme 32GB card. But when using a SanDisk Ultra 16GB card everything works fine.

@Morten-Nissov 1MHz is a supported clock rate for i2c on the DSP based on what I can see in the code. But we have never tried running a device at 1MHz on i2c so it's tough to say why it wouldn't be working for you.

@ceu-gomez PX4 on VOXL2 is composed of two separate applications. One is on the applications processor (running Ubuntu) and the other is on the DSP (running Qurt RTOS). They use the muorb module to communicate topic data back and forth. The spare i2c on J19 is mapped to the DSP, not the applications processor, so Ubuntu has no access to it. To gain access to it on Ubuntu side with PX4 running would require some new code. This is something that is on our development roadmap but no definitive answer on when we will be able to get to it.

@smilon Yes, in order to build you can follow the README in the voxl-px4 project. The Docker provides the build environment so you need to use it.

@Sam-Kiley When on public 3G / 4G / 5G networks we use a VPN and assign fixed addresses to each system component with our VPN configuration. You should be able to do a similar thing with your 5G private network. Does your private network have a connection to the Internet or is it self contained? I don't know anything about 5G private networks but I'd be surprised if it didn't have a way to assign the same IP address to a device on the network so that you effectively have a static IP. Earlier versions of the RB5 SDK set the MAV_BROADCAST parameter in PX4 to 1 and PX4 would then use the network broadcast address to send out it's initial messages. Any QGC instance running on the network will receive that broadcast and respond so that you get automatic connection. However, this can be problematic if there are more than one instance of QGC running since you may connect to an instance that you don't want. Also, some wireless networks do not support broadcast.

@Curious By default the voxl-streamer application assumes a wireless link. But you can change the configuration as needed. See https://docs.modalai.com/voxl-streamer/

An update to UVC camera support has been started. It will increase number of supported cameras by allowing MJPEG and will increase number of supported viewers including latest QGroundControl versions. Target availability is mid-December.

@Zachary-Lowell-0 The updated Debian package can be found here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mpa-to-ros2_0.0.3-202406240850_arm64.deb

@valvarez Some examples include: https://www.modalai.com/collections/expansion-board/products/m0151?variant=47083939791152 and https://www.modalai.com/products/m0141?variant=46829445513520

@valvarez No, you cannot connect two separate devices to the same UART.

@JP-Drone I understand the request. Yes, it seems like that would be a nice feature to support in voxl-mavcam-manager. We don't currently have time to develop this new feature but we will add it to our list of desired updates and hope to be able to get to it at some point. If you are able to do this update on your own please send us a merge request so that we can update the code for everyone to use.

@valvarez That is the IO board. Yes, that's part of what I was talking about. Perhaps I don't quite understand your question. I would suggest creating a wiring diagram of your proposed system and including that in this thread. We can take a look and see if looks feasible. What you are proposing is a customization to the platform that we have never attempted so the best we can do is to take a look at your proposed design and provide some feedback on it.

@Jetson-Nano Depends on what you mean by RC. If you are using a dedicated RC transmitter / receiver to control the drone then it is a separate thing. If you use a joystick with your ground control software then "RC" (or manual control) data is sent via Mavlink messages over the telemetry link.

@Jetson-Nano Here's some example code: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-vision-hub/-/blob/master/src/autopilot_monitor.c?ref_type=heads#L514

@valvarez The IO board was created to allow builders of custom drones who need to use PWM ESCs and / or SBUS RC units to be able to connect to a VOXL 2 which has neither PWM nor the ability to configure UARTs for SBUS. So, for example, if you wanted to use PWM ESCs instead of our UART based ESC then you would attach the IO board to the UART that normally is connected to the ESC. Or, for RC, you would connect (as in that diagram) to the UART that normally is connected to an RC receiver. If you still want to use our ESC, the current RC and GPS then you don't have a spare UART for the IO board. One possible way to do this would be to move the GPS from it's current connector to a UART on the applications processor side and then attach the IO board to the UART that has the GPS now. This would require an add-on board that exposes such a UART.

@bkim1301 I would start by connecting the VOXL 2 UART 7 to a PC with a serial to USB cable. Make sure you can communicate back and forth using that setup and then do the same with the Teensy before connecting the Teensy and the VOXL 2 together. It's often very helpful to use an oscilloscope on the rx / tx lines to verify that there is actually data flowing.

@Jetson-Nano I think what you are trying to do is entirely possible. But it isn't anything we have ever tried. So I'm just throwing out some ideas that could maybe help you develop this. Or maybe you have some better ideas. One possibility, that I was referring to above, is to create a new program running on the Linux applications processor. It would have to use the libqrb5165-io library to get access to the UART on J19 that is mapped to the SLPI DSP. Another idea is to actually run PX4 on VOXL 2 and either use px4-listener to monitor the input_rc topic or monitor the RC_CHANNELS Mavlink message via voxl-mavlink-server or even voxl-vision-hub and use that to create an RC_CHANNELS_OVERRIDE Mavlink message to send to the external FC. I'm just brainstorming here and can't really provide much more support than offering some high level ideas.

@Jetson-Nano Instead of listening to the input_rc topic with the listener function you can now monitor the RC_CHANNELS Mavlink message from the FC v2.