The Arbiter
Early plans for the arbiter are documented here. This wiki page is considered the authoritative source about how it actually works.
The robot has a number of different "behaviors" it needs to demonstrate in order to complete IARC Mission 7. As much as possible, we would like to be able to develop and test those behaviors in isolation, then put them together with a strategy controller deciding which gets executed at any given time.
The Arbiter allows this to happen, and also performs a couple other useful functions along the way
The arbiter (green) is a middleman between several different primary behaviors (red) and the topics that ultimately control the drone (purple). It takes its orders from the strategy controller (blue). If a behavior stops publishing, the arbiter may choose to send some other set of commands to the drone to prevent a dangerous situation.
Note that the arbiter accepts commands in various formats other than just geometry_msgs/Twist. Currently supported types:
| Topic | Type | Description |
|---|---|---|
/.../cmd_vel |
geometry_msgs/Twist |
Desired velocity of the drone, in its own frame |
/.../cmd_global_vel |
geometry_msgs/TwistStamped |
[coming soon] Desired velocity of the drone, in the provided reference frame |
/.../cmd_pos |
geometry_msgs/PoseStamped |
[coming soon] Fly to the provided pose, in the provided reference frame |
/.../cmd_takeoff |
std_msgs/Empty |
Activate the inbuilt "takeoff" functionality |
/.../cmd_land |
std_msgs/Empty |
Activate the inbuilt "land" functionality |
In addition to the core switching functionality, the Arbiter contains transformers that interpret input formats into standard types. There will also be a number of secondary behaviors (like obstacle avoidance) that live inside the arbiter and are responsible for checking and asserting the safety of the commands before they are published.