[WIP] added control modes concept #13097
Conversation
| if (strcmp(argv[1], "multicopter") == 0) { | ||
| obj = new MulticopterLandDetector(); | ||
|
|
||
| } else | ||
| #endif | ||
| #ifdef CONTROL_MODE_VT | ||
| if (strcmp(argv[1], "vtol") == 0) { | ||
| obj = new VtolLandDetector(); | ||
|
|
||
| } else | ||
| #endif | ||
| #ifdef CONTROL_MODE_ROVER | ||
| if (strcmp(argv[1], "rover") == 0) { | ||
| obj = new RoverLandDetector(); | ||
|
|
||
| } else | ||
| #endif | ||
| { | ||
| print_usage("unknown mode"); | ||
| return PX4_ERROR; | ||
| } |
There was a problem hiding this comment.
FYI, the extra tabs are due to the formating hook. I couldn't do commit without that.
added new concept of control modes which allows to separate different vehicles modes in the compile time. current control modes are: fixedwing, multicopter, vtol (vtol), rover.
BazookaJoe1900
force-pushed
the
pr-control_modes
branch
from
bc1574f to
d85fa73
Compare
|
In the case of the land detector I think it could be split fairly easy into separate modules for each vehicle type with the common pieces moving to lib. Selecting including airframes based on vehicle type would result in a large flash savings. |
|
About land detector, I am not sure it will be good to seperate to lib+modules. I think its better to keep them in one module. more important is what do you think about the concept, and about the basic implementation? |
|
We'd benefit from something like this to set the supported vehicle types at the board config level, but I'don't think we should be introducing vehicle type defines throughout the code base unless there's a very compelling reason. The mechanism for handling vehicle type differences is using different sets of modules. For example parameters come along with a module, so if a module isn't included those particular parameters won't even be present in the build. Setting the vehicle type in the board could be a short hand to automatically include the required modules, portions of init (eg rc.mc_defaults), airframes, and mixers. With newer c++ uORB, px4 work queues, module base, and module parameters, the cost of creating and running each additional module is significantly reduced. We should be working towards greater modularity with each of these pieces doing one thing and one thing well. Then the board configurations and system init would evolve alongside to help make this manageable. |
|
@dagar - seems that you didn't like the concept so I am deleting. |
Describe problem solved by the proposed pull request
there are many places of dead code on firmware that related to control mode (fw/mc/vtol/rover) . for example, landing detector of fixed-wing on multicopter only compilations.
also, calling to non-exists parameters of VTOL, on many different places on the code.
Test data / coverage
none for now...
Describe your preferred solution
added new concept of control modes which allows to separate different vehicles modes in the compile time.
current control modes are: fixed wing, multicopter, vtol, rover.
Additional context
note: this is wip, and waiting for responses. after the concept is added many other placed on the code can use that in order to reduce and improve code.
in current examples, i showed that only relevant land detectors modes can now be compiled.
later, places that search for non-relevant parameters can be optimized. for example, look at VT_MODE that spereded in many places.