@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

@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

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

@Alex-Kushleyev It is disappointing to see some tickets—like this one—go unanswered for many weeks and require bumps, especially when this forum is pitched as the de facto way to contact the team. That said, I understand this is probably a stressful situation for the company. I appreciate you chiming in and look forward to hearing from 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!

@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

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

@Moderator The description to MCBL-00128 (https://docs.modalai.com/cable-datasheets/#mcbl-00128), the TOF for the Voxl 2 Mini says it's supported with M0188 (https://docs.modalai.com/M0189/) without specifying any sub P/N (-1 or -2), even in the documentation of the M0188 doesn't say anything about P/N -1 or -2 (https://docs.modalai.com/M0188/).

@Moderator thank you so much, I will go through that now.

@Alex-Kushleyev alright, thanks for the help!

@Moderator Order #7559

And, yes I ordered the configuration without the radio? But I wasn't told that it wouldn't include a GPS module?

@brandon there are likely a number of things going on

If the drone sits idle for a period of time, the sensors heat up (accel and baro). When the props start spinning, the temperature drops causing significant drift. If you let the props spin for 10 or 20s cooling off the board, that can help

I would guess after 30-60s of flight, the altitude stabilizes. That is the temperature of the sensors stabilizng.

The latest SDKs have temperature compensated calibration for IMU and baro. Try calibrating accel and baro and see if that helps.
https://docs.modalai.com/calibrate-baro/
https://docs.modalai.com/calibrate-imu/

The GPS on Starling 2 Max has been tricky. We do have a new GPS on the way that looks promising, and hope to make it available in the next 2mo.

@Matt69 For further clarification, my understanding is that a 169.XXX.XXX.XXX IP address indicates off nominal wifi performance. Please advise.

Thanks!

@colombe-ai There is a long-standing GPS issue ModalAI is working to solve. Depending on when you purchased the drones, there was a disclaimer on the purchase site. You can see in my last commented on post one of the devs promised status in the coming days. There is another post here where people have made mounts/shielding to reduce EMI, which is almost certainly the issue.

Hello @Catalystmachine ,

Sorry for the confusion. We have updated the page to be more clear that Boson is not included, see below: "(No Boson)" was added to the kit description.

The title of the product already states "VOXL 2 MIPI Boson+ Adapters for Thermal IR FPV" as well as the Kit description used to say (Before we added (No Boson)) : "PCB Adapters Only..."

The price of the Boson cameras varies significantly, depending on the specifications. You can contact a distributor to get more details. For example : https://www.oemcameras.com/product-category/thermal-imaging-cameras/thermal-imaging-cores/flir-boson-series-htm/boson-plus/ (you can find more at https://oem.flir.com/contact/find-a-dealer/)

Please note that Boson+ series of the Boson sensor is required for compatibility with VOXL2.

Regarding the pricing of the adapter kit, we do offer discounts in higher volumes, if you are interested, please send us a request: https://www.modalai.com/pages/contact-us

ebff1907-0495-4a65-8f27-2138562022d3-image.png