Difference between revisions of "Subsystems"

From PaparazziUAV
Jump to navigation Jump to search
m
 
(34 intermediate revisions by 8 users not shown)
Line 1: Line 1:
== About ==
<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>
{| class="wikitable"
|-
| Since '''v6.0''' all subsystems have been moved to modules and no longer exist in Paparazzi.
|}
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
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]].
configuration options to them. (See conf/autopilot/subsystems/...)
{| class="wikitable"
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
| Since '''v5.8''' it is possible to safely replace ''subsystem'' by ''module'' in your airframe file. The roadmap of Paparazzi is to convert existing subsystems to [[modules]].
us to change the code and move/rename files behind the scenes without
|}
breaking everyones airframe files.


=== Differences to Modules ===
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/firmwares/subsystems/...</tt>)
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,
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.
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.
See [[FirmwareArchitecture]] for the differences to [[Modules]], as well as how to write a new subsystem.
infrared), or the other way round (e.g. imu_ppzuav).
As you can see with the imu_ppzuav module it also still expects a
direct ImuEvent call from main_ap, so you could say it's not a "pure"
module.


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


{| class="wikitable" border="1"
{| class="wikitable sortable" border="1"
! Name !! types !! firmwares !! description
! Name !! Types !! Firmwares !! Architecture !! Description
|-
|-
|[[Subsystem/gps|gps]]
|[[Subsystem/gps|gps]]
||
||
*ublox
* ublox
* ublox_utm
* ublox_utm
* nmea
* nmea
* mediatek_diy
* mediatek_diy
* skytraq  
* skytraq
| all || GPS drivers
* sirf
|
* all
* fixedwing
* all
* fixedwing
* rotorcraft
* rotorcraft
|
* all
| GPS drivers
|-
|-
|[[Subsystem/imu|imu]]
|[[Subsystem/imu|imu]]
||
||
* analog
* apogee
* aspirin_v1.0
* aspirin_v1.0
* aspirin_v1.5
* aspirin_v1.5
* aspirin_v2.1
* aspirin_v2.2
* aspirin_i2c_v1.0
* aspirin_i2c_v1.5
* aspirin2_i2c
* b2_v1.0
* b2_v1.0
* b2_v1.1
* b2_v1.1
* b2_v1.2
* b2_v1.2
* drotek_10dof_v2
* gl1
* yai
* yai
* aspirin_i2c
* krooz_sd
* analog
* navgo
* ppzuav
* umarin
* crista
* crista
* crista_hmc5843
* crista_hmc5843
* ppzuav
|
|
* all
* all
Line 63: Line 76:
* all
* all
* all
* all
* fixedwing
* all
* fixedwing
* all
* fixedwing
* all
* all
* all
* all
* all
* all
* all
* all
* all
* all
* rotorcraft
* rotorcraft
* rotorcraft
* rotorcraft
* fixedwing
|
* all
* stm32f4
* all
* all
* all
* all
* all
* all
* all
* all
* all
* all
* all
* all
* all
* stm32f4
* lpc21
* lpc21
* all
* all
* all
|| IMU drivers
|| IMU drivers
Traditional IR sensors can be used for fixedwing
but an IMU subsystem is not required
|-
|-
|-
|-
|[[Subsystem/ahrs|ahrs]]
|[[Subsystem/ahrs|ahrs]]
||
||
* int_cmpl_quat
* float_cmpl
* float_dcm  
* float_dcm  
* int_cmpl_euler
* int_cmpl_euler
* int_cmpl_quat
* float_mlkf
| all || AHRS algorithms
* infrared
|
* all
|
* all
|| AHRS algorithms
|-
|[[Subsystem/ins|ins]]
||
* alt_float
* gps_passthrough
* xsens
* xsens700
* ''no_type''
* hff
* extended
* ardrone2
* float_invariant
* ekf2
|
* fixedwing
* fixedwing
* fixedwing
* fixedwing
* rotorcraft
* rotorcraft
* rotorcraft
* rotorcraft
* all (experimental, only tested on fw)
* all
|
* all
* all
* all
* all
* all
* all
* all
* all
* mcu with fpu (e.g. stm32f4)
* all
|| INS algorithms
Most of the INS filters are only providing position and speed, and they need to be used together with an AHRS filter for attitude
 
Currently, only the experimental invariant filter is a full INS
|-
|-
|[[Subsystem/radio_control|radio_control]]
|[[Subsystem/radio_control|radio_control]]
Line 83: Line 177:
* spektrum
* spektrum
* datalink
* datalink
* superbitrf_rc
* sbus
* sbus_dual
|
* all
|  
|  
* all
* STM32
* all
* STM32
* all
* all
* all
* all
* fixedwing
| Radio Control implementations
| Radio Control implementations
|-
|-
Line 94: Line 196:
* transparent_usb
* transparent_usb
* xbee_api
* xbee_api
* superbitrf
|  
|  
all
* all
* all
* all
* rotorcraft
|
* all
* LPC21xx
* all
* STM32
| Telemetry implementations
| Telemetry implementations
|-
|-
Line 101: Line 212:
||
||
* mkk
* mkk
* mkk_v2
* asctec
* asctec
* asctec_v2
* asctec_v2
* pwm_supervision
* pwm
* dualpwm
* skiron
* skiron
* heli
|
* all
|
* all
| Drivers for different ESCs and servos
|-
|[[Subsystem/stabilization|stabilization]]
||
* int_quat
* float_quat
* int_euler
* float_euler
* indi
|  
|  
* rotorcraft
* rotorcraft
* rotorcraft
|
* rotorcraft
* all
* rotorcraft
| Attitude control system for rotorcraft
* rotorcraft
* rotorcraft
| drivers for different ESCs for rotorcraft
|}
|}


