tarling - Path planning (blue line) is erratic and drone moves to wrong locations

DronAlan

Hi,

I am having significant issues with the voxl-mapper on a Starling drone. When using the "Plan to a Point" feature in the VOXL Web Portal, the system fails to calculate or execute a reliable path.

Even in a clear environment, after clicking "Plan to a Point", the calculated trajectory (blue line) becomes erratic. Instead of following the direct path, the drone often moves to incorrect locations, diverges from the intended target, or the planning simply fails to produce a viable route.

Hardware Details (Starling):

Flight Controller/Compute: VOXL 2 (MDK-M0054-1)
ToF Sensor: MDK-M0040 (PMD)
Tracking Sensor: ov7251
VIO: voxl-qvio-server (Stable)

Why is the path planner generating such erratic trajectories instead of a direct path to the waypoint? Are there specific tuning parameters for the Starling's ToF setup to make the planner more reliable?

Thanks

Cliff Wong

@DronAlan Hi there,

Can you power up, login and at the ModalAI splash screen is a label: SKU: [some text value] Please post that sku text here to help us diagnosis.

This looks an extrinsics error posting improper orientations of the drone. Please try the following, I expect one of these actions will fail:
a. power cycle and perform a bench test to ensure the extrinsics are proper (forward is X, etc..). If that passes...
b. edit file on drone /etc/modalai/voxl-vision-hub.conf and change back to figure_eight mode. Flight test in figure 8 mode (it should fly a controlled figure 8). If these tests pass, your extrinsics are good and you can switch back to trajectory mode.

If those 2 actions pass, then this leans towards a classic VIO reset error. Rerun your mapping test case, login and run voxl-inspect-qvio -n and it will provide the status if vio reset in flight. Typically the lighting conditions of one's environment are poor for qvio to work robustly and you can get multiple rests in flight.

DronAlan

Hi @Cliff-Wong ,

Thank you so much for your detailed response and help! Actually, I have some great news: it is working now! Before I saw your message, I had already performed most of those resets and reconfigurations because I noticed something critical: the CPU was completely saturated. When running voxl-inspect-services, several services (especially the portal and mapper) were maxing out the CPU with percentages in red.

Once I managed to clean up the configurations, restart the pipes, and get the CPU usage back to normal, stable levels (no red percentages in the inspector), the drone started behaving correctly. I tested the trajectory planning and it executed it decently. There is still a tiny bit of error/drift, but it is much more reliable now and no longer going crazy.

I really appreciate your troubleshooting steps regarding the extrinsics and the VIO resets, it's great to know how to diagnose those for future tests. Thanks again for the support!

DronAlan

@Cliff-Wong said in tarling - Path planning (blue line) is erratic and drone moves to wrong locations:

voxl-inspect-qvio -n

As requested, here is the system information and SKU from the splash screen:

system-image: 1.8.04-M0054-14.1a-perf
kernel: #1 SMP PREEMPT Mon Mar 24 21:47:11 UTC 2025 4.19.125
hw platform: M0054
mach.var: 1.0.0
SKU: MRB-D0005-4-V2-C6-T7-M0-X0
voxl-suite: 1.5.0

While optimizing the CPU usage helped stabilize the services, I am now experiencing a new flight behavior that perfectly aligns with your suspicion about an extrinsics error. When I command the drone (via offboard mode) to go to position (1, 1), it physically flies in the exact opposite direction to (-1, -1). It seems its internal orientation is completely inverted or mirrored.

Given my specific SKU, what is the correct procedure to fix this extrinsics orientation? Are there specific rotation matrices or parameters I need to change in /etc/modalai/extrinsic_config.txt, voxl-camera-server, or voxl-vision-hub so that "forward" matches the physical front of the drone?

Thanks again for your continuous support!

DronAlan

Just one more quick detail to add: this behavior is not constant. Sometimes the drone executes the trajectory perfectly fine, and other times it does the opposite thing and goes to (-1,-1).

DronAlan

@DronAlan

DronAlan

@DronAlan

Now he's doing it the other way around, I don't understand anything

Cliff Wong

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