Parameter Sorting for GCS // @User: or new field for tags

Right now it appears that Most GCS use this “User” field or the actual parameter name to sort/identify critical parameters and those that should only be changed by advanced users. Is there an easier way that could help everyone out rather than the binary Standard/Advanced user field?

Something that came to my mind was Tags. Parameters that are changed often could be assigned tags that help search or categorize them. It would help group critical parameters during tuning time.

For example, when I am tuning planes for landing, I need both LAND_ parameters and TECS_LAND parameters. In addition, a few other useful parameters such as LEVEL_ROLL_LIMIT and USE_REV_THRUST would also be applicable. Each of those parameters could have tags, one of which could be a // @Tags: field that would include words separated by commas or semicolons to assist in grouping parameters that may not be in the same class.

Some group tags that come to my mind would be Takeoff, Steering, Attitude, Speed, Navigation, Altitude, Failsafe, Safety, RTH, Input, Output, etc. What do you think? Would this help new users find the right parameters to modify without searching through nearly 1,000 parameters?

1 Like

Excellent idea. I wonder if this would be better implemented at the GCS level, and be user-configurable.

The implementation and user-configurability should come from the GCS, but I think the tags should be in the Ardupilot tree. Changes to parameters and names are inevitable, so that’s why I think tags might work best in the long run. Hopefully this would increase communication and compatibility between the code and the GCS.

As I understand it, the parameter descriptions and info is pulled straight from the codebase - not the vehicle during connecting. More information in the code base won’t hurt anything… right?

Indirectly yes - GCS pulls the metadata from XML files on website, which are generated automatically from comments in the codebase. So yes tags could be added to the codebase and be consumed by the GCS - it’s a really good idea.

Suggest you raise a github issue, so it can be picked up by someone and implemented. It’s actually a really non-techie update (more of a doc update), so it could be done quite easily by anyone with the time and inclination.

1 Like