parameter set auto generation

[dagar]

I think we need a mechanism for defining each param and metadata once, but with a configurable number of each (that can be overridden per board).

Many parameters in the system have an index.

• CAL_ACCN_*
• CAL_GYRON_*
• CAL_MAGN_*
• COM_FLTMODEN
• PWM_AUX_*N
• PWM_MAIN_*N
• RCN_*
• RC_MAP_AUXN
• RC_MAP_PARAMN
• temp cal (TC_*)

Why?

• removes a huge amount of manually maintained param boilerplate and metadata, the list above accounts for > 1/3 of all params in the system
  • in the past some of the metadata became noticeably out of sync
• better scalability and control per board
  • large configurations with more than 8 PWM outputs per output module
  • extremely small configurations where limiting the param generation to a more realistic maximum would be a worthwhile savings
• future expansion
  • multi-EKF
  • parameter configuration for an arbitrary number of airspeed sensors, GPS, lidar units, etc

Thoughts? @LorenzMeier @bkueng @davids5

[bkueng]

Sounds good. Something like

/**
 * ID of Magnetometer the calibration is for.
 *
 * @group Sensor Calibration
 * @array-min 0
 * @array-max 3
 */
PARAM_DEFINE_INT32(CAL_MAG*_ID, 0);

?
That's simple and we can generate the same XML from that.

Some questions:

• Do we need more than one dimension?
• Does the size need to be per board? What are the savings and are they worth it? It will add complexity and is a potential source or errors, since testing is usually done on one board.

[dagar]

That should work. There aren't many cases where more than one dimension would help (TC polynomial coefficients).

Override per board is a bit of a stretch goal. One not entirely contrived example would be if someone wanted to squeeze PX4 into something tiny and flash constrained with a single IMU. Not having to pay for the additional sensor params in flash (several hundred) would save a few kilobytes. Let's not worry about it for now, I think it's solvable later going in this direction.

The other minor piece would be specifying the index in the metadata.

[BazookaJoe1900]

@dagar Regrading the parameters definition. Why is it on a .c file? that is not a code, its not even tries to be compiled. there might be other implications on the past that might be irrelevant now?

From what I understand the data from the .c files are only taken by scripts to the XML file.
can't this data be on other way? something like small XML files maybe? that will make your ideas much more easier.
(I understand the compatibility issues, and that work is not trivial)

About this issue too:
PX4_PARAM_DEFINE.. is almost not used and can be removed, are you agree?

[dagar]

It's historical, and obviously not C code anymore. The issue is we want to move to defining them in json or xml directly, so it's not worth the project churn to rename them .c to .param (or something), and then rename then yet again right after.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Closing as stale.