I have been experiencing circular oscillations in GUIDED that look similar to a toilet bowl movement when the quad should hold position. I fly indoors with visual-inertial odometry as my primary and only source of position and orientation/yaw (compass is disabled).
Any ideas on how to stop or reduce this oscillation? Ideally the quad should stay still in the same place. I’m inclined to think it might be related to PSC parameters or bad tuning, since we didn’t do AUTOTUNE (and can’t perform it due to the limitation that we can only fly the copter in a small indoor space); but it flies great in alt hold. Maybe the parameter visodom noise and visodom delay could help?
Here is a log file + screenshot of the oscillations shown in UAV Log Viewer for this log, circled in red, and a drawing further explaining how it moves and how i believe it should actually move. Also, a video where the oscillations can be observerd right after takeoff and before landing.
I have not looked at the tuning (maybe someone else could) , but assuming it is a well tuned vehicle, I see your ViO is lagging 200 msec behind IMU, making it a little marginal for optimal control.
I’m using VINS-FUSION in a Global shutter camera running on a Jetson Nano, with the output at aproximately 10Hz (as seen in the mavros topic). Could you help me understand how can the Visodom output be 10Hz, but still be laggin behing the IMU? What could be causing this 200 ms lag?
The algorithm doesn’t seem to be slow, the VISO_DELAY_MS is set to 20ms, so we should change it to 200ms, which is what you found out. Also, VISO_POS_M_NSE is 0.2m.
Do you have any suggestions on possible enhancements to this situation?
P.S.: thank you for answering so quickly, we’re still novices in this field, so any advice is welcomed
Actually, we are using ArduCopter 4.4.0, I put the wrong tag, I’m so sorry. I’ve edited the post tag to 4.4
We are afraid of going from 4.4.0 to 4.4.1 and introducing unknown variables that could hinder our development, since we are on a very tight schedule (16 days). Do you believe going up to 4.4.1 would be worth it?
Unfortunately Jetson Nano might be a little underpower to run this pipeline.
200 msec correspond to the latency on the complete process , from frame capture to pose output.
Generally we expect 20Hz or better with minimal lag in the control loop (150 msec) for a good and stable ViO.
I would suggest you go outdoor to proceed for an optimal tuning first.
Then you might try to work on optimizing parameters.
@amilcarlucas we are using a Teledyne Flir FMVU-03MTC. We do not have access to an Orin NX at this time, Jetson Nano is the most powerful companion computer we have access to.
@ppoirier thank you very much for the insight. After your reply we have set the visodom delay param to 200 msec and have noticed an improvement in multiple tests, with less toilet bowl, which has already helped us. Sadly, we can’t go outdoor for an optimal tuning this time, but I’ll surely try this in the future. In our tests, the Jetson Nano seemed to be good enough, although seeming to be almost reaching its limit, so maybe it is indeed not capable of running all of this. We intend on trying to run the visodom at 20Hz to check for general improvements and see if the visodom lag is reduced.
