@Rowan-Dempster ,

We have not tried this recently, but it should work. Here are some tips:

Use IMX412 camera (M0161 or similar) because it has great image quality and the fastest readout speed of all of our cameras (IMX214 is not recommended for this, it is an old and "slow" camera sensor) faster readout = less rolling shutter skew use the latest camera drivers, which max out the camera operating speed in all modes : https://storage.googleapis.com/modalai_public/temp/imx412_test_bins/20250919/imx412_fpv_eis_20250919_drivers.zip The readout times are documented here for all modes : https://docs.modalai.com/camera-video/low-latency-video-streaming/#imx412-operating-modes for example 1996x1520 (2x2 binned) mode has about 5.5ms readout time, which is pretty short QVIO (mvVISLAM.h) has a parameter "readout time", which suggests that it supports rolling shutter. I have not tried it myself, but i heard that it does work. mvVISLAM_Initialize(...float32_t readoutTime ..) @param readoutTime Frame readout time (seconds). n times row readout time. Set to 0 for global shutter camera. Frame readout time should be (close to) but smaller than the rolling shutter camera frame period.

Here is where this param is currently set to 0 in voxl-qvio-server : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-qvio-server/-/blob/master/server/main.cpp?ref_type=heads#L371

in order to correctly use the readout time, you have to ensure that the camera pipeline indeed selects the correct camera mode (for which there is the corresponding readout time) : https://docs.modalai.com/camera-video/low-latency-video-streaming/#how-to-confirm-which-camera-resolution-was-selected-by-the-pipeline also, readout time is printed out by voxl-camera-server when you run it in -d mode (readout time in nanoseconds here): VERBOSE: Received metadata for frame 86 from camera imx412 VERBOSE: Timestamp: 69237313613 VERBOSE: Gain: 1575 VERBOSE: Exposure: 22769384 VERBOSE: Readout Time: 16328284 keep the exposure low to avoid motion blur (IMX412 has quite a high analog gain, up to 22x and 16x digital gain). If you want to prioritize gain vs exposure, would need to tweak the auto exposure params in camera server (when you get to that point, i can help you).. it would be interesting to compare performance against QVIO with AR0144 - that would probably require collecting images from AR0144 and IMX412 (side by side) + IMU data and running QVIO offline with each camera.

Good luck if you try it! let me know if you have any other questions. Please keep in mind that QVIO is based on a closed-source library from Qualcomm and our support of QVIO is limited.

Alex

@mark , thank you for confirming. The error is the same that i am observing. It should not matter whether it is 8 or 12 bit image (in your case it is 8 bit).

In my case the issue happens on M0154 board. I don't think M0054 vs M0154 makes any difference.

Just to clarify what is actually happening..

The issue starts with some CRC errors (interference between multiple cameras, it seems). In my case, the rate of CRC errors depends on the position of the ucoax cables. (you can also watch these CRC errors and move the coax cables for the second tracking camera).

If the error occurs at a critical point (such as beginning of the frame), the camera pipeline reports a critical problem and should produce an error in the camera pipeline.

The correct behavior should be that the problematic camera stops streaming and in latest SDK, it will actually be restarted and stream will recover. However, the camera is never stopped, instead it reports a duplicate image from the other tracking camera.

We are investigating the root cause, as it is somewhere low level in the camera stack (not in voxl-camera-server).

Alex

Tagging people who might have the most context here: @Cliff-Wong @Clifford-Wong @zauberflote1, any comments / studies on comparative performance, as well tuning routines to get the best performance out of a running OpenVINS on a new airframe?

Perusing posts about OpenVINS from the past year: https://forum.modalai.com/search?matchWords=all&in=titles&showAs=posts&replies=&repliesFilter=atleast&timeFilter=newer&timeRange=&sortBy=topic.lastposttime&sortDirection=desc&term=openvins I found some information about drifting and how to address it. But I'm not sure if that's the most up to date advice, it looks like the module is still under active development. Is the module in a place where it is ready for general customer use? The starling2 drones that ship with SDK1.6 use OpenVINs for localization, not QVIO, correct?

Thank you for any input!

@Zachary-Lowell-0

Thank you for the feedback! This was very helpful

@Eric-Katzfey When I swapped in the power module board, I did not update voxl-px4.conf. I tried changing POWER_MANAGER to VOXLPM and rebooted but still did not see anything publishing on px4-listener battery status. I set it back to NONE (since I think the ESC should still be able to read power data because I have battery->power module board->ESC input). Below is the output of the commands you requested. The log that had battery_status did come from this same drone. It had been working, but then stopped, and I'm pretty sure I didn't change anything. Could the VOXL 2 have a hardware issue?

Command outputs:
https://pastebin.com/4FCVT6Vw

@tom Thank you. I will submit an RMA request.

