Difference between revisions of "Subsystems"
m |
|||
Line 39: | Line 39: | ||
* aspirin_v1.5 | * aspirin_v1.5 | ||
* aspirin_v2.1 | * aspirin_v2.1 | ||
* aspirin_v2.2 | |||
* drotek_10dof_v2 | |||
* b2_v1.0 | * b2_v1.0 | ||
* b2_v1.1 | * b2_v1.1 | ||
Line 50: | Line 52: | ||
* crista_hmc5843 | * crista_hmc5843 | ||
| | | | ||
* all | |||
* all | |||
* all | * all | ||
* all | * all | ||
Line 64: | Line 68: | ||
* rotorcraft | * rotorcraft | ||
| | | | ||
* | * all | ||
* | * all | ||
* | * all | ||
* all | |||
* all | |||
* all | * all | ||
* all | * all |
Revision as of 12:13, 29 August 2013
Mostly a subsystem is a part offering a specific functionality with a defined interface and can have multiple different implementations. (See sw/airborne/subsystems/...)
They are selected and configured with a <subsystem name="foo" type="bar">
in the firmware section of the airframe file.
All this does is basically include a makefile foo_bar.makefile that adds the respective sources and adds a few configuration options. (See conf/firmwares/subsystems/...)
This makes it easier to put an airframe file together (they replace the old raw makefile section) and also allows us to change the code and move/rename files behind the scenes without breaking everyones airframe files.
See FirmwareArchitecture for the differences to Modules, as well as how to write a new subsystem.
Available Subsystems
Name | Types | Firmwares | Architecture | Description |
---|---|---|---|---|
gps |
|
|
|
GPS drivers |
imu |
|
|
|
IMU drivers
Traditional IR sensors can be used for fixedwing but an IMU subsystem is not required |
ahrs |
|
|
|
AHRS algorithms |
radio_control |
|
|
|
Radio Control implementations |
telemetry |
|
|
|
Telemetry implementations |
actuators |
|
|
|
Drivers for different ESCs for rotorcraft
Fixedwing ESCs and servos are possible on all firmwares/architectures |
stabilization |
|
|
|
Attitude control system for rotorcraft |