Cannot make an Alt Hold stable

Hey, I have an around 250 mm Quad with PX4 1.8.2 and LPE estimator. I am flying indoors without a GPS. Here are logs from last flight where I tested Alt Hold:
https://logs.px4.io/plot_app?log=6933f388-8e5e-4445-8a18-b126543655f9

As you can see the LPE is working great (the local_position_estimator.z follows the data from Lidar) but I cannot make the quad hover in place. You can also see that I have played with P and PIDv of MPC_Z. What’s wrong? Which parameters should I tune?

Here are zoomed parts of the graph where I am actually in Alt Hold:



Thanks!

You could try to improve the tuning with the params:
https://dev.px4.io/en/advanced/parameter_reference.html#MPC_Z_VEL_P
https://dev.px4.io/en/advanced/parameter_reference.html#MPC_Z_VEL_I
https://dev.px4.io/en/advanced/parameter_reference.html#MPC_Z_VEL_D

Best to change one param at the time maybe in 10 or 20% increments and see if you see a positive or negative effect and then iterate.

I have tried changing all MPC-Z_* parameters, even drastically… Couldn’t see any difference to better or worse.
Is there a chance that this is a vibration problem? I saw that some people here mentioned that as a stability problem.

Good point, your accelerometer data looks quite noisy:
https://logs.px4.io/plot_app?log=6933f388-8e5e-4445-8a18-b126543655f9#Nav-Raw-Acceleration

The other thing is that the local position estimate is tracking the distance sensor very closely which means that you should see very good performance if your distance sensor is accurate and has little delay but not otherwise.
I don’t know how LPE fuses accelerometer, baro, and distance sensor data which is crucial.
I’m going to tag @mhkabir and @jgoppert who should be able to help you with everything LPE.

Thank you @JulianOes. I have tried the current master and it works a lot worse. After entering ALTCTL the drone shoots to the ceiling even if throttle is below 50%. I am pretty sure that it’s not the problem with LPE but with mc_pos_control.
Do you know what’s wrong in these logs? Look at the velocity setpoint, it’s like the drone is doing the opposite: https://logs.px4.io/plot_app?log=c01f4bd4-9bd9-4618-8557-2808cad64f69
Maybe @mhkabir will help?

So with current master, you’re using EKF2? And is the range sensor still working and used?

Still on LPE with range sensor and without an external vision or flow. In short: the althold is not stable or shoots upwards. I will test it without the lidar or outdoors to let it go few meters up before terminating.

Are you hardmounting the flight controller? It can affect the accelerometer and pose estimation significantly.

It’s mounted on fairy stiff and thick mounting tape. But… I have tested the EKF2 estimator on the same setup and MPC* parameters and it worked perfectly! Rock solid altitude hold. It confuses me a lot: how come the mc_pos_control works differently with different estimator? And I am pretty sure that the LPE is fine: the position follows the LIDAR without any significant delays…
I have also tested the LPE v 1.7.0 and it did not help. Here are some logs:
LPE: https://logs.px4.io/plot_app?log=6f315b12-3887-4432-9aa5-1a47b14f6eee
PX4: https://logs.px4.io/plot_app?log=4e6c8836-fd98-44be-a7df-637eb7fd08fa

I understand that LPE is not supported anymore, so people will probably not spend too much time supporting it. I have had other problems with LPE and motion capture, I would not recommend it. If it works with EKF2 and you are sure that it is the only difference, it must be a problem with the LPE estimator.

You velocity looks weird in position hold mode with the LPE estimator. The derivative of the Z position does not look like it matches the Z velocity in the graph underneath when the vehicle is in altitude hold.

Yeah, that’s what I am thinking. I will move to EKF2. The only problem is that it was a lot easier to initialize the PX4 without a mag sensor onboard.

Thanks you all for you help :slight_smile:

1 Like