-
Notifications
You must be signed in to change notification settings - Fork 13.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Violation of MPC_ACC_UP_MAX and MPC_ACC_DOWN_MAX with manual controls. #19101
Comments
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. 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). |
Hi @bresch , thanks for the feedback! I've done more analysis and now I understand where the confusion was coming from. |
No, the same algorithm for vertical setpoint generation is used in mode 3 and 4. What I wanted to say is that:
So it's expected that the measured accelerations are sometimes larger than those parameters. |
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 documentationAs 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 referenceMPC_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 implementationsAs you'd already know, flight mode manager switches the flight task according to the value of MPC_POS_MODE.
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 Thanks again for looking into this. |
First of all, thanks for digging into this, I agree that there are a lot of inconsistencies in the doc...
You're right, |
…mapping To safe users from confusion e.g. PX4/PX4-Autopilot#19101
…mapping To safe users from confusion e.g. PX4/PX4-Autopilot#19101
Thanks @squizz617 for digging into this!
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?
@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? |
…mapping (#1795) To safe users from confusion e.g. PX4/PX4-Autopilot#19101
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) andMPC_ACC_DOWN_MAX
(3.0) parameters.To Reproduce
Steps to reproduce the behavior:
Expected behavior
The acceleration of the drone should stay within the boundaries set by the parameters.
Log Files and Screenshots
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
, violatingMPC_ACC_UP_MAX
(default: 4.0).dist_bottom
is 1.74 meters, and there was no ground contact right before the violation.t=42.039
,vehicle_acceleration/xyz[2]
is -6.60973 (3.1903 without g = 9.8), violatingMPC_ACC_DOWN_MAX
(default: 3.0).dist_bottom
is 3.503 meters.The text was updated successfully, but these errors were encountered: