Difference between revisions of "Subsystems"

From PaparazziUAV
Jump to navigation Jump to search
m
(comparison now in FirmwareArchitecture)
Line 2: Line 2:
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages hideprefix=always>Subsystems</categorytree>
Mostly a subsystem is a part offering a specific functionality with a
Mostly a subsystem is a part offering a specific functionality with a
defined interface and can have multiple different implementations.
defined interface and can have multiple different implementations. (See <tt>sw/airborne/subsystems/...</tt>)
On the technical side subsystems are basically just a convenient way
to pack certain parts of the code into makefiles and add a few
configuration options to them. (See conf/autopilot/subsystems/...)
So these replaced the old raw makefile section in the airframe file.
This makes it easier to put an airframe file together and also allows
us to change the code and move/rename files behind the scenes without
breaking everyones airframe files.


=== Differences to Modules ===
They are selected and configured with a <source lang="xml" enclose="none"><subsystem name="foo" type="bar"></source> in the [[Airframe_Configuration#Firmware_and_Hardware_definitions|firmware section of the airframe file]].
So the difference is that with subsystems you "package" some of the
"normal" code and you have to explicitly call the functions (e.g.
control loops) from the main ap loop. This gives you tighter control
over what gets called when.
The event and periodic functions of the [[Modules]] get called at the end
of event_task_ap and periodic_task_ap respectively.


This means that modules are perfect to add stuff like extra sensors,
All this does is basically include a makefile <tt>foo_bar.makefile</tt> that adds the respective sources and adds a few configuration options. (See <tt>conf/autopilot/subsystems/...</tt>)
but not so much for e.g. estimation and control where you want to
exactly control when and in what order things happen.


But you can also wrap some subsystem code as a modules (e.g.
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.
infrared), or the other way round (e.g. imu_ppzuav).
 
As you can see with the imu_ppzuav module it also still expects a
See [[FirmwareArchitecture]] for the differences to [[Modules]].
direct ImuEvent call from main_ap, so you could say it's not a "pure"
module.


== Available Subsystems ==
== Available Subsystems ==

Revision as of 06:31, 21 April 2012

About

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/autopilot/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.

Available Subsystems

Name types firmwares description
gps
  • ublox
  • ublox_utm
  • nmea
  • mediatek_diy
  • skytraq
all GPS drivers
imu
  • aspirin_v1.0
  • aspirin_v1.5
  • b2_v1.0
  • b2_v1.1
  • b2_v1.2
  • yai
  • aspirin_i2c
  • analog
  • ppzuav
  • crista
  • crista_hmc5843
  • all
  • all
  • all
  • all
  • all
  • all
  • fixedwing
  • fixedwing
  • fixedwing
  • rotorcraft
  • rotorcraft
IMU drivers
ahrs
  • float_dcm
  • int_cmpl_euler
  • int_cmpl_quat
all AHRS algorithms
radio_control
  • ppm
  • spektrum
  • datalink
  • all
  • all
  • fixedwing
Radio Control implementations
telemetry
  • transparent
  • transparent_usb
  • xbee_api

all

Telemetry implementations
actuators
  • mkk
  • asctec
  • asctec_v2
  • pwm_supervision
  • skiron
  • heli
  • rotorcraft
  • rotorcraft
  • rotorcraft
  • rotorcraft
  • rotorcraft
  • rotorcraft
drivers for different ESCs for rotorcraft