Hello Everyone ! My name is Arsh Pratap , and I am glad to share my current progress of my GSoC project, titled Improvements to the Native DDS Support in Ardupilot .
First of all I would like to thank my mentors @rhys and @tridge for helping and guiding me throughout the mentorship session. I would also like to thank @rfriedman for helping me with reviewing my PRs and always providing valuable suggestions for improving my work.
RECAP
I worked with Ardupilot community during my previous GSoC mentorship to provide Ardupilot with Native DDS Support via the implementation of an XRCE-DDS Client , that provided the Ardupilot vehicles with Native DDS publishing functionalities. One can refer the following blog for further details
During my current mentorship, I was tasked with improving the current DDS Support present in Ardupilot and a detailed explanation for all the work that was being worked up until my mid evaluations for this year’s GSoC mentorship can be found here.
WORK DONE
Subscriber Support : We were successfully able to implement the subscriber support similar to the publisher support functionality that was implemented in the previous mentorship, along with the addition of the on_topic function was added to handle the appropriate callbacks that are triggered at every subscription. One can find the details of the implementation below
UDP based Communication Support : We had also decided to add support for UDP transport , ( alongside the currently available Serial Support for DDS communication ) inorder to sync up with the future STM32 boards , which are supposed to have a strong focus on ethernet ports. Based on a previous work done on this branch, we were able to push in a PR that adds UDP transport as another way to the connect with the ROS 2 nodes . A huge thanks to @tridge with helping me push in the PR .
Service Support : We were also able to add in support for Ardupilot vehicles to operate as a ROS 2
server and have ROS 2 nodes utilize the services that Ardupilot provides support for. The PR for the same can be found below. Massive thanks to @tridge , @rfriedman and @rhys for helping me with their suggestions and reviews.
Arming / Disarming Service from ROS-2 node : Now that we have successfully implemented support for ROS 2 services , we have also added a custom Arming/Disarming Motors Service as one of the features. This allows ROS 2 users to successfully arm/ disarm vehicles from the ROS 2 node itself.
- Arming/ Disarming Service Request
# True to arm motors, false to disarm motors.
bool arm
- Arming/Disarming Service Response
# True if arming/disarming request for motors was successful , false otherwise.
bool result
Flight Mode Switch from ROS-2 node : Similar to the previous service, we have also implemented a custom Flight Mode Switching Service, which as the name suggests allows a ROS 2 user to switch the current flight mode to another requested mode.
- Mode Switch Service Request
# This service requests the vehicle to switch its drive/flight mode
uint8 mode
- Mode Switch Service Response
# status : True if the request for mode switch was successful, False otherwise
# curr_mode : Returns the code for the current drive/flight mode , after the processing the request
bool status
uint8 curr_mode
Micro-ROS Approach : As was discussed in my previous GSoC mentorship blog, I had mentioned regarding the existence of potential third approach to connect with ROS-2 by using micro-ROS , but wasn’t able to dig much into this approach mainly because of the mismatch in the target OS and hardware currently being supported by micro-ROS and Ardupilot. I would like to thank @rhys for developing proof-of-concept Ardupilot - microROS SITL build and ESP32 build. The key takeaways from this approach are summarized below .
- Pros :
- Directly using the micro-ROS into the Ardupilot , provides us with access to the ROS 2 api, which a lot of the developers will find it easy to interact and implement any required features.
- micro-ROS is currently the only successful library that has been able to implement all the necessary ROS 2 fundamental entities (including ROS Actions)
- We also witnessed a huge performance boost while utilizing the micro-ROS , as it was able to create some really fast publisher/subscriber communication. (Need to further investigate the performance with ROS 2 Services and Actions)
- Cons :
- The current POC build requires a huge chunk of memory to utilize the micro-ROS library. This makes the current build not an ideal solution for some memory constrained boards currently supported by Ardupilot
- The current POC was build by statically linking the entire micro-ROS build with Ardupilot , but to streamline the integration of micro-ROS with Ardupilot, some major changes have to be made into the Ardupilot codebase (more specifically towards the pre-requisite modules that would be required ) and also since Micro-ROS was setup to be an independent software as compared to Ardupilot, it seems that can be clashes / discontinuity with the way things are implemented and the code practices that are used for Micro-ROS as compared to the larger Ardupilot codebase.
- As mentioned above, there is currently a poor mismatch in the target OS and Hardware being supported by Ardupilot and Micro-ROS
Miscellaneous :
a) Example Repo : To help interested and budding developers to setup and test DDS projects , we have created our own Examples Repository , to test out several different test / use cases involved with this project.
b) Custom DDS profile generation : To complement the above experience and to also help ROS 2 developers wanting to contribute to this project , we have also setup a ROS 2 repository that consists of ROS 2 .srv and .msg definitions for several custom services and topics that can be used for different test cases. The repository also consists of code for several ROS 2 subscribers and clients for several of the topics and services defined in this repo.
c) Verbose Debugging Messages : Given the current nature of the project, especially the development of the Service Support , we ended up cluttering the Ardupilot console with several debug messages. To fix this situation we have pushed in the following PR that allows the said messages to be displayed based on the debug_level ( A DDS parameter , introduced via this PR ) that has been set by the user.
FUTURE UPDATES
- Based on the discussions , I had with @rhys regarding the Micro ROS / Ardupilot build and the current architecture that Ardupilot supports, , we would like to look into a new approach that aims to amalgamate the current DDS architecture with the architecture that is found in Micro-ROS and in the end provide us with a architecture that not only is relative easy to sync up with Ardupilot codebase but is also memory efficient and also provides us with a decent performance.
- I would like to develop a custom xrce dds profile generation script, that enables users to generate a DDS profile (to be used by the XRCE Agent ) based on the topics / services they want to use for their project as compared to the current approach of loading all the topic/ service entities together .
- I would also like to test the current progress that I have made on the project on a real hardware and update the community with the results
- I would like to develop some Gazebo examples to complement the ROS 2 side of the project
Thanks
Note: title image courtesy of ros.org