1 new parameter in src/.
- Added 1 parameter:
MPC_Z_ERR_MAX=1.0. - Most activity in
src/(+16/−0).
Full analysis → Summary: automatic analysis
MPC_Z_ERR_MAX = 1.0.src/ (+16/−0).Full analysis → Summary: automatic analysis
None.
| Name | Value | Type | File |
|---|---|---|---|
MPC_Z_ERR_MAX | 1.0 | number | src/modules/mc_pos_control/multicopter_autonomous_params.yaml |
155/280 weighted chars
| Module | Added | Modified | Removed | Lines + | Lines − |
|---|---|---|---|---|---|
src | 0 | 1 | 0 | +16 | −0 |
| Path | Lines | Note | |
|---|---|---|---|
| M | src/modules/mc_pos_control/multicopter_autonomous_params.yaml | +16/−0 |
feat(mc_pos_control): per-axis time-stretch with new MPC_Z_ERR_MAX PositionSmoothing already has a horizontal-error gate (MPC_XY_ERR_MAX) that slows trajectory integration when the smoother's virtual position runs ahead of the drone in XY. The same time-stretch was applied to all three axes, but it was only ever computed from XY error. So: - Z lag never slowed Z down: a noisy altitude reference (e.g. mission setpoint jittering as home altitude is refined in flight) could walk the commanded z 5+ m above the mission target while horizontal tracking stayed fine. The jerk-limited smoother integrates each small step into a velocity ramp, and successive ramps superpose into multi-meter altitude excursions. - Z lag dragging XY: when a Z stretch eventually was added, applying the same scalar to all axes meant a ±1 m altitude jitter could cap forward flight speed during a straight mission leg. That's almost never what we want. Fix: compute time_stretch_xy and time_stretch_z independently using their own _max_allowed_*_error thresholds and apply per-axis. Default the new MPC_Z_ERR_MAX to 1 m (tighter than XY's 2 m because altitude holds are usually crisper). Other PositionSmoothing users (Orbit, GotoControl) keep zero as the vertical error cap, which is the explicit "disable Z stretch" sentinel — so behaviour there is unchanged.