Violation of MPC_ACC_UP_MAX and MPC_ACC_DOWN_MAX with manual controls.

[squizz617]

Describe the bug
Hi. I kept on testing PX4 searching for the parameter violation I mentioned in #18962 and #18965 that DOES NOT involve any collision or ground contact. This case involves violations of both MPC_ACC_UP_MAX (4.0) and MPC_ACC_DOWN_MAX (3.0) parameters.

To Reproduce
Steps to reproduce the behavior:

1. [terminal 1] make px4_sitl_rtps gazebo -j4
2. [terminal 2] Arm and send the following manual_control messages over MAVLink every 0.1 seconds: 1643407191.4075294-controls.txt

Expected behavior
The acceleration of the drone should stay within the boundaries set by the parameters.

Log Files and Screenshots

• Flight Review
• Key topics and data
• At t=40.6, vehicle_acceleration/xyz[2] is -15.1018 (-5.3018 w/o g = 9.8), and raw accelerometer readings are at -14.9255 and -14.8804, violating MPC_ACC_UP_MAX (default: 4.0). dist_bottom is 1.74 meters, and there was no ground contact right before the violation.
• At t=42.039, vehicle_acceleration/xyz[2] is -6.60973 (3.1903 without g = 9.8), violating MPC_ACC_DOWN_MAX (default: 3.0). dist_bottom is 3.503 meters.
• Recording of the simulation is available here

[bresch]

Hi @squizz617 , those parameters are there to define the constraints of the trajectory generator (i.e.: reference signals used by the position/velocity controller) https://docs.px4.io/master/en/config_mc/mc_jerk_limited_type_trajectory.html#trajectory-generator.
Those constraints are not applied at the output of the controller, only the output thrust is limited by MPC_THR_MIN and MPC_THR_MAX.

As you can see on the plots below (from your log), the trajectory setpoints are within the constraints, but in order to follow those setpoints, the controller needs to ask for more acceleration if it isn't already tracking perfectly (which is impossible).

[squizz617]

Hi @bresch , thanks for the feedback!

I've done more analysis and now I understand where the confusion was coming from.
The current parameter reference describes MPC_ACC_UP_MAX and MPC_ACC_DOWN_MAX as "maximum vertical acceleration in velocity controlled mode upward/down" without mentioning that these parameters come into play only when MPC_POS_MODE is set to 3 so that "ManualAltitudeSmoothVel" flight task is enabled. In the experiment, PX4 was running in the position mode with MPC_POS_MODE set to 4 (default), triggering the "ManualAcceleration" flight task, in which the two params are not used for generating constraints at all. Right?

[bresch]

In the experiment, PX4 was running in the position mode with MPC_POS_MODE set to 4 (default), triggering the "ManualAcceleration" flight task, in which the two params are not used for generating constraints at all. Right?

No, the same algorithm for vertical setpoint generation is used in mode 3 and 4.

What I wanted to say is that:

• those parameters are used to constrain the setpoints (see vehicle_trajectory_setpoint)
• you are looking at the measured acceleration
• to follow a desired setpoint with a given acceleration, the drone will need to produce more acceleration than the setpoint if the tracking isn't perfect

So it's expected that the measured accelerations are sometimes larger than those parameters.

[squizz617]

Yes, I do understand your points; constraints are applied when generating trajectory setpoints, perfectly tracking these setpoints is not possible, so the actual sensor measurements are not necessarily constrained by the said parameters. Thanks for the clarification.

I just want to point out that there are multiple sources of confusions about the expected behavior. I should probably open an issue in the user guide repository, but would really appreciate your feedback on the third point.

1. Inconsistency in the documentation

As of now, Flight Modes Trajectory Support says that "Position mode uses the Jerk-limited trajectory by default". The next section says "Jerk-limited (default)" and "Set in position mode using MPC_POS_MODE=3".

However, Jerk-limited Type Trajectory for Multicopters notes that "The jerk-limited type is not used by default in position mode", and "To enable it in Position mode set the parameter: MPC_POS_MODE=3".

As the default value of MPC_POS_MODE is 4, it had me wondering whether the jerk-limited trajectory generation is the default or not, and if the jerk-limits will be applied when MPC_POS_MODE=4 or not.

2. Inconsistency in the parameter reference

MPC_POS_MODE has a comment that talks about the sub-modes: "3 Smooth position control with maximum acceleration and jerk limits based on jerk optimized trajectory generator (different algorithm than 1)." and "4 Smooth position control where sticks map to acceleration and there's a virtual brake drag", as if the acceleration and jerk limits are not applied for sub-mode 4.

Combining the information, it is pretty clear that MPC_POS_MODE=3 would enable this jerk-limited trajectory generation. But what about when MPC_POS_MODE=4?

MPC_JERK_MAX notes that "This is only used when MPC_POS_MODE is set to a smoothing mode 3 or 4.", so it can be inferred that we can expect the jerk limits for both 3 and 4. However, MPC_ACC_UP_MAX and MPC_ACC_DOWN_MAX says nothing about the sub mode, or anything about their usage in the trajectory generation.

3. Code path in flight_mode_manager and flight task implementations

As you'd already know, flight mode manager switches the flight task according to the value of MPC_POS_MODE.

• In the position mode (POSCTL nav state),
  • 0 leads to ManualPosition,
  • 3 leads to ManualPositionSmoothVel, and
  • 4 leads to ManualAcceleration flight task, which makes sense.
• In the altitude mode (ALTCTL nav state),
  • 0 leads to ManualAltitude, and
  • 3 leads to ManualAltitudeSmoothVel, which also makes sense.

But when you look into the ManualAcceleration flight task implementation, it internally invokes (or overrides) the functions of ManualAltitudeSmoothVel (and consequently ManualAltitude) flight task, not those of ManualPositionSmoothVel flight task.

This doesn't make sense to me, because ManualAltitudeSmoothVel and ManualAltitude are supposed to be enabled when the system is in ALTCTL mode.

It seems that FlightTaskManualPositionSmoothVel::_updateTrajConstraintsZ() and void FlightTaskManualAltitudeSmoothVel::_updateTrajConstraints() happen to apply the same constraining logic for the acceleration along the z-axis (which is congruent with what you've mentioned in the previous comment). But for other control logics and constraints, it follows those of altitude flight tasks. For example, MPC_ACC_HOR_MAX, which are not applied in the altitude mode, is not involved in the trajectory generation of the position mode with MPC_POS_MODE=4. Is this an intended implementation of the ManualAcceleration flight task?

Thanks again for looking into this.

[bresch]

First of all, thanks for digging into this, I agree that there are a lot of inconsistencies in the doc...

But when you look into the ManualAcceleration flight task implementation, it internally invokes (or overrides) the functions of ManualAltitudeSmoothVel (and consequently ManualAltitude) flight task, not those of ManualPositionSmoothVel flight task.
This doesn't make sense to me, because ManualAltitudeSmoothVel and ManualAltitude are supposed to be enabled when the system is in ALTCTL mode.

ManualAltitudeSmoothVel and ManualAltitude are taking care of generating the vertical trajectory profiles of the drone and since it does its job pretty well, we didn't invest time into re-implementing something else for the ManualAcceleration. So in pos mode 4, ManualAcceleration generates the horizontal setpoints only and ManualAltitudeSmoothVel is used for the vertical ones.

For example, MPC_ACC_HOR_MAX, which are not applied in the altitude mode, is not involved in the trajectory generation of the position mode with MPC_POS_MODE=4. Is this an intended implementation of the ManualAcceleration flight task?

You're right, ManualAcceleration uses MPC_ACC_HOR instead of MPC_ACC_HOR_MAX. That's also unexpected to me since one parameter should be used for auto and the other on for manual modes, but looking at the param description, it's apparently by design: "Note: In manual, this parameter is only used in MPC_POS_MODE 4."
Let's ping the author @MaEtUgR for clarification.

[MaEtUgR]

Thanks @squizz617 for digging into this!

1. You're totally right. I updated in mc_trajectory_tuning: bring up to date with acceleration based stick mapping PX4-user_guide#1795
2. A more detailed description of how the acceleration-based mapping works would likely help here. But in short:

• Vertically both smoothed implementations MPC_POS_MODE 3, 4 behave exactly the same. They call the same update of FlightTaskManualAltitudeSmoothVel and don't overwrite the vertical setpoints. As a result MPC_ACC_UP_MAX and MPC_ACC_DOWN_MAX have the same effect and determine the maximum acceleration commanded via the trajectory.
• Horizontally the following parameters configure acceleration-based mapping MPC_POS_MODE=4:
  • MPC_VEL_MANUAL maximal speed when staying with full stick input
  • MPC_ACC_HOR horizontal acceleration when starting from hover with full stick input. So maximum acceleration (not deceleration/braking) without any drag.
  • MPC_JERK_MAX maximum jerk to avoid sudden tilt changes when switching in and out of braking logic when centering the stick.
  • MPC_TILTMAX_AIR general tilt limit as hard limit for maximum braking deceleration.

3. That's correct FlightTaskManualAcceleration is a completely independent implementation for producing horizontal setpoints from sticks. It does not use the jerk-optimized trajectory generator except for the vertical input. That's also why it's based on ManualAltitudeSmoothVel and not ManualPositionSmoothVel. It's also configured in a different way, see my summary under 2. I plan to add this to the docs as well.

In general the most important thing to note is that setting maximum acceleration and jerk does not give you a guarantee that those values are never exceeded in real flying conditions. They are used to configure how the drone should behave e.g. to allow for faster and slower reactions. Does this answer your questions?

ManualAcceleration uses MPC_ACC_HOR instead of MPC_ACC_HOR_MAX. That's also unexpected to me since one parameter should be used for auto and the other on for manual modes

@bresch Sorry, I was not aware of this definition. If we want to define it that way I suggest we call the parameters ACC_HOR_MIS and ACC_HOR_MAN and state this clearly in the description. Would that make sense for you?