New REP to replace REP-147 for autopilot agnostic ROS messages optimized for flight stacks

Aerial Vehicles
1

Purpose

This discourse thread can be used to discuss how to get started with the new proposed path for REP-147. As discussed in the February 28, 2024 ROS Aerial Working Group, we have found REP-147 to be insufficient for the needs of ROS developers that use flight stacks.

Problems with existing standards

  • Some messages are too big for using in flight stacks, and overload bandwidth because covariances are mandatory
  • Some messages are not clear on how to use them in simple use cases (How should you use twist to make a plane fly in an altitude hold circle?)
  • MAVLink is the industry standard for multiple open source flight stacks; why reinvent the wheel?
  • MAVLink is highly optimized for low bandwidth high latency communication, which is not an optimization needed onboard an aircraft with an autopilot and a companion computer
  • PX4 uORB is an implementation detail of PX4 and couples ROS developers to PX4 directly, as well as potentially a specific version of PX4
  • MAVLink has no ABI breaking process if certain messages have severe problems; it requires replacing messages and deprecating existing ones
  • The MAVLink governance model can slow the process of making common messages

Shorter Term goals of this effort

  • Make it easier for ROS developers in aerial robotics to write autopilot-agnostic code
  • Integrate flight stacks with existing ROS tooling and simulation infrastructure
    • Foxglove
    • RVIZ
    • PlotJuggler
    • Gazebo
  • Iterate on a small set of messages that are optimized for communicating with common flight stacks
  • Develop example implementations on two common flight stacks
    • ArduPilot
    • PX4
  • Integrate the work done in MAVLink common messages to inform the data content
  • Develop a test suite to verify either an autopilot or a ROS package works with the messages
  • Focus on incremental behavior support, rather than standardization of message definitions
  • Avoid autopilot-specific logic in core behaviors (IE - QGC has specific logic because certain MAVLink messages are interpreted differently by different autopilots)

Out of Scope

The following items are not in scope of the effort, as they have been deemed to not be productive

  • Developing a comprehensive standard of messages before implementation
  • Prohibiting customizations for use-case specific behaviors
    • IE - a delivery drone should be able to add custom messages for dealing with payload grippers
  • Trying to be an official certification authority for using ROS on aerial vehicles that certifies implementations are compliant with a REP

Long term visions

  • Being able to write an autopilot agnostic obstacle avoidance algorithm in ROS and have it work with many autopilots out of the box
  • Being able to write a global planner in ROS and have both fixed-wing and copter vehicles able to follow a path
  • Be able to command a mixed swarm of vehicle types from a central ROS computer

How to start

  1. Propose a list of use cases (problems) that we want to solve (focused on vehicle behavior)
  2. Select a which problem or behavior we want to solve
  3. Design or re-use an existing message(s) to meet the use case
  4. Get agreement between multiple autopilots to support this message
  5. Implement the interface in multiple flight stacks
  6. Write some test code in ROS that can verify the desired behavior is met
  7. Write clear documentation on the new behavior, which message(s) are used, and link to the reference implementation in ROS as well as the PR’s in the flight stacks.
  8. Add the message definition(s) and explanation of the expected behavior to a REP
  9. Merge the changes to the REP
  10. Retrospective
  11. Repeat with a new use case

Proposed use cases to start (will update with feedback)

Here are some more straightforward use cases we could start with

  1. As a ROS developer, I want my autopilot to publish its global position in a way that it can show up on the Foxglove map panel so I can see where it is in a GUI
  2. As a ROS developer, I want my autopilot to publish its battery information so I know whether I can keep flying or land using the ROS 2 CLI
  3. As a ROS developer, I want to be able to arm my vehicle from ROS and know whether it was armed
  4. As a ROS developer, I want a way to force a disarm of my vehicle using the emergency stop feature in QGC
  5. As a ROS developer, I want to know which way vehicle is facing (global yaw) in a GUI
  6. As a ROS developer, I want to know how many GPS satellites each of my GPS sensors has in the ROS 2 CLI
  7. As a ROS developer, I want to be able to click (or touch) a location on a map and have the vehicle fly there while maintaining altitude (this would require #1) using the QGC GoTO feature.
  8. As a ROS developer, I want to be able to know if my vehicle is in currently in a failsafe in the ROS 2 CLI

Please suggest alternatives if you have any better ones, or vote on them. I’ll preserve numbering.

Whether we need to add ROS/DDS directly to QGC for those features, or use a ROS-capable GUI such as Foxglove or RVIZ to things like force disarm or GoTo can be decided later.

3 Likes
2

With the change of Foxglove to go closed source and commercial, we may have to rescope some of these tasks to integrate with other tools (RVIZ).

3

Thank you for starting this important discussion.

Another use case to consider, building on failsafes:
9. As a ROS developer I want to be able to easily query and monitor the safety state of my vehicle (battery remaining, GPS connectivity, flight time remaining, sensors failed etc.)

1 Like
4

Thanks! Let’s add your suggestion to the list. Failsafes are a very important part of a vehicle.

Looks like I can’t edit the original post, but that’s ok.

1 Like