@clange Yes, definitely. All the support to build a Debian package for installation is in https://github.com/ArduPilot/ardupilot/tree/master/libraries/AP_HAL_QURT/packaging

@John-Nomikos Hi, Can you please explain how you solved this? I am facing same problem where my camera is connected via USB to ethenret convertor with Microhard add-on board and my host machine is unable to ping my camera but can ping voxl2.

@tom Thank you for your answer!

Unfortunately the overlay does not appear, even when the drone is armed. We are using Starling 2 drones with SDK 1.6.2.
Also in the voxl-open-vins-server.conf we can't find a setting for something related to the overlay.

Do you have any ideas what we can try to see the ov_overlay again?

Thank you in advance!

I fix this issue.
switch the Pin1 & Pin4 of MCBL-00010 cable is OK

@Alex-Kushleyev Hi Alex, I appreciate you looking into our use case for us (as always!). Please let me know if I can help by providing more details regarding the structure of our clients that are consuming the camera pipes. If there is a detail Cleo can't share publicly on the forum I can always email you as well or hop on a quick call to elaborate.

Understood about the misp pipes, that expensive read access would explain both point #1 and the strange part of point #2 in my original post.

We at Cleo will be monitoring this closely, since CPU usage regressions is pretty much the only gating item for us upgrading our robotic perception stack to SDK1.6. The misp_norm pipes are a great benefit to that perception stack and we'd of course love to take advantage of them as soon as possible. Thus we are definitely open to trying out zero-copy client approaches for keeping CPU usage down, or any other optimizations you could share examples of for us to try out on our use case.

Hello @Teon,

This is more of a general question, not specifically related to VOXL2. However, here is some information that you might find helpful.

Base station

Raspberry Pi ZED-F9P receiver with dual band helical antenna, connected to RPI via USB configure ZED-F9P to be a in base station mode (will require data collection for localizing the base station precisely). Check Ublox docs configure ZED-F9P to output RTCM3 corrections over usb to RPI run NTRIP caster software (you will need to find one..) which will connect to USB port and serve the RTCM3 data to the clients via NTRIP protocol
-- this would require an NTRIP client on the client side (alternatively) publish the RTCM data via Mavlink directly to the drone (MAVSDK). would need a client that would connect to Ublox via USB and send out mavlink messages to your drone
-- https://mavsdk.mavlink.io/main/en/cpp/api_reference/classmavsdk_1_1_rtk.html
-- https://github.com/mavlink/MAVSDK/issues/2352

Rover (VOXL2)

wifi connection to the base station server based, on the following docs (https://docs.px4.io/main/en/advanced/rtk_gps) the PX4 gps driver will automatically forward RTCM packets to the attached GPS receiver. The Px4 GPS driver will need to receive the Mavlink GPS_RTCM_DATA packet. if you use the NTRIP caster in the step above, you could use a NTRIP client and have the client publish the mavlink GPS_RTCM_DATA message locally on VOXL2 .

I will ask around to see if we have a better documentation for this..

Alex

@Seungjae-Baek , the resolution of the camera should depend on the use case. However, it is also important to keep in mind what exactly you are doing with the images coming from the hires cameras. For example, if you set the resolution to 4K and you try to view those uncompressed images using voxl-portal, this process will be very taxing on the CPU for the following reason: when you view uncompressed images in voxl-portal, these images are encoded with a software JPG encoder and then sent from voxl2 to your browser. This process is very cpu-heavy. On the contrary, if you use h264 / h265 stream, it should be perfectly fine to encode 4K30 video to disk or even stream, since H264 / H265 encoding is done by a hardware encoder.

voxl-portal, actually does support showing h264 (but not h265) 30FPS streams, so that would be a lot more efficient for the CPU, since there would be no jpg encoding. Otherwise, if you are using raw frames (not _encoded) in voxl-portal , please keep in mind that you will always have a lot of cpu overhead. voxl-portal is designed for debugging / development purposes, so it's not necessarily the most efficient solution for video streaming. For real video streaming use cases, you would use h264 or h265 encoding and save to disk on voxl2 + stream the encoded video for remote viewing. You could encode the same camera source with two different resolutions / codecs / bitrates.

If you need help setting up a specific use case, please provide some details and I can help you further.

Alex

@cbay ,

We support any camera that is compatible with UVC (plugged into a usb port). Please look into voxl-uvc-server. https://docs.modalai.com/voxl-uvc-server/

Regarding NIR, have you considered using a regular camera (most cameras are sensitive to NIR) and install a lens with a NIR pass filter (if you dont want to see visible light)? Then you could use one of our hi-res cameras like IMX412 or IMX664. I can get you spectral response plot of those sensors if you need.

Alex

@Aaky , 5A hover / 12A max (per motor) should be easy for M0129 in terms of current capacity. Just make sure you have some cooling. Sufficient cooling should be determined by testing and monitoring ESC temps, which are available in the ESC telemetry and PX4.

Alex