Px4-autopilot: Oscillations in auto mode

[neom89]

I have a big quadcopter which starts oscillating when it is close to reaching a way point. This is happening only after I upgraded to v.1.7.2. Before this I had v.1.5.4 and I did not have any problems.
I retuned the gains after I upgraded to v.1.7.2 and the impulse response of the quadcopter was acceptable. The problem appears only when it starts breaking in the auto mode. Here are the two logs using two different sets of gains. First log has a bit aggressive gains but I retuned the gains and reduced the _rate_P gains to a small amount but oscillations still appear just before and after reaching a waypoint.
Log 1 : https://logs.px4.io/plot_app?log=62935c55-ff5a-4345-afd6-1e38b801bc57
Log 2: https://logs.px4.io/plot_app?log=84a29046-efc0-4686-82c8-5ffc644b228a

[deksprime]

I have been observing this exact behaviour on our quadcopter as well. I think this might be due to a newly introduced parameter which has to be set somehow. I am using 1.7.3 and the exact same behaviour is seen on the quad. Estimated yaw is quite off, and the copter twitches right before it reaches the waypoint and right after leaving the waypoint, a very dramatic twitch as if it loses power or something but it is not the case as it can be seen from the logs.
Log 1: https://logs.px4.io/plot_app?log=efff27a4-9977-4e04-8812-540ca7bc668d
Log 2: https://logs.px4.io/plot_app?log=af5e540d-4aff-47ff-885d-e2153827a9ec

[tops4u]

Check if it also happens in PosCTL Mode. If Yes, then it may be due to some change in the Position Controller that was introduced in 1.7.0.

Check: https://github.com/PX4/Firmware/issues/8847

I also don‘t like this behaviour. I was not able to completely get rid of the strong movement, but it got somewhat smoother. It is a lot worse when you move the Pitch/Roll Stick gently to the middle. If the braking is more aggressive then you may almost not notice the Jerk. Which makes it a bit weird, if I wanted to fly smooth it just banks suddenly - At least this is my observation.

[Stifael]

We need to distinguish between auto and manual controlled mode. All the smoothing stuff is no active in auto mode, and hence this issue is independent of #8847.
@neom89 in auto there is no smoothing at all. The logic is very simple in a sense that the vehicle just follows the line to the next waypoint. Once it reaches the waypoint, there is a hard switch to next waypoint, where NAV_ACC_RAD is the threshold at which the switching occurs. However, you can control how fast it should pass a certain waypoint depending on the angle previous-current-next through MPC_CRUISE_90 (https://github.com/PX4/Firmware/blob/master/src/modules/mc_pos_control/mc_pos_control_params.c#L247-L259). This parameter basically says the following: if the angle is 90 degrees, then pass the waypoint with MPC_CRUISE_90. Any other angle is then mapped from the maximum cruise speed (MPC_XY_CRUISE) and a minimum speed of 1 m/s.

From your log, I saw that your cruise speed is quite low (2m/s) and larger than MPC_CRUISE_90 (3m/s). I suggest to lower MPC_CRUISE_90 to 1.5m/s or similar. In addition, NAV_ACC_RAD is quite large given slow speed. I suggest to set NAV_ACC_RAD to 1 (that also works for larger cruise speed)

[deksprime]

@tops4u #8847 is unlikely to be related to this issue, since as @Stifael says it happens when entering the waypoint and exiting the waypoint. Another thing that draws my attention is that both @neom89 and my flight path is triangular, where the copter tries to succeed very sharp turns which might also be introducing an issue. Also, does this MPC_CRUISE_90 param only apply to exactly 90 degrees differences or does it apply to angles>90?

[Stifael]

@tops4u it applies to exactly 90. All other angles are mapped from an exponential function that is defined by MPC_XY_CRUISE and MPC_CRUISE_90. The speed will be lower for angles smaller than 90.

I started now to add some info to the px4 devguide. Hopefully that will make things more clear and allow people to make fixes / improve it.
https://github.com/PX4/Devguide/pull/484/files

[neom89]

@deksprime Did you change the MPC_CRUISE_90? If yes, did you observe any change in the behavior?

[deksprime]

@neom89 I have changed it from 3.0 to 1.5 m/s. Although my MPC_XY_CRUISE parameter was 2 m/s, so decreasing the MPC_CRUISE_90 have actually helped. But I have also tuned down the MPC_ACC_HOR and MPC_ACC_HOR_MAX parameters about which might have also helped.

[neom89]

@deksprime What did you set the MPC_ACC_HOR and MPC_ACC_HOR_MAX values to? I had set it to 2 m/s^2 and 5 m/s^2 respectively.

[deksprime]

@neom89 mine were set to 4 m/s and 6 m/s respectively, for a 650 mm quad. Also I have set the waypoint acceptance radius NAV_ACC_RAD from 3.2 meters to 2 meters (I forgot to mention that)
Edit: btw the issue still persists but is much much better after these tweaks

[Stifael]

here is a temporary rendered version of the docs https://madennis.gitbooks.io/px4dev/content/en/advanced/advanced_position_ctrl_tuning.html.

But I have also tuned down the MPC_ACC_HOR and MPC_ACC_HOR_MAX parameters

I would not decrease MPC_ACC_HOR_MAX, because this way you just make the general tracking worse. Decreasing MPC_ACC_HOR is fine, which will effect the velocity setpoint rate during acceleration.

However, I still would suggest to decrease the acceptance radius to 1. i fly mission with up to 10 m/s, with MPC_CRUISE_90 at 3 and NAV_ACC_RAD at 1, and that works ok. It is important to understand that having NAV_ACC_RAD large, the discontinuity in position setpoint gets larger during the waypoint update.

[neom89]

@Stifael What is an acceptable settling time for an attitude rate control loop for example pitchrate control loop? I am thinking about doing some matlab simulation to tune the gain offline so that I have a good starting point.

[neom89]

@Stifael I made the changes you suggested. There are still oscillations while braking. Here is the log of the flight:

https://logs.px4.io/plot_app?log=3142ffe9-673c-4da7-8f19-fc9af7027923

Is there a way to fix this or should I move to 1.6.5?

[Stifael]

What do you mean with oscillation? Do you mean it brakes to fast, too abrupt? It is not obvious from the log which oscillation you mean.
I can do another PR where the minimum speed is even lower than 1m/s. You could try to lower the acceptance radius even more , since you anyway just fly with 3m/s.
Here is now the final version of the docs: https://docs.px4.io/en/advanced_config/advanced_mc_position_tuning.html

@Stifael What is an acceptable settling time for an attitude rate control loop for example pitchrate control loop? I am thinking about doing some matlab simulation to tune the gain offline so that I have a good starting point.

All the settings that we were talking about are independent of the attitude controller. For the attitude controller, you should tune it such that it tracks the setpoint as fast as possible, You don't want to add any delay.

[neom89]

@Stifael Here is the log for the impulse response test of the quadcopter:

https://logs.px4.io/plot_app?log=54e6a0de-a521-4760-a6dc-c3e070acd4b1

You would be able to see here that the the angular rate and angular references are being tracked by the quadcopter for both roll and pitch.

When I give a mission to the quadcopter, I can visibly see that oscillations are induced in the quadcopter in both pitch as the vehicle starts braking. You can observe this behavior after 22:15 in the following log:

https://logs.px4.io/plot_app?log=3142ffe9-673c-4da7-8f19-fc9af7027923

It is also observed that there is some oscillation in the roll axis right from the beginning which gets amplified after the vehicle starts braking at approximately 22:15.

[Stifael]

@neom89 from the log (https://logs.px4.io/plot_app?log=3142ffe9-673c-4da7-8f19-fc9af7027923) what I see is that the tracking for roll/pitch is not as good as you think it is. You should zoom in for roll and pitch (in the magnitude of 1) and then you can see how bad the tracking is. Besides, this really has nothing to do with auto.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.