[[Category:Software]] [[Category:Developer_Documentation]] [[Category:Subsystems]]
[[Category:Software]] [[Category:Developer_Documentation]] [[Category:Subsystems]]

Latest revision as of 02:45, 29 November 2021

Since v6.0 all subsystems have been moved to modules and no longer exist in Paparazzi.


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.

Since v5.8 it is possible to safely replace subsystem by module in your airframe file. The roadmap of Paparazzi is to convert existing subsystems to modules.

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
  • ublox
  • ublox_utm
  • nmea
  • mediatek_diy
  • skytraq
  • sirf
  • all
  • fixedwing
  • all
  • fixedwing
  • rotorcraft
  • rotorcraft
  • all
GPS drivers
imu
  • analog
  • apogee
  • aspirin_v1.0
  • aspirin_v1.5
  • aspirin_v2.1
  • aspirin_v2.2
  • aspirin_i2c_v1.0
  • aspirin_i2c_v1.5
  • aspirin2_i2c
  • b2_v1.0
  • b2_v1.1
  • b2_v1.2
  • drotek_10dof_v2
  • gl1
  • yai
  • krooz_sd
  • navgo
  • umarin
  • crista
  • crista_hmc5843
  • ppzuav
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • rotorcraft
  • rotorcraft
  • fixedwing
  • all
  • stm32f4
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • stm32f4
  • lpc21
  • lpc21
  • all
  • all
  • all
IMU drivers

Traditional IR sensors can be used for fixedwing

but an IMU subsystem is not required

ahrs
  • int_cmpl_quat
  • float_cmpl
  • float_dcm
  • int_cmpl_euler
  • float_mlkf
  • infrared
  • all
  • all
AHRS algorithms
ins
  • alt_float
  • gps_passthrough
  • xsens
  • xsens700
  • no_type
  • hff
  • extended
  • ardrone2
  • float_invariant
  • ekf2
  • fixedwing
  • fixedwing
  • fixedwing
  • fixedwing
  • rotorcraft
  • rotorcraft
  • rotorcraft
  • rotorcraft
  • all (experimental, only tested on fw)
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • all
  • mcu with fpu (e.g. stm32f4)
  • all
INS algorithms

Most of the INS filters are only providing position and speed, and they need to be used together with an AHRS filter for attitude

Currently, only the experimental invariant filter is a full INS

radio_control
  • ppm
  • spektrum
  • datalink
  • superbitrf_rc
  • sbus
  • sbus_dual
  • all
  • all
  • STM32
  • all
  • STM32
  • all
  • all
Radio Control implementations
telemetry
  • transparent
  • transparent_usb
  • xbee_api
  • superbitrf
  • all
  • all
  • all
  • rotorcraft
  • all
  • LPC21xx
  • all
  • STM32
Telemetry implementations
actuators
  • mkk
  • mkk_v2
  • asctec
  • asctec_v2
  • pwm
  • dualpwm
  • skiron
  • all
  • all
Drivers for different ESCs and servos
stabilization
  • int_quat
  • float_quat
  • int_euler
  • float_euler
  • indi
  • rotorcraft
  • all
Attitude control system for rotorcraft