I am using a motion capture system with my drone that uses PX4 and I am using the EKF estimator in firmware version 1.13.1. It has an onboard RPI that I send the position feedback too before remapping the topic to the mavros/vision_pose/pose. The issue I am having is, although it sometimes flies (loses control and almost crashes others) it cant follow the setpoints with any precision and wobbles everywhere. An example can be seen in the y-direction:
This is actually very good compared to usual as most times it wobbles way off and isnt anywhere near the setpoint. The logfile is here:
https://logs.px4.io/plot_app?log=0c3c0c88-cb76-410d-b7c9-37c7dbd9ba5a
I am not sure what the cause is, but I have flown the drone using another source of pose feedback and it has worked fine so that eliminates onboard controller tuning. One thing I have noticed is a consistent offset in attitude between the onboard local position and visual odometry:
I recalibrated the drone a few times, unsure on what causes this offset. It appears in another attitude plot as well. I am streaming from motive at 120hz, the setup is time synced. One possibility I thought was the markers are smaller (sensitive to small changes) and are on the frame which can vibrate a little bit. Not sure if this destabilizes the rigid body readings. Either way I am not sure what causes this but if it is firmware or px4 related any advice would be appreciated.
So a couple of things here. First off, the onboard tuning is quite bad, even though it might enable you to fly, I would suggest lowering your rate controller for roll and pitch since it jumps quite a bit.
Furthermore, I can see that you set your EKF2_EV_DELAY to 0, which is impossible for the system to reach. I would set it to around 50, since it seems like the system average around 50 ms delay, but sometimes even goes to 100-150ms.
1 Like
I figured the tuning wasnt ideal as I was just using the standard gains for my Drone configuration. Also, that was one thing I was unsure on, that delay parameter must account for a variety of things? Like depending on the setup, all devices in the system can be time synced (say using a time synchronization software). This ensures the timestamping is the same, but even if that was the case, it must account for the small time difference between the cameras capturing the markers and the imu processing the received pose data? I did actually set it to 50ms for a few flights previously and it couldnt fly at all (compared to 0ms and flies poorly). I believed if all devices were time synced in the setup, the time stamps are the same and there is no delay, as that parameter is a hack to compensate if that was not the case. EKF may consider latency from timestamp to current time…
Hmm I’m actually not quite sure exactly how the delay parameter works if it takes timestamps into account 
That will have to be a question for the devs. If you want to know more about that, I would suggest joining the discord and asking them directly.
But I think a good start would be to just fix your tuning and try and see if that makes any difference. Could be a good idea if you can get the drone to hover stably and react to manual commands to just use auto-tune if you are not experienced in tuning the drone yourself.
I find it interesting, this is from a flight with ekf_ev_delay = 0:
I see from normal well working flights (other peoples ulogs) that delta t is like a normal line as from the px4 website:
when I set ev_delay = 20 it creates estimator time slip:
also with ev_delay=40
not sure what this means but it cant be ideal
hmm I must admit I got no idea what is causing that. Haven’t seen that before. I would suggest try to join their discord and ask, since more people will react to the post there.
