Assisted Flight Modes unclean! FlightModeAssistMap defined in wrong UAVObject

Description

The ManualControl module has become quite complex and unreadable through the addition of Assisted Flight modes.

Assisted Flight modes are not a well defined term. They are used in Stabilized1-6 flight modes to enable GPS assisted flying, making use of the pathfollower and some special path modes. They are hardcoded-enabled for Velocity Roam, but they can also be optionally engaged for PositionHold, AutoLand and AutoTakeoff Flight modes on top of Stabi1-6. They are hardcoded as disengaged for any other flight modes (as assigned to switch positions)

However, there is no intuitive definition nor documentation what AssistedFlightMode actually does or means for each different flight mode that it can be enabled for.

More so, whether assistedControl is enabled for a flight mode switch position (unless the flightMode is VelocityRoam where it is hardcoded as enabled regardless of that setting) is defined in the StabilizationSettings UAVObject - even though it's 6 elements correspond NOT to Stabilization Modes 1-6 but to flight mode positions.
Since this is the case, the setting is definitely defined in the wrong UAVObject and should be in FlightModeSettings.

Frankly, the entire assisted control flight code is a mess that is unintuitive and badly documented, hard to read code with unclear consequences. It is in dire need of refacturing.

At a minimum refactoring should:
1. Put the setting in the correct UAVObject (FlightModeSettings)
2. Add checks to sanitycheck to make sure it is only enabled for supported flight modes
3. Add inline code documentation to make more clear what is the intended behaviour of assisted control in each flight mode that supports it - especially in combo with stabiliyation axis assignments, but also velocityroam, pos hold, auto-land and takeoff.

It would be better to also clean the code up. To me it looks like assisted flight modes are an over-fitting hack that tries to do more than one task at the same time than it was originally designed for. It might be better to add an additional abstraction level - between flight modes (aka what mode the switch is set to) and control modes (control chain and executed modes effectively engaged at the current time)

manualcontrol or positionhold would likely be primitive modes, where flight mode and control mode would be the same thing.
however "return to base" is a more complicated behaviour, that would have flight mode "return to base" but a control mode that cycles (possibly) through "PathPlanner" (to fly a waypoint sequence to get home) "PositionHold" and/or "AutoLand" which would be a clearer implementation than the current one.

This would be cleaner, more versatile for future enhancements and less error prone than the current "assistedcontrol" hack.

From the users point of view the functionality doesn't/shouldn't change much

Environment

None

Status

Assignee

Unassigned

Reporter

Eric Price

Labels

None

Fix versions

Affects versions

REL-16.09 - Black Rhino

Priority

Medium