Servers by jDrones

Ardupilot:Native ROS2 support

Ardupilot-ROS2

Introduction

Hello Ardupilot family, my name is Arsh Pratap and I was selected this year to work with Ardupilot organization for GSoC ’21 programme. In this blog I will be discussing my GSoC project - Native ROS2 support for Ardupilot and the progress that I have made on this project so far.

To help readers effectively understand the project , this blog is spit in the following parts-

  • Definitions - To properly define/differentiate some important terms that are going to be used in this project and also to clear confusions that might arise from similar concepts and terms.
  • Basic Setup - Provide details on the setup and the practical aspects of the project
  • Method 1 (XRCE - DDS and Integration Service) - Discuss the working,merits and demerits of the project based on aforementioned approach
  • Method 2 (Customized “Micro-ROS” approach) - Discuss the working,merits and demerits of the project based on aforementioned approach
  • Current Issues - Discussion regarding the issues faced by the project

Definitions

As mentioned above , in this section I will be providing definitions of the important terms and concepts , so as to properly help readers understand the project and also help in clearing some of the doubts/confusions that might arise from similar undermentioned concepts and terms.

ROS - Robotic Operating System is an open source suite of software libraries and tools that is used for developing robotics software.As of now , it is available in two forms ROS1 and ROS2 , each with their own distinct LTS releases.For ROS 2 , the dev team working behind it decided to adopt DDS as its official middleware.In easier words , you can think of ROS-2 being built upon DDS or a “customized form” of DDS.

DDS - Data Distribution Service is a middleware standard defined by OMG(Object Management Group) that is used in real time embedded systems for providing publish-subscribe communication features.Here, we have a global DDS data space (also defined as a DDS Domain) and the data space participants communicate with each other by publishing/subscribing to a corresponding topic(similar topic names and topic data type).DDS implementation is available via several vendors with ROS 2 providing an interface with these implementations.Some of the popular ones are

  • eProsima’s Fast DDS
  • RTI Connext
  • Eclipse’s Cyclone DDS

For a list of DDS vendors that are supported by ROS,you can take a look here.

RTPS - Real Time Publish Subscribe is an interoperability wire protocol defined by OMG consortium and is used by DDS implementations to provide real time publish/subscribe features over transports such as UDP,TCP and Serial(for Posix systems).You can think of RTPS protocol as the “backend” for a DDS implementation.
Screenshot from 2021-07-16 01-44-02
XRCE-DDS - DDS for eXtremely Resource Constrained Environments is OMG specified protocol that provides embedded systems the ability to communicate with an existing DDS data space.Here the resource constrained devices use XRCE-DDS protocol to communicate with a agent which then further communicates with the DDS space on their behalf. eProsima’s Micro-XRCE-DDS is a popular implementation of the XRCE-DDS protocol and a natural fit for this project given the fact that it is the official vendor implementation used by ROS for providing ROS functionalities to micro controllers (discussed below).

XRCE-Client - The resource constrained devices/embedded systems and in our case-our vehicles serve as the XRCE-Clients.These devices due to shortage of memory resources on their end cannot have a normal DDS code running on them , so they use the XRCE-DDS protocol to communicate with the agent(running on the offboard computers) by sending (operation requests) and requesting (responses) from the agent and have it communicate on their behalf on the DDS space.

XRCE-Agent - The agent resides on the off board computer end and hears for any incoming requests from the client(s).Once it receives the operation requests,it then communicates with the DDS space based on the requests and sends the responses to the client.You can think of the XRCE agent as a client’s “proxy” DDS participant.


Micro - ROS - As discussed above eProsima’s Micro-XRCE-DDS implementation is the leading XRCE-DDS implementation available right now.The ROS2 team used Micro XRCE DDS as their official implementation of the XRCE-DDS protocol to provide a new version of ROS-2 that can be used by micro controllers.This new version of ROS-2 is called Micro-ROS and it mainly consists of :

  • Micro-ROS client libraries(rclc), which are nothing but the Micro-XRCE-DDS client libraries with wrappers around it to make it compatible with the ROS-2 stack.
  • Micro-ROS agent , which in a way similar to the Micro-ROS client library, is nothing but the Micro-XRCE-DDS agent with appropriate wrappers around it to make it easily communicate with ROS2 nodes.

Topic - Topics are identifiers that are used to point to a specific data type via topic names that are unique in the DDS domain.DDS entities use these topics to communicate with each other in the dds network.To make sure a successful communication takes place between the entities,one must make sure that the publisher and subscriber have the topci settings.

Integration Service - Given the fact that ROS-2 uses DDS as it middleware,and in theory every ROS-2 node is actually a DDS participant,there are still several configurational changes that are made for a ROS-2 node that it makes cross communication between a ROS-2 and DDS a real mess.As discussed above for two DDS entities to communicate with each other , they must have same topic configurations and hence for setting up a cross communication between between the two protocols,it can really be tough for users to properly configure the protocols specific entities to cross communicate with each other.To battle this issue,eProsima provides its Integration Services which helps in translating a ROS2 topic into its DDS topic analogue or vice-versa.

Basic Setup

For this project, keeping in mind the reduced time frame allotted this year for GSoC ,we decided to focus our efforts on Ardupilot’s simulated vehicles.After having discussions with my mentors ,it was decided that we would be providing communication of Ardupilot to ROS2 via Serial Transport.To achieve this , I have been using 2 USB to TTL (UART serial) adapters and using it with SITL and ROS-2 .The Serial Adapter setup for me looks like this :

For the exact ROS-2 LTS version to use, I have decided to use ROS-2 Foxy,given the fact that micro-ROS is compatible and has been properly tested with ROS2 -Foxy,plus its also the preferred version to use as listed on the micro-ros tutorial page.

The entire code is split in 2 parts :

  • Client Side - This part of the code deals with implementing an xrce client in the Ardupilot code base
  • Agent Side - This part of the code deals with working/setting up ROS-2 nodes for off-board computers.

Method 1 (XRCE-DDS and Integration Service)

Git link : https://github.com/ArduPilot/ardupilot/pull/17779


As of now AP has two different topics.We have a Num message (a 32 bit integer) to test basic functionalities and a INS message that sends information like vehicle’s gyro count and accel count.

This approach works as follows :

  1. Ardupilot xrce client initiates a connection with the xrce agent

  1. Once the connection is established,ardupilot starts sending the configured message
  2. Agent on behalf of ardupilot client starts publishing the message to a dds domain
  3. ROS-2 subscriber is then started.At this time we should not expect any messages on the subscriber
  4. We run the proper integration service file and we should now be seeing the published message(gyro count) from AP being heard by the ROS-2 sub.

Merits

  • This is the current standard/official way of integrating dds with ros2
  • Easy to configure,as we have our own integration service file to take care of the configuration changes of the topics in the two protocols.

Demerits

  • As you can see from the above discussions,the agent side of the code becomes a little too complex.Not only does the user have to run the ros2 node,they also now have to have an instance of the corresponding integration service.
  • Continuing the above point,the agent side of the code base also becomes a little bit more complex.Not only does the user now have to have the ros2 nodes settled they also now need to have the integration service configuration files to be present on the agent side of the computer.

Method 2 (Customized “Micro ROS” approach)

Git link : https://github.com/arshPratap/ardupilot/tree/ddsrosPrototype


As discussed in the above approach we have 2 different topics to test this approach : 32 bit int Num topic and an AP_INS topic for sending the vehicle’s gyro count and accel count.

Before moving forward,I would suggest readers to take a look at below git issues to get a better idea of tackling cross communication (DDS and ROS2) problems through a customized approach :

This approach works as follows :

  1. Ardupilot xrce client initiates a connection with the Micro ROS agent

  1. Once the connection is established,ardupilot starts sending the configured message
  2. Micro Ros Agent on behalf of ardupilot client starts publishing the message to the ros 2 domain
  3. ROS-2 subscriber is then started.At this time we should now be seeing the published message(gyro count) from AP being heard by the ROS-2 sub.

The reason for using only Micro ROS agent on the agent side and not using the micro ros client library is that the micro ros client library is still in active development and as of now does not support the necessary hardware that would be suitable for ardupilot.To counter this problem ,it’s much better to use micro xrce client on the AP side and have micro ros agent on the other.

Merits

  • Having a customised approach helps us in properly molding the client code base to our needs and to maintain uniformity of the entire codebase
  • As seen above,the agent side of the code is simpler as compared to the first approach.Users now have to only worry about the having ROS2 workspace on their off board computers

Demerits

  • This is not an official way to address the cross communication from dds to ros2 and hence should the devs on either end(dds/ros2) change configurations for the respective code base ,we might have to make appropriate changes to our codebase accordingly.
  • The customized approach might be a little complex for interested users to learn about and contribute to,plus since this is not an official way,there are no proper documentation available either for some changes.

Current Issues

Here are some of the issues that I am currently facing while working on the project.

  • Configuring the waf build systems to take care of the xrce client dependencies so that other users can test the branch(s) on their device properly.
  • Make the serial port management a little more dynamic(currently xrce client is able to communicate via the UART through one of the ports)
  • Polishing parts of the code base

I would really like to find out what the devs think about the project and would like to discuss with them below in the comments or on Ardupilot’s ros channel on discord.

Thanks !!

11 Likes

I am eagerly waiting to see the fruits of your labours!
Micro-ROS has been in development for so long that I personally feel a bit lost by now in terms of how it could prove useful after all.

I hope some great use cases will come out of this.
Primarily, breaking the low bandwidth of telemetry information from the Flight Controller to the Companion Computer that right now is limited by the MAVLink stream rates.

It would be dreamy if a ROS-enabled companion computer could have access to the full rates of the sensor messages and command full rate, low-level control signals.

3 Likes

glad to hear it @Georacer

Hi Arsh! Great post! I have several questions, first seems like in both methods you are running the XRCE-Client as part of the Ardupilot code. And that you mean that currently the Micro-ROS client does not run on the Ardupilot hardware?
If this is the case seems like if we use Micro-ROS on the companion side we can later switch the ardupilot side to Micro-ROS? would this require changes on the companion side also?
It seems to me that method 2 is cleaner and more user friendly than using method 1, and if we can migrate easily in the future without requiring more changes on the companion side that this could be a better option?

Micro ROS as of now does not support all the boards that ardupilot currently supports. @jmachuca sir you can take a look at the hardware that is currently supported by Micro-ROS here.Also Micro Ros library for arduino is currently still in experimental stage.
As for swtiching to Micro-ROS on Ardupilot side,definitely we can switch to Micro-ROS once it grows some more and starts supporting AP supported hardwares.As for changes on the companion side , there wont be any need to change stuff on that end.As mentioned above ,Micro-ROS is split in 2 parts : the client library and the agent.Its just the client that would have to be switched once Micro-ROS has matured enough to support the proper hardware.
I agree with you on the fact that 2nd approach is more cleaner and user-friendly.The only reason I am a little skeptical is the fact eProsima provided Integration Services to tackle cross protocol communication issues and hence is the “official” solution . But considering the end result of properly utilizing MicroROS client I do think method 2 is definitely better

Very nice to see that! Thanks, Arsh!

“My two cents”:

I did work a little bit with DDS/RTPS (RTI, CoreDX, and OpenSplice) in the past. DDS intends to be used in LAN and takes some advances to perform well (hardware multicasting, etc…). Indeed we needed to create some “XRCE-Agent” likes proxies, and they used not to be so simple as we wish. So, set up it or run could need some over-engineering in some cases.

My first reaction is to “prefer” the second method. However, your comment about it not being the official way of Ros2 is a good point.

Perhaps a good exercise in deciding your architecture would be to think about your primary utilization. I mean, Who will use it and What for? Here are some questions that may be simple but could help to reflect:

Which one would be more practical for the off-board computer to control 1 to n vehicles?
There are academic works that study quadcopter flight control. Would it be a way to run the EKF outside of a vehicle?
Would the use in a real vehicle be by telemetry radios? They’re relatively slow for some things.
Would the use make more sense with an encapsulated serial access via wifi?
What will it be like when ArduPilot has native Ethernet?

Maybe they don’t make sense with the two topics in ArduPilot today, but… just in case.

Once again, thank you for working on that!

Hi, more higher-level question. Are there’re any plans about actual message/topics implementation? In PX4 it’s natural, they extended existing uORB structure. Here, I think it would be best to mimic Mavros as close as possible.

Servers by jDrones