DevGuide/BoozDesign
From Paparazzi
Here we want to collect our thoughts on the re-design of the booz airborne code.
Contents |
brain storm
Aims:
- Interface on Navigation, Guidance, Stabilization and Supervision level
- Priority system
- Overlay of different inputs
- Events
Use Cases
- priority of RC to switch to manual mode
- RC overlay of guidance
- FMS overlay of RC (e.g. test signal)
- Limit max. throttle with RC
Events:
- Mode change from RC
- Mode change from GCS
- give priority of mode from RC over mode set in GCS?
- RC lost
- if in Nav mode goto Home mode
- if in Nav mode do nothing
- if in Manual/Auto1 mode goto Failsafe mode
- datalink lost
- if in Manual do nothing
- if in Nav do nothing
- if in Nav goto Home mode
- GPS lost
- if in Nav do Safety landing
- in Manual do nothing
- outside zone
- kill motors
- in Manual do nothing
- if in Nav mode goto Home mode
- battery critical
Autopilot
Describe modules (nav, guidance, stabilization, etc.) as xml with in and outputs. A mode is a specific connection of modules. Events can change the mode.
possible priority systems:
- Every mode belongs to a certain priority level. If an event requests a new mode with a higher priority than the current mode it is switched to the new mode.
Better suited for a lot of different modes which can be grouped into priority levels. - Every event has a condition (current mode) and associated requested mode (or multiple conditions). If the condition matches the current mode the autopilot will switch to the new mode.
e.g. Event: GPS lost Condition: Nav mode ReqMode: Failsafe
This will get tedious with a lot of modes....
Interfaces
navigation
- interface here needed at all?
guidance
- pos setpoint in LTP
- speed setpoint in LTP ?
stabilization
- quaternion fixed point
- quaternion float
supervision
- roll, pitch, yaw and thrust command. unit? limit?
Current Status
<graphviz border='frame' format='svg'> digraph G {
nodesep="0.5" ranksep="0.25" size="5,5"
actuators [ shape=box ] "supervision" [ URL="Booz#Supervision" fontcolor=blue ]
INS [shape=Mrecord,label="{{<hf> horizontal\ filter | <vf> vertical\ filter} | INS }"]
{rank=same baro mag GPS IMU}
{rank=same AHRS INS}
GPS -> INS:ins [label="init ltp"] GPS -> INS:hf
IMU -> INS IMU -> AHRS baro -> INS:vf mag -> AHRS
AHRS -> INS
INS -> guidance_h INS -> navigation
subgraph cluster_guidance {
guidance_v
guidance_h
}
AHRS -> "stabilization attitude" "stabilization attitude" -> supervision [label="roll,pitch,yaw commands"] supervision->actuators guidance_v -> supervision [label="thrust command"] guidance_h -> "stabilization attitude" [label="euler"] navigation -> guidance_h [label=carrot] navigation -> guidance_v [label=alt]
} </graphviz>
ReDesign
Example of input and control loops. For normal navigation mode the the setpoints follow the black path only. But via the green path the RC command can be overlaid on guidance (the two input quaternions to stabilization are multiplied). For manual attitude mode only the green input is considered for stabilization.
<graphviz border='frame' format='svg'> digraph G {
compound=true
nodesep="0.75"
ranksep="0.25"
size="7,4.5"
node [shape=box]
//rankdir=LR
guidance [group=control]
stabilization [group=control]
supervision [group=control]
actuators [group=control]
navigation [shape=ellipse]
overo [shape=ellipse]
stick [shape=Mrecord,label="<stick> stick | {<rc> RC | <fms> joystick |<test> test\ signal}"]
guidance -> stabilization -> supervision -> actuators
navigation-> guidance [label="pos,alt", color=yellow] navigation-> stabilization [label="quat", color=yellow] overo -> guidance [label="pos,alt", color=red] stick:w -> guidance:e [label="speed_sp", ltail=cluster_input, color=blue] //guidance -> stabilization -> supervision -> actuators [color=blue] stick:stick:s -> stabilization:e [label="quat", ltail=cluster_input, color=green] //stabilization -> supervision -> actuators [color=green]
} </graphviz>
