ModalAI Forum

Great to hear @mikhail-mayers . I tested the module you sent back and it baffles me... must be some internal silicon damage to the IC since it had all in-spec inputs, and no faults on any outputs, but it was just not turning on... so, it is now one of my Mechanical Samples Glad we could get that resolved for you and thanks for your patience.

Hi @muqing-cao Correct, M0213 does not have a USB hub on it like M0090.

Hi @Eric-Katzfey Thank you for your help! I got it to work on J19 through PX4.

@NikosMav Yes, things will get hotter when running QVIO. But once you arm and start the props everything will cool down. When reflashing the SDK I would grab one of the official releases from our downloads page and not a nightly.

And the latest build of our fork with this fix is here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-px4_1.14.0-2.0.146-202607161052_arm64.deb

the hexagon sdk has been unlocked. It is under the miscellaneous folder: https://modalai.filecloudonline.com

DSHOT Telemetry seems like the only option for the MadMotor ESC linked in the original post so that would be our requirement.

Hi Alex, Thank you very much for your detailed explanation. It was very helpful, and I really appreciate you taking the time to investigate this. We understand that the OV7251 camera has reached EOL, and we are also aware of the AR0144 solution. We are planning to evaluate the AR0144 cameras in the future. However, for our current project, we need to reproduce our existing system using the hardware that we already have. Therefore, our immediate goal is to implement the following configuration: * 4 × OV7251 cameras * 1 × Boson+ connected through the M0181 VOXL2 MIPI Boson Adapter on J8 This configuration is very important for our current project, so we would like to continue with the OV7251 cameras for now. Once you verify the kernel/device tree changes, do you expect 4 independent OV7251 cameras plus one Boson (via M0181 on J8) to run simultaneously under voxl-camera-server? Thank you again for your support. We really appreciate your help, and we look forward to hearing your results. Best regards,

@vinny @alex-kushleyev @tom Thanks for the input guys! Happy to report it is all working as intended. Much appreciated.

Hello @Alex-Kushleyev , This is exactly what we needed ... thank you for turning the combined flip + GNSS-fix driver around so fast! Confirming our plan against your docs: We're on the encoded (ISP) path ... large_encoded for the pilot's low-latency FPV feed, not MISP ... so the ISP should pull the reversed bayer from the flip sensormodule and debayer correctly (no R/B swap). We'll run the version-agnostic combo: the flip sensormodule + en_rotate = true, plus maxRAWSizes=20 in camxoverridesettings.txt. Bit rate: going with 2088 Mbps. Our GNSS is a Septentrio mosaic dual-antenna running moving-baseline heading, so GPS L1 integrity is critical for us ... your analysis showing 2088 sitting ~10 MHz off L1 center with only a 1–2 dB drop is exactly the margin we need. We'll keep our FPV mode clear of the three forced-2200 modes (staying 1080p ≤120 fps). We'll validate by logging the Septentrio C/N0 and satellite count with the camera streaming vs. off, in representative daylight (noting your point that under-exposed frames worsen the interference). One quick check: for our single hires IMX412 on the M0173, is the default i2c 0x34 the right choice, or is there a scenario where we'd want the 0x20 variant? I'll report back the before/after GNSS numbers once we've tested ... happy to share the data if it's useful. Thanks again, John

@RoyAzriel 1.6.4 release is tested on Starling 2 now, go ahead and use that from the link I emailed you.

You are welcome! By the way the Starling 2 Max plastics kit (linked above) contains both types of front camera mounts (with and without the TOF sensor).

Hey @Moderator , I had few more questions regarding the same. Does the 3D map generated have the same quality has PMD TOF? Can the 3D map be used for P-to-P navigation from voxl-Portal? Can the TOF data be used for collision prevention? Can multiple maps be used together? Does Multiple TOF give collision prevention in multi direction? If you could provide a image of map generated by the new TOF, it would be great and help us to make a decision for our architecture. Thank you for your help and time, looking forward to your response.

I am able to download the log from the site along with all of the parameter settings. The accelerometer bias is clear in the log. Can you try to recalibrate the IMU with air flow on the unit to keep it from getting too hot? The yaw estimate error is not active during the log. However, to remove the interaction with VIO, try setting EKF2_EV_CTRL to 0 and see if that clears that occasional error. If it does then that helps narrow the issue to the VIO input versus the magnetometer / IMU input. Is the red light on the GPS unit or the RC receiver?

MCBL-00084-180 (26-pin Micro-Coax Cable): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MSU-M0161 (EO Camera): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. (The Sony IMX412 image sensor guarantees image performance from −10°C to +60°C.) VOXL 2 / MDK-M0154-1-00 (Flight Computer): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MDK-M0155-1-00 (Image Sensor Micro-Coax Adapter): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C. MDK-M0062-3-00 (VOXL2 Ethernet & USB Hub Adapter): Operating temperature 0°C to +70°C; Storage temperature 0°C to +70°C.

Yes, use the normal RC port. But cannot use an SBUS receiver with that port.

We do not support DSHOT when using Voxl2 + IO Expander board. However, OneShot125 is supported (though you would need to re-build voxl-px4 pakage and change the following scale factor : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/voxl2_io/voxl2_io.hpp#L133) -- set MIXER_OUTPUT_TO_CMD_SCALE = 125 instead of 1000. This would reduce the actuator latency by 1-2ms (as long as the ESC supports OneShot125).

Sorry to hear that. https://www.modalai.com/pages/rma You can provide a link to this post when you submit it.

Hi ZBFT, We have done the steps you recomended both with 1.6.4 alpha2 version in with 1.6.6 version. canceling qvio, making sure only one open-vins service regarding vio. recalibrating imu. The drone is still loosing horizontal pos at the same manuver( sliding to the left when there is a wall in front) I want to proved you with some facts. we reverted back to a code we know worked well before and suddenly we experiance this problem. ( made us syspect somthing changed in hw ( some kind of movment of camera or lense because of a crash) the qvio with 1.6.4 alpha2 version with qvio was working perfectly with this version of ours and now it not failing in the same manuver again and again. we double check all px4 params against a golden copy. The other possiblity that it is something wrong in our appication is also a possiblity( we have two drone acting the same) can you guide us what other information we can log in order to trace why vio pos suddenly jumps to a far horizontal position. what can explain such a behavior ? BR, Roy

Hello @jameskuesel , Sorry for the confusion about the lens change. Please see the details below. The original lens in the IMX412 modules (M0107 and M0161) had manufacturing issues where the internal components of the lenses were loose and vibrating in flight, causing shaky video. Due to quality / vibration issues of the original lens (part number M10000580) shipping with IMX412 (M0107 and M0161) modules, the default lens was changed to M10001028 (late 2025). However the new lens does have much narrower FOV. When purchasing the standalone camera, you have a choice of lens: M0161 with old lens (wide) : MDK-M0161-1-07 (3.1mm EFFL, M10000580 lens) M0161 with new lens (narrow) : MDK-M0161-1-08 (3.24 EFFL, M10001028 lens) It seems that there maybe some discrepancy in the manufacturer stated EFFL for the new lens (3.24 vs original 3.1) because the actual FOV change is more significant than the change in the effective focal length would result in. We are looking into this. Starling 2 and Starling 2 Max drones are currently shipping with the new lens (narrow FOV). We do currently have stock of the old (wide) lenses that should have no issues (according to the manufacturer), however we cannot provide any guarantees for this lens due to past history of issues. If you would like to update your drone / camera with the original wide lens, please contact us and we will make it available for you to purchase (lens part number M10000580). Alex