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.
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 :
- Ardupilot xrce client initiates a connection with the xrce agent
- Once the connection is established,ardupilot starts sending the configured message
- Agent on behalf of ardupilot client starts publishing the message to a dds domain
- ROS-2 subscriber is then started.At this time we should not expect any messages on the subscriber
- 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 :
- https://github.com/eProsima/Fast-DDS/issues/1995 (DDS and ROS2)
- https://github.com/eProsima/Micro-XRCE-DDS-Client/issues/250 (Micro XRCE DDS and ROS 2)
This approach works as follows :
- Ardupilot xrce client initiates a connection with the Micro ROS agent
- Once the connection is established,ardupilot starts sending the configured message
- Micro Ros Agent on behalf of ardupilot client starts publishing the message to the ros 2 domain
- 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 !!