parameter system and storing vehicle generated data

[dagar]

The parameter system is primarily used for user configuration of the vehicle. It's also used as storage for several onboard systems like calculated sensor calibration values, storing vehicle flight time, auto incrementing UUID, storing EKF learned bias. These parameters are treated the same as any other parameter, including syncing to the ground, and user editable.

I believe we need a separate area for storing this type of data. Hand editing these parameters doesn't make any sense and only provides another avenue for invalidating a system configuration. Syncing these parameters to the ground wastes time. When they change vehicle side (some every disarm) they break the mavlink param HASH_CHECK mechanism, ensuring the next vehicle connection will require a potentially much longer full parameter sync. Some of these parameters aren't even human readable and need to be reassembled (like flight time). These clutter the param system wasting flash space on the autopilot and they don't scale well with the variability in sensor calibration requirements. Mixing these in with regular user editable parameters increases the need for filtering in the ground control station. These parameters represent nearly 1/3rd of the the active parameters in a typical system.

Separating them could be as simple as prepending a character to treat them as private (~) and no longer sync them to the ground, or we could consider having a secondary internal only storage space. We could also think about storing the entire calibration struct at once instead of splitting a sensor calibration into many manually defined parameters.

Relevant parameters.

• per sensor calibrations
  • X, Y, Z offsets and scale factors
    • CAL_ACCN_{X, Y, Z}OFF, CAL_ACCN_{X, Y, Z}SCALE
    • CAL_GYRON_{X, Y, Z}OFF, CAL_GYRON_{X, Y, Z}SCALE
    • CAL_MAGN_{X, Y, Z}OFF, CAL_MAGN_{X, Y, Z}SCALE
    • airspeed calibration
    • could we store these as structs directly?
    • prime sensors?
  • temperature compensation parameters
    • TC_* (not including params to enable/disable)
• vehicle flight time
  • LND_FLIGHT_T_HI and LND_FLIGHT_T_LO
• COM_FLIGHT_UUID
• EKF2 learned mag bias (EKF2_MAGBIAS_{ID, X, Y, Z}
• SYS_RESTART_TYPE?

Questions/concerns
What are the downsides to this approach?

1. complete vehicle backup and restore via param (with calibration).

• maybe less of an issue if the vehicle calibration is stored separately and not reset

2. temperature compensation setup via param
   • could be replaced with a mavlink api?
3. other issues?

#8568 (comment)
#8569 (comment)

[jlecoeur]

1. complete vehicle backup and restore via param (with calibration).

The backup could be made via the normal parameters + a binary blob for internal data. It does not have to be all parameters.

Alternatively they can be sent on request to the ground station. In this case I like the ~ prefix as it does not require metadata to decide whether a param should be included in the hash or not.

[dagar]

I'd still like to consider this.

[dagar]

This is somewhat relevant to the parameter lock idea. #12429
If the vehicle generated data were stored somewhere else we could truly lock the parameter backend.

[dagar]

Some of this has improved with volatile parameters, but I'd still like to consider storing this data differently.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[junwoo091400]

Possibly duplicate / strongly related to: #12429?

Oh this was mentioned above already!