@Vinny yes I removed the level shifter for that setup and yes the voltage drops to 3s for the highlighted area.

@Myles-Levine , if you are masking out 90% of down-facing camera, then it is probably useless any movement of the features will get it out of the unmasked region very easily and feature will be dropped.. It may hurt VIO as there may be features going in and out, only trackable for a few frames (just adds to the complexity).

You should try to move the down-facing camera to free up it's FOV or even have it facing slightly angled to the back of the drone..

Alex

Hi @austin-c ,

I ran some tests with Tmotor MN4006-23 380kV and 15-inch MS1503 propeller, using M0138 ESC. Tests were done with a battery and a power supply. Please see results below.

the colors may vary from plot to plot, but the one with slower deceleration is "regen off" 🙂 did not run large rpm steps on power supply because the power supply was already current limited regen peaks were 31V (pwm step) and 33V (rpm step) for the power supply test motor acceleration is almost identical for regen on/off tests very large difference in motor deceleration, especially for the large high-to-low rpm transitions also note that the power supply tests result in slower deceleration even with regen on (because the power supply cannot sink the current) TVS diode did not blow out in this test, because the spikes were short and only a few at a time

Please note that, in theory, it is possible to decelerate the motor faster without regenerative braking (by applying more power, but out of phase), however we do not have this implemented.

If the motor deceleration is slowed down due to lack of regenerative braking, the attitude control will be affected because the motor response is highly asymmetric for acceleration vs deceleration. Overall, this will result in effectively reducing the average responsiveness of the motor, so you would need to decrease control gains and probably will not be able to handle large disturbances very well and cause oscillations if not tuned properly.

Please review the plots (which are not surprising), and we can discuss further..

Alex

6S battery, Power step test:
75e2acb0-7505-4f57-9ad0-607768c923cf-image.png

6S battery, RPM small step test
e5e02d3a-ac63-4fbf-b8e6-b64d4b33f983-image.png

6S battery, RPM large step test
7b2f7b28-6825-4498-908e-68353de9fa79-image.png

11A Power Supply, Power step test:
d6888452-1155-4567-8309-a994d7d717ff-image.png

11A Power Supply, RPM small step test
d88b5433-2756-42c7-9de6-804bbef8b814-image.png

@DronAlan Hi there,

Seeing the opposite direction that looks like a 100% 180 rotation is typically a sign of a reset while powering up: incorrectly detects the gravity vector. This is a common anomaly with qvio. I suggest at power up, immediately put the drone on the ground and try not to move the drone until takeoff. Try this and see if you get consistency. QVIO is sensitive to resets prior takeoff. You can edit the following in /etc/modalai/voxl-vision-hub.conf:

"en_reset_vio_if_initialized_inverted": false,

if your use case doesn't allow this type of procedure, you can ssh onto the drone and force reset before every takeoff by running: systemctl restart voxl-qvio-server.

If you have not edited the extrinsic settings from factory then I would safely assume they are correct, but in case, extrinsics are stored in /etc/modalai/extrinsics.conf where you'd look for the body to imu parameter section (which should be 0,0,0 in starling's case).

Note: these types of anomalies have been corrected in SDK 1.6.x, as the latest SDK now defaults to the new & improved openvins VIO subsystem if you're inclined to upgrade (recommended, though any custom-external apps make need to be recompiled as the MPA API has changed).

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

@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

@groupo and ALL, please see https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

@qubotics-admin First you need to determine the version of PX4 running. With ssh or adb you can run the following at the command line: px4-ver all. You will see PX4 version and Vendor version. So, for example, for px4 version 1.14.0 and vendor version 8.134.3 then you would checkout the tag v1.14.0-8.134.3-dev from the repo to see that commit.

@ndwe Whether you use a VOXL or Jetson as a companion computer shouldn't make any difference unless you want to use the VOXL SDK. The version you run is totally up to you. If our v1.14.0 based version works for you then use it. We do plan to transition to v1.17.x in the near future. I don't think the issues you are seeing are related to something specific in the flight core v2 hardware setup. I would think that if you swapped it out for some other brand you would see the same issue. I would ask on the PX4 forums to see if others have experienced the same issues.

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!

@restore Are there any Mavlink messages coming out of ArduPilot that you could use to know when to take the snapshot? If so, create a new application that listens, via voxl-mavlink-server, to Mavlink and the message(s) you need. Then trigger the snapshot when it's needed. ArduPilot's external interface is Mavlink so it would be good to leverage Mavlink messages for this.

I'm also facing this after updating. Worked on an older version but it is now defaulting to the link local. One thing I noticed is that it doesn't go through the connection process (finding the network, trying password, etc) when using voxl-wifi, just skips all of it:

Configuring station mode...
Detected WiFi interface: wlan0
NetworkManager not installed, using legacy wpa_supplicant/hostapd
stopping softap mode
Enabling station mode on wlan0 (legacy)...
creating wpa_supplicant configuration for station mode
Station mode enabled on wlan0
Station mode configured!

This is using the MCBL-00022 kit on the voxl2.

Downgrading to 1.6.2 and the wifi works but seems a bit bugged because it cant find it at first even though it connects successfully :

Detected WiFi interface: wlan0
Disabling all WiFi modes...
Detected WiFi interface: wlan0
Scanning for network 'xxx'...
Scan succeeded, looking for network 'xxx'
Could not find network 'xxx' in scan results - proceeding anyway
Enabling station mode on wlan0...
creating wpa_supplicant configuration for station mode
Station mode enabled on wlan0
Station mode configured!

@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

Hi @Vinny

Thank you for your reply! That's good news:)
We are looking forward to it!

@Alex-Kushleyev I am using second one i.e. TOF V2 and defined it in custom_camera_config.txt file as given below:
Screenshot from 2026-03-14 10-34-07.png

@colombe-ai , please see https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

@Alex-Kushleyev Thanks Alex, very helpful!

@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.