@Leo-Allesch , if you are talking about VSLAM, which stands for Visual Simultaneous Localization and Mapping, then this is a sub-class of SLAM which uses only cameras (and often IMUs, then it is VISLAM).

VSLAM and VISLAM usually generate and maintain a sparse map of 3D features (points), which is used for self localization.

If you want to be able to detect a target, and you have your 3D pose from VIO (VIO = VISLAM), then you can either triangulate the target location or get it's location from a single frame if you know the size of the target (such as April tag, etc). Then you can transform the coordinate of the tag from the camera frame into your "world" (VIO) coordinates.

The depth sensor would allow you to build a more detailed 3D map / point cloud using the 3D pose output from the VIO algorithm (or just using a depth sensor, which may be more complicated). You can also build a dense 3D map using camera only (and IMU), but that typically requires a lot more computation than using a depth sensor.

You don't necessarily need a depth sensor for identifying the position of a specific target that is easily detected by a camera.

There is a lot of research material you can find on these topics, please look into it deeper and let us know if you have specific questions about using VOXL2 hardware and software.

Alex

@Alex-Kushleyev Found the reason why it was skipping. In /px4-firmware/src/lib/parameters/CMakeLists.txt there is a line that skips all modules that match 'pwm_out'. I was able to disable that for PCA9685. Once I disabled the module.yaml file being skipped it worked. No need for the .c file (which makes sense, that is just the old way to do the .yaml)

Hey @voxltester
It seems there is an issue with how MicroXRCE and the microhard modem interfaces are starting up, I had to edit the service files to get the topics on the VOXL2.
Edit /etc/systemd/system/voxl-microdds-agent.service:

[Unit] Description=voxl-microdds-agent SourcePath=/usr/bin/MicroXRCEAgent After=network.target After=multi-user.target [Service] User=root Type=simple ExecStart=/usr/bin/MicroXRCEAgent udp4 -p 8888 [Install] WantedBy=multi-user.target

Edit /etc/systemd/system/voxl-modem.service:

[Unit] Description=Modem Initialization After=sdsprpcd.service [Service] User=root Type=oneshot ExecStartPre=/bin/sleep 2 ExecStart=/usr/bin/voxl-modem-start RemainAfterExit=yes [Install] WantedBy=multi-user.target

Add export ROS_DOMAIN_ID=0 to your .bashrc
Reboot the VOXL2, and the topics should come up
Thanks

@Alex-Kushleyev appreciate the assist here. I'll follow up next week!

@emarcphera @Eric-Katzfey thank you so much after upgrading to voxl-mainline im getting GPS readingScreenshot from 2026-02-28 01-45-10.png

@Alex-Kushleyev Thank you so much!

I'm a bit preoccupied with a few other projects but hopefully I can take a look by the end of next week and get back to you.

@zauberflote1 I am no longer having this issue. I have been flying with OpenVins for some time, and I was sometimes seeing drift in the vio estimate, and I was wondering what are the best configs to use. for vio_cams.conf and voxl-open-vins-server.conf?

@bendraper
Hello,
I hope this quick clarification helps for warnings:

CMake Policy warnings: OV internally (external dir in the repo) still uses boost and references an older cmake version -- it's a harmless warning for devs (as you are building from scratch)

Yaml-cpp lib warnings: This is a third party dependency that gets compiled from scratch during the make/build process. We use C++ 17 but the library is based on an older C++ version; nevertheless, it compiles fine on C++ 17 with minor warnings. -- it's a harmless warning

TrackOCL warning: ModalFlow is a core library written in C++ 17 that allows function call usage as done in TrackOCL, i.e., the narrowing conversion is harmless in this case.

That being said, we are actively working on the dev branch, so all flight--impacting warnings are hopefully caught early. We currently have no flight-impacting warnings/bugs identified, but if you found one warning/bug that caught your attention, please feel free to share.

All the best,
ZBFT

@Myles-Levine Nevermind, I got it working through the voxl interface instead of Qgroundcontrol. Thank you.

Hi @Alex-Kushleyev, sorry for the late reaction, it took some time before i could update to the new SDK (1.6). the system now works normally with the resolution 2704x1540, and downscaled to 1920x1080 for the MISP pipeline. Thanks for the help!

@Alex-Kushleyev I can't seem to upload pictures of the drone here. Is there somewhere else I can send them?

@Alex-Kushleyev I made the following changes.

Modified the DTS files as stated prior. Flashed the devcfg.mbn file from SDK 1.0.0 I did not need to configure the level shifter actually. The port worked in SPI mode even without running voxl-gpio -w 67 1. Running the command doesn't seem to change anything.

I used Channel 1 on /dev/i2c-0 for the second lepton. I simply wrote TCA9543A_CHANNEL_1_ENABLE to TCA9543A_CONTROL_REGISTER in voxl-lepton-server. I pretty much followed what was described here.

@Cliff-Wong the drone is on SDK 1.5.0, I switched to open vins, and the vio portal reflected the movement, but when i toggled my controller from manual mode to position mode, the drone crashed for the first fight, on the second and third trial the drone kept landing, when i tried the fourth time, the drone finally maintained the height and hovered. Why do I have that unpredictable behavior ? I have attached images of my controller to show the toggling i meant.

Kindly advice.
Thanks. WhatsApp Image 2026-02-13 at 10.53.46 AM.jpeg WhatsApp Image 2026-02-13 at 10.53.46 AM (1).jpeg

@jbhines929 Please fill out the RMA form to get the process started. If it is due to manufactures defect it is covered under warranty and no diagnosis fee will be charged.

@cbay voxl-fpv-px4 is based on voxl-px4 but has some custom tuning code / parameters for our fpv drones that isn't in voxl-px4. So, it's kind of a superset. But there isn't anything related to low level i2c drivers so I have no idea how that could be causing this issue.

@Jetson-Nano , since we currently have no plans to do the MIPI integration of this sensor, you always have the option to use USB connection and voxl-uvc-server to publish images via MPA. You would need to check if the sensor supports the standard UVC interface and try it out...

Alex

@jameskuesel Thanks! Merged

@Eric-Katzfey I tried that parameter, but I did was not able to get the motors to spin in turtle mode.
I tried searching the voxl-px4 repo and could not find how that parameter is used. Do you mind sharing some insight on how the joystick button will trigger turtle mode?
Just to highlight that I am not using a VTX but doodlelabs radio to connect to a handheld gcs/joystick.

@Maxwell-Schaefer Thanks for your reply. Is this step also applicable for the BetaFPV Nano RX? Should this also used ModalAI's firmware repo? Or will this use BetaFPV's? I did look into trying to flash the Nano RX initially, but stopped short of doing it as the physical RX itself did not have a BetaFPV silkscreen on it, so I assumed that it might be using a different firmware from the stock BetaFPV

Are you able to advise on the other queries regarding the new wifi adapter board?

@Moderator

Thanks for the clarification on the ~50 ms glass-to-glass number.

Trying to get a better understanding the performance envelope:
1. Does the 50 ms include RF transport over Doodle, decode, and HDMI output latency, or is that measured only within the VOXL + VRX software stack?
2. Was this measured in point-to-point mode or mesh routing mode?
3. Can you expand on bitrate, resolution, and encoder settings were used (GOP structure, B-frames disabled, UDP vs RTSP)?
4. Is MAVLink or other traffic running on the same link during that measurement?
5. Do you have a latency breakdown per stage (encode / RF / decode / display)?

Appreciate any information you can provide. I just want to make sure I can test and validate this effectively.