2023-06-28 Model CFG 2
Configuration files will be written purely with C++.
Each model + board combination will have its own set of configuration files.
Changes to the configuration will be applied during compile time.
All data in the configuration files will be constant
The configuration files will store the following data:
For each motor:
Axis (pitch, thrust, etc)
Direction (positive, negative)
Driver (PWM, DSHOT)
Interface identifier (Which PWM/DSHOT channel?)
Number of motors
For each sensor: (Revisit this later) Maybe a different list for each type of sensor
Type
Driver
Interface identifier
Number of sensors
For each compatible flight mode:
Flight mode subclass?
PID values
Control limits
(control algos) (Might not be model-dependent)
Â
Implementation details
Number of files?
Data structures?
How to access data?
Â
.hpp and .cpp file for each configuration
global_config.hpp file included by each model-specific config.hpp
Â
Managers/ZP include config.hpp, which includes the configurations selected when compiling.
Â
Motors represent as struct in global config:
Axis (enum)
Direction (enum)
Driver (driver class)
Function pointer to driver constructor
Interface identifier (data structure depends on driver)
Array of motor structs in model-specific config
Number of motors (uint8_t) calculated from array
Â
Flight mode superclass in global config
Model-specific config defines subclass for each specific compatible flight mode
Ensures flight modes are only defined if they are compatible
PID values (struct)
control limits
min and max percentage float for each axis
Â
FWManual::control() function is defined somewhere else outside the config files
Â
Structure of flightmode definitions:
global_config.hpp
class flightmode{}
Â
config.hpp for Model A
subclass FWManual : flightmode
subclass QuadManual : flightmode
Â
config.hpp for Model B
subclass FWManual : flightmode
subclass FWAuto : flightmode
Â
AM function receives flightmode parameter
Â
Accessing data:
Example:
Attitude manager includes config.hpp (The specific file was already chosen by the build system)
AM accesses global motor array and number of motors
Iterates through each motor
Accesses corresponding motor driver and interface identifier
Sends command using motor driver function call, passing in the interface indentifier
Remaining issues:
Having to redundantly define flightmodes common to multiple models
Sensor data organization might need more thought
Â
Â
Â