@Nikos-Mavr Can you reboot, try the command again, and send the entire output of PX4 so that I can see the entire startup process?

@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

@restore There are a few examples of code that listens for Mavlink messages in our SDK. For example, in voxl-mpa-tools, take a look at the source code for voxl-inspect-mavlink.c. https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-mpa-tools/-/blob/master/tools/voxl-inspect-mavlink.c?ref_type=heads

Probably would be a good idea to run voxl-inspect-mavlink on the mavlink_onboard and mavlink_to_gcs pipes to see which one has the desired Mavlink message in it. Then create your own application that listens for the Mavlink message on that pipe.

@Alex-Kushleyev The Alfa Network AWU2036

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

@Dan-Jennings I'd try our voxl-inspect-mavlink application. Check voxl-inspect-mavlink mavlink_onboard and voxl-inspect-mavlink mavlink_to_gcs and see if battery_status appears at all. I just loaded voxl-ardupilot_ArduCopter_4.8.0-94b27fd3_arm64.deb on my voxl2 with our standard APM and I see battery status in QGroundControl and with voxl-inspect-mavlink mavlink_to_gcs. Also, can you upgrade to VOXL SDK 1.6.x?

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

@Piyush-Singh , can you please provide more details

how exactly all cameras are connected to VOXL2 mini (including interposers, flexes), etc. A diagram would help a lot which kernel variant are you running on your voxl2 mini (2.0.0 or 2.0.2).

Are all the other cameras working if you disable the TOF sensor in the camera server config?

Alex

@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 Thank you for the hint. We have fixed the issue by changing the resolution to 2704x1540 in the voxl-camera-server.conf. Now, the actual DFOV is 150°.

Hi @Vinny

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

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