create a range of common quadcopter frame sizes and general ROMFS cleanup

[dagar]

This was motivated by px4fmu-v2 flash space, but it's something I've wanted to improve for some time now.

One common source of confusion I see with new (and even experienced) users is not knowing where to start with airframe selection. We have a range of issues with the default airframes, including fairly generic configurations that are named specifically, or configurations that target a common frame that include many details specific to one particular users setup. The vast majority will never have the exact same setup, and users often end up playing a guessing game.

This PR attempts to start addressing some of these issues.

• create a range of airframes for common quadcopter frame sizes
• don't configure parameters that don't correspond to the actual airframe
  • an airframe for a frame kit shouldn't include PWM settings for particular ESCs unless they come with the kit
  • an airframe shouldn't include user preferences for things like frsky_telemetry
• delete unnecessary airframes for things like vmount or CAN usage. These can easily be configured with a param change.

[dagar]

If there's concern over general churn or some of the airframes that have been added or removed I propose we set up a quick call to review this.

[dagar]

Here's what QGC airframe selection looks like with this PR.

Compared to current master.

[dagar]

TODO

• review and consolidate
  • all VTOLs
  • Quadrotor Wide category
  • helicopters and coaxial helicopters (there should be generics)
  • flying wings (these could all be using the same mixer)
• review generic options in all categories

[hamishwillee]

FWIW I think this is a hell of a lot better end user story - I would know what to select now (either a specific vehicle because that is RTF with no configuration, or a generic config for my frame size).

When this is in we should review the docs in QGC and PX4 user guide to make it clear how you make the selection.

[bkueng]

This looks good except for the various SYS_AUTOSTART ID changes. I understand the intent but it unnecessarily breaks a lot of existing setups. E.g:
4010 -> 4330
4011 -> 4450
4050 -> 4251
1001 -> 4002

EDIT:
We could add transition logic in the form:

if param compare SYS_AUTOSTART 4010
then
  param set SYS_AUTOSTART 4330
fi

[dagar]

Suggestion from @MaEtUgR on the dev call to limit the generic quadcopter selection to small, medium, large.

[hamishwillee]

Suggestion from @MaEtUgR on the dev call to limit the generic quadcopter selection to small, medium, large.

That is probably a good idea, but is there a good shared understanding of what those sizes mean, and if not, how would it be conveyed?

[dagar]

Example of how we're hurting users. #10099

For a non-technical user getting out of this state is quite difficult.

[LorenzMeier]

Happy to review & help to get in if you rebase.

In terms of "bricking": We need support in the bootloader to trigger a complete system reset.

[mcsauder]

@dagar, I've deconflicted your work here: https://github.com/mcsauder/Firmware/tree/pr-airframe_cleanup

EDIT: The current compare isn't too bad: master...mcsauder:pr-airframe_cleanup

[stale]

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

[stale]

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

[stale]

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

[LorenzMeier]

Closing as stale.