Starling 2 Max Crashes in Position Hold Mode After Disabling Magnetometer for Indoor Flight
-
@berayksl said in Starling 2 Max Crashes in Position Hold Mode After Disabling Magnetometer for Indoor Flight:
@Cliff-Wong I applied the param file you provided and did some test flights recently. Before the flight, I checked the VIO accuracy by moving the drone around in my hand while monitoring the trajectory in the VIO tab on the portal, and it seemed to be working fine.
During the first flight, I put the drone in “Position Hold” mode. It was holding its position quite well initially. I moved it around and rotated it, and it continued to hold position accurately when I released the sticks.
However, after landing and taking it for another test flight a short while later (same area), it wasn’t able to hold its position well in the z-axis. The drone kept ascending and didn’t respond to RC inputs, so I had to trigger the kill switch for safety.
I noticed that VIO performance seems to vary even when flying in the same area, making it unreliable at times. Additionally, I occasionally get a “Yaw estimate error” message on the portal, but there are no corresponding errors on the QGroundControl terminal, and it still allows me to arm.
Do you have any suggestions on what might be causing:
- The inconsistent VIO performance between flights
- The drone ignoring RC inputs during the second flight
- The “Yaw estimate error” message (should I be concerned if QGC shows no error)?
I also tried calibrating the cameras (even though I haven’t changed their locations since delivery) by following the link you provided. I was able to calibrate the front camera successfully, but when I try to calibrate the downward-facing camera, the camera feed on the portal becomes extremely laggy, and the calibration app becomes unresponsive after a while, requiring me to reboot the drone each time.
@Eric-Katzfey can you help me with this as @Cliff-Wong was last online 14 days ago?
@berayksl Hi there, to address your questions:
- The inconsistent VIO performance between flights
appears the inconsistent vio behavior on multiple arm/disarms is due to the way
voxl-open-vins-serverre-initializes after a disarm event. Are you still using in the voxl-open-vins-server.conf option"en_vio_always_on": falseand"en_auto_reset": true?If so, the next thing that can be an issue is takeoff speed. To ensure VIO has the correct origin (0,0,0) we have a conf parameter called:
"takeoff_accel_threshold": 0.5,This is essential a takeoff detector and is set for a aggressive take off (>80% throttle)If you are taking off very slow and gentle, it's possible the detector is not being tripped. Try lowering it from
0.5to0.3.- The “Yaw estimate error” message (should I be concerned if QGC shows no error)?
If the error doesn't repeat, it's just VIO telling PX4 to reset it's heading and PX4 complains on reset. This can be ignored. BUT if QGC keeps repeating the announcement, you have a PX4 yaw_gate issue--make sure in PX4 the param EKF2_EV_CTRL has the 'yaw' option checked.
And as a sanity check cause you are seeing an R/C issue: goto the radio tab in QGC and confirm your pitch/roll/yaw inputs are calibrated and centered such that you are not sending biased commands.
- The drone ignoring RC inputs during the second flight
Are you getting a r/c
"manual control lost"announcement in QGC or just lack of control when trying to move the drone? On the former case we have notice users in environments with lots of metal (e.g. warehouse) will have RF interference issues.At this point, we have numerous improvements in SDK 1.5.0 for Max and it maybe worth the upgrade if your system design allows it. It has improvements with the vio-always-on issues, vio resets, and some PX4 altitude improvements.
-
@berayksl Hi there, to address your questions:
- The inconsistent VIO performance between flights
appears the inconsistent vio behavior on multiple arm/disarms is due to the way
voxl-open-vins-serverre-initializes after a disarm event. Are you still using in the voxl-open-vins-server.conf option"en_vio_always_on": falseand"en_auto_reset": true?If so, the next thing that can be an issue is takeoff speed. To ensure VIO has the correct origin (0,0,0) we have a conf parameter called:
"takeoff_accel_threshold": 0.5,This is essential a takeoff detector and is set for a aggressive take off (>80% throttle)If you are taking off very slow and gentle, it's possible the detector is not being tripped. Try lowering it from
0.5to0.3.- The “Yaw estimate error” message (should I be concerned if QGC shows no error)?
If the error doesn't repeat, it's just VIO telling PX4 to reset it's heading and PX4 complains on reset. This can be ignored. BUT if QGC keeps repeating the announcement, you have a PX4 yaw_gate issue--make sure in PX4 the param EKF2_EV_CTRL has the 'yaw' option checked.
And as a sanity check cause you are seeing an R/C issue: goto the radio tab in QGC and confirm your pitch/roll/yaw inputs are calibrated and centered such that you are not sending biased commands.
- The drone ignoring RC inputs during the second flight
Are you getting a r/c
"manual control lost"announcement in QGC or just lack of control when trying to move the drone? On the former case we have notice users in environments with lots of metal (e.g. warehouse) will have RF interference issues.At this point, we have numerous improvements in SDK 1.5.0 for Max and it maybe worth the upgrade if your system design allows it. It has improvements with the vio-always-on issues, vio resets, and some PX4 altitude improvements.
@Cliff-Wong Hi there. Thank you for answering my questions. We’re still using the same voxl-open-vins-server.conf settings with "en_vio_always_on": false and "en_auto_reset": true. I also updated the system to SDK 1.5.0 as suggested, but unfortunately, it didn’t seem to resolve the issue.
To further investigate, I tested VIO performance by holding the drone in my hand and moving it manually while observing the trajectories in the VIO visualization. I noticed two distinct trajectories being displayed: QVIO and OV. Sometimes the OV trajectory appears more accurate when I move the drone in a “plus” pattern, and sometimes the QVIO trajectory is more accurate, but most of the time it tends to drift significantly, and sometimes QVIO doesn't move at all.
I have two questions:
1-) What is the difference between QVIO and OV, and which one is actually used during flight for position estimation?
2-) What could be causing QVIO to fail to track properly, while OV performs well? (or the other way around)
Also, I'm not getting any 'manual control lost' errors in QGC, and I'm able to control the drone perfectly fine. However, it doesn't respond to any control inputs on rare occasions, where the drone can't hold its position and continues to ascend when I use VIO in 'Position Hold' mode.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login