This REP is written to provide a common interface for aerial vehicles.
This interface is designed to promote interoperability and reusability of core functionality between diverse aerial vehicles.
By leveraging the interfaces defined in this REP we both tools and libraries can be designed to be reusable between different frameworks and vehicles.
It is expected that aerial vehicles can and will implement additional interfaces in addition to these core interfaces.
When choosing an interface these should be considered the default and only change away from them for a good reason.
These interfaces are designed to be relevant for all types of aerial vehicles whether multi-copter, fixed-wing, hybrid, transitional or other.
Like ground robots, the core abstraction is the same for all vehicles regardless of their method of motivation.
There are a lot of developers around the world using ROS on aerial vehicles.
As such there are also many different implementations which are similiar but not exactly compatible.
A short list of existing known bridges and implementations follows:
Due to a lack of common interfaces the majority of the above packages cannot be used together.
By implementing common interfaces elements of each package can be used in conjunction with elements of a different package.
This will allow much better collaboration between projects and allow a reduction in duplicate efforts to implement the same functionality.
There are also a lot of interfaces already well developed from other domains which can be brought into the aerial vehicle domain.
This REP seeks to also integrate as many of those reusable interfaces as well to provide the greatest compatibilty with those other domains.
For this document we will use the following abstractions of the architecture.
These abstractions are used to define the interfaces, however it is not required that a given system implement all the interfaces.
A given system may implement subsets of these interfaces.
For controlling an aerial vehicle we will use the following terms for the interfaces.
va -.-> am[Allocation Matrix]
va -.-> mixer
am -.-> Actuators
mixer -.-> Actuators
A higher level view of the system uses the following abstraction.
GCS[Ground Control Station]
style L fill:#fff,stroke:#ff0,stroke-width:0px;
L --> CS
L --> GCS
L --> OS
subgraph Generic Planning Framework
Minimum Snap Trajectory Generator]
CM ---|Shared State|MSC
CS -->|Obstacle Observations|CM
MSC -->|Control Abstraction|C
%% Links to L
linkStyle 0 fill:#fff,stroke:#ff0,stroke-width:0px;
linkStyle 1 fill:#fff,stroke:#ff0,stroke-width:0px;
linkStyle 2 fill:#fff,stroke:#ff0,stroke-width:0px;
Aerial vehicles should use the sensor_msgs/BatteryState message for reporting their battery status.
This is a recently standardized message which is much more broadly applicable than aerial vehicles and has already been standardized.
- Datatype: sensor_msgs/BatteryState
- Topic: battery_state
Drones could have different configurations or types as well as define failsafes, engine failures or hardware in the loop setup. These are the fields proposed for this message
- Datatype: proposed_aerial_msgs/VehicleStatus (proposed)
- Service Name: status
uint8 HIL_STATE_OFF = 0
uint8 HIL_STATE_ON = 1
uint8 VEHICLE_TYPE_UNKNOWN = 0
uint8 VEHICLE_TYPE_ROTARY_WING = 1
uint8 VEHICLE_TYPE_FIXED_WING = 2
uint8 VEHICLE_TYPE_ROVER = 3
uint8 VEHICLE_TYPE_VTOL = 4
uint8 system_type # system type
bool engine_failure # Set to true if an engine failure is detected
bool failsafe # true if system is in failsafe state
uint8 hil_state # current hil state
Drones have quite a few flight modes. For example the PX4 Flight Modes number between 9 and 12 for different configurations.
Many of these different modes are modifying which user inputs are used and/or how they are interpreted.
For working with ROS it is expected that the user inputs will be modulated and recieved through the ROS system and that the system will be in control the whole time including implementing fallback and recovery behaviors.
Without the need for these extra modes we will reduce the state diagram significantly.
The autopilot itself is expected to be in Offboard control mode for most configurations using ROS.
In theory all of the states could be eliminated and the arming, takeoff, landing, and return to land logic could be fully implemented, but we will keep those states which are related to safety system already implemented.
To that end the following modes for ROS flight operations are proposed.
RTL[Return to Land]
DISARMED --> |Arm| ARMED
ARMED --> |Takeoff| FLYING
FLYING --> |Land| LANDED
FLYING --> | RTL
Lost Link | RTL
LANDED --> |Auto Disarm| DISARMED
RTL --> |Disarm| DISARMED
FLYING --> |Disarm| DISARMED
RTL --> | Auto Land | LANDED
%% Links to DISARMED
linkStyle 5 fill:#fff,stroke:#f00,stroke-width:3px;
linkStyle 6 fill:#fff,stroke:#f00,stroke-width:3px;
Note that the red disarm transitions are potentially unsafe as they could lead to the vehicle falling.
- Datatype: mav_msgs/FlightMode (proposed)
uint8 flight_mode # The flight mode indicated
- Datatype: mav_msgs/SetFlightMode (proposed)
- Service Name: set_flight_mode
mav_msgs/FlightMode goal # The desired flight mode
mav_msgs/FlightMode result # The resultant state after the attempted transition.
bool success # True if desired change was executed False otherwise.
One of the most common protocols for drones is Mavlink.
It is important that we define the minimal set which provides coverage of general flying vehicles.
This type of abstraction allows the greatest level of reusability of components between different systems.
The goal of a standard message set is to define the things that are completely general, and let implementers define their own specializations for their specific systems.
As those specifications become more mature they can also be standardized as optional extensions to the defined interface.
When using ROS messages these extensions will be discoverable and shareable to facilitate converging implementations.
This section will provide a guide of suggested mappings of existing Mavlink messages to existing ROS messages outside the above minimal specification.
This will be useful for users who are familiar with Mavlink or using a system with mavlink and need to bridge between systems.
This is a departure from Mavlink where things needed to be fully defined in the spec or at least allocated out with negotiated message IDs so that messages didn’t collide.
Also the availability of topics allows the use of the same data structures for different purposes.
For example there doesn’t need to be three IMU messages to tell the different IMUs apart.
This list has focused on getting coverage of it has been grouped into basic categories.
Code should use the ROS_CONSOLE or RCL status api to report status.
This has infrastructure for enabling and setting verbosity levels at startup and runtime as well as changing them during runtime and has standard messages for remotely monitoring and controlling them.
For quick reference the following mavlink messages are considered covered in the specification above.
There are many position reporting methods defined in Mavlink.
They are all variations on PoseWithCovarianceStamped with different relevant frame_ids.
These are all covered in the hierarchy of commands in REP 147
These should be behaviors that then output via the REP’s hierarchy of command topics.
Each node can have logic or parameters to react according to a behavior.
It’s no longer a global state of the system.
There are a lot of existing ROS messages in the sensor_msgs package that can be immediately reused in drones.
A few examples are as follows.
- DISTANCE_SENSOR -- sensor_msgs/Range
- CAMERA_TRIGGER -- std_srvs/Trigger
- OPTICAL_FLOW_RAD -- These could use a new message but I’d want it to be driven by an active user/developer. There might also be potential in existing vision_msgs TODO(tfoote)
- VISION_SPEED_ESTIMATE -- geometry_msgs/TwistWithCovarianceStamped on a specific topic.
- VISION_POSITION_ESTIMATE and GLOBAL_VISION_POSITION_ESTIMATE -- geometry_msgs/PoseWithCovarianceStamped on a specific topic TODO(tfoote) link
For transporting images and image streams it is recommended to use the [image_transport system](http://wiki.ros.org/image_transport) from ROS.
It is capable of streaming raw as well as compressed image streams and selecting the mode at runtime.
There is a plugin system to add support for different compressions and transports.
This would cover:
WIND_COV is recommended to be represented by a geometry_msgs/TwistWithCovarianceStamped on a specific topic.
The absolute measurements can be captured by sensor_msgs/FluidPressure TODO LINK TODO A barometer message with the relative measurements would be a good extension.
Related mesages are:
The message HIGH_LATENCY is a custom summary message for sending the state out.
It’s optimized for a specific use case with specific hardware.
It can easily be directly ported, but is is recommended be broken down into a few different messages or composed of a few different messages forwarded over the high latency/low bandwidth link instead of defining a new datatype.
This is uncaptured but is not documented well enough to define a message and is not a primary flight concern but more of a diagnostic.
For GPS messages there already exists a [NavSatFix](http://docs.ros.org/api/sensor_msgs/html/msg/NavSatFix.html) and a [NavSatStatus](http://docs.ros.org/melodic/api/sensor_msgs/html/msg/NavSatStatus.html) which are recommended for general GPS position information and status.
There are also a bunch of raw and other specific data types that are potentially useful in Mavlink, but are moderately specific to the localization hardware.
As such they would be better ported for specific hardware support packages and not considered fully standardized.
This is mostly encoding specific messages related to autopilot implementation behaviors.
It is recommended to be caputred by a generic waypoint communicated on a specific topic or service instead of as a dedicated message.
These messages can be replaced by using parameters on the nodes to set these values.
ROS provides parameters set and get services which can replace the below messages.
Logging and playback are recommended to be managed by rosbag.
There are APIs already implemented for controlling recording remotely.
There are not currently apis for downloading the data but that is likely better done using a standard file transfer mechanism than through a runtime behavior.
Related mavlink messages include:
It is recommended to use the stadard ROS time abstraction.
There are many capabilities of DDS to check for livelyness and heartbeats built into the communication layer that can be leveraged.
Also the bond libraries from ROS1 have heartbeat logic.
It is recommended that acknowlegement of message receipt be embedded into the communication layer using the reilable transport and callbacks if the message does not arrive.
ROS2 using DDS's security extensions can provide cryptographically secure fine grained authentication, access control, and encryption.
It is recommended to use that toolchain for security.
- RESOURCE_REQUEST not flight related
- V2_EXTENSION not clearly documented
These are generic data types that are defined to let the developer send basically anything over the network.
Instead of shoehorning data into these few generic datatypes on a ROS based system, it is recommended that the developer define their own debug messages and send them along capturing exactly what they want with the appropriate datatypes or structures.
These are simulation specific messages that are specific to integrating the autopilot with simulation.
The current messages are also specific to the autopilot implementation and not generic enough to necessarily use alternative autopilots.
These mavlink messages are coupled directly to hardware and are not abstracted at an optimal level to be considered universal for all vehicles.
These mocap systems can use generic position reports with covariance on a specific topic instead of needing a custom datatype.
This is too low level for a good abstraction, it’s not valid on all types of hardware.
- RC_CHANNELS_OVERRIDE Also overriding user commands
This can be captured as a parameter.
This is a specific message for displaying into a HUD, it’s aggregating and duplicating existing data that doesn’t need to be generally broadcast separately.
This is a debug/status message that’s specific to the current estimator desing. The parameters are not right for a particle filter based estimator or another style of implementation.
These are messages that can share the state of controllers but is only valid for specific controllers and thus not a good candidate for standardization.
The current mission definitions are a basic set of primative behaviors.
They are a significant subset of the capabilities of vehicles and those primatives should not be built into a next generation abstraction for drones.
However that’s not to say that the mission concept should be eliminated.
Going forward the current mission structure is easy for operators to think about and that should be retained, but instead of considering the missions a standard interface for the drones.
They should be parsed and simply generate the REP 147 compliant trajectory that the drone can follow.
In the future this will allow the implementation to extend the mission waypoints types and add more complex logic into the missions and remain compatible with all drones.
This is a very hardware specific message that was added for a specific hardware type.
This is a good example of an extension that was required because the standard was not abstract enough.
These collision messages are customized to a specific implementation and do no generalize.