AP_Follow: FOLL_ACCEL_D/JERK_D/ACCEL_H/JERK_H defaults are above their @Range maximum

[coreyfarley]

Bug Report

Issue details

File: libraries/AP_Follow/AP_Follow.cpp
(lines 165-211)

I noticed four of the FOLL_ parameters have a default that's higher than the maximum in their own @Range comment:

• FOLL_ACCEL_D: default 5.0, but @Range: 0 2.5
• FOLL_JERK_D: default 10.0, but @Range: 0 5
• FOLL_ACCEL_H: default 360.0, but @Range: 0 90
• FOLL_JERK_H: default 720.0, but @Range: 0 360

Origin

27c1f76638 raised six defaults without touching the @Range lines. (The other two, FOLL_ACCEL_NE and FOLL_JERK_NE, still fit inside their ranges)

Impact

The dev wiki page on adding a parameter says ground stations use these comments to "limit the values that the user may set the parameter to". The published Copter parameter list is generated from the same metadata and still shows 0 to 2.5 for FOLL_ACCEL_D, so a vehicle built from current master boots with values the published documentation says are out of range. I have not checked how Mission Planner or other ground stations behave when that happens.

Reproduction

Confirmed in Copter SITL with a wiped EEPROM (sim_vehicle.py -w): after param set FOLL_ENABLE 1, param show FOLL_* reports the out-of-range defaults above (e.g. FOLL_ACCEL_D 5.0, FOLL_JERK_H 720.0).

Version

master @ 9bbfed9c910699892251f76d0a604b4c9ac398dc

Platform

• All
• AntennaTracker
• Copter
• Plane
• Rover
• Submarine

I only tested Copter, but Plane and Rover include the same AP_Follow parameter group (AP_SUBGROUPINFO(follow, "FOLL", ...) in their Parameters.cpp), so they should be affected too.

Airframe type

Default SITL quadcopter.

Hardware type

None. SITL only on x86_64 Ubuntu 24.04.4.

Logs

None. The problem is visible in the parameter values themselves.

Note

I'm a CS student doing this as part of an open-source course, so I may very well be missing context.
If the fix is as simple as raising the @Range lines to match the new defaults, I'd be happy to make it my first contribution.

[rmackay9]

Hi @coreyfarley,

Thanks very much for the report. Yes, the fix should be as simple as increasing the "@range"'s 2nd value. Maybe @lthall has an opinion on what the maximum should be but I'd guess that perhaps 2x the default might be a good starting point.