Hi all,
We are flying a cube orange FCU with Airbot Wraith 35A ESCs, and using slam with a 3D LiDAR to feed in VISION_POSITION_ESTIMATE mavlink messages for our external position estimate. The logs I have attached are using ArduCopter 4.1.0-dev with EKF3, however, we have experienced and posted about similar issues we’ve had with 4.0.5 and EKF2 here, so I don’t believe that its a beta version issue.
Since the previous post, we have found that EK*_POSNE_M_NSE=0.5 seems to work best even though our North East innovations are around 0.2 which the EKF Tuning Guide would recommend we set the Noise value to 0.2 but that makes it pretty inaccurate.
We have worked a lot on tuning the PSC values previously(On EKF2 not EKF3) and although it has been able to smooth things out it has never fixed the oscillations we see completely. This makes me think we have a more fundamental issue. In general, our SLAM seems to be fairly accurate when we compare it to real-world landmarks that we set up as well as low latency when comparing the VISP PD with the Laser Altimeter values the waves seem to be in synch. Does anyone have an idea of what we can adjust to get rid of these positioning errors?
Yes, we can fly it in a GPS enabled environment in Auto and Pos/Alt hold modes. We have not tuned the Attitude PIDs through autotune in a GPS unavailable environment and in stabilize mode it flies very well. The issue occurs in Pos/Alt Hold modes in the GPS unavailable environments. We have previously attempted PID tuning the PSC_ PID values and have seen moderate improvements in the XY axis and very little improvement in the Z. We have also had the same PIDs perform inconsistently in different environments with a few glaring issues that I felt like this flight demonstrated well but I can upload flight videos and logs from all/or some of our tuning sessions if that would be helpful.
The first major issue is that regardless of our tuning of the PSC values the drone would always oscillate slightly when it got to its mark, we were able to get it to ±20cm on the XY axis and ±.5 m on the Z. The XY axis isn’t a huge issue since that isn’t very large but it is not a behavior we see in the GPS environment and if it were a PID error I would expect to see the oscillations dampen while holding, but when we did several holding tests we got no such result(Which this video does not represent well). Additionally, the drone seems to be adhering to the “desired” values of xy and z fairly well which I feel could be a sign that our PIDs are tuned ok, but it could be that some are tuned well while ones driving the desired values are not.
The second major issue is the large Z drops when it moves to the next waypoint, I’m not entirely sure what would cause it to do this consistently but it also does not seem to be a PID issue, but I am unsure which is why I’m reaching out.
I will go ahead and work on getting some logs and videos from tests with a better PID tune and longer holds.
Hi, Just an update, I apologize for not uploading another previous log. It was eventually found that we had a massive vibration problem but we only found out after switching to PX4 temporarily. This was partly because the Batching IMU logging wasn’t working but we were able to run the FFT on ACC and GYR data with decent success after we realized our vibrations were so bad. We were able to bring these vibrations down with hardware adjustments but one of the more confusing things for me was that before and after we removed a massive amount of noise the VIBE graph seemed within limits according to the documentation. Our max vibe was around 9m/s/s with one of the axis being as low as 5m/s/s. What does the VIBE logging message actually represent?
For anyone looking at this post in the future the VIBE message is the ACC message after filters such as the notch filter are applied. There is a filtered logging mode for ACC messages but these filtered messages do not have the notch or harmonic notch filter applied.