Robot Operating System (ROS) is a widely used software system for robotics. ROS establishes and enables a data flow among different parts of a robot using the so-called “publisher – subscriber” paradigm, e.g.:
- a proximity sensor of a robot generates data and publishes it to an actuator
- a robot’s actuator subscribes to a data flow from the proximity sensor to get the data
- a robot may have many “publishers” (i.e. sensors) and “subscribers” (i.e. actuators), as well as various different software for inter-robotic communications
- ROS seamlessly enables the data flows among different parts of a robot, managed by ROS applications
ROS architecture design
A high-level data flow is enabled by a central part of the ROS framework, called the ROS core, shown on Figure 1. The ROS core is responsible for advertising the communication topics across subscribers and publishers.
ROS system is focused on different robotic application tasks inside a robot, that is – most of the data communication flow is taking place locally. If an external ROS application wants to communicate with some part located on a robot, it should directly connect to the ROS core daemon running on a robot, using some 3-rd party TCP/IP communication links, such as Wi-Fi or Ethernet cable.
This approach is not suitable for underwater robotic applications, where the communication links are usually not TCP/IP-based, and do not posses with high communication capacities necessary to forward the ROS-message overhead from an external ROS application, located on the surface. TCP/IP based wired links (i.e. Ethernet) are possible, however, they would significantly reduce a communication range and the mobility of the underwater nodes. Wireless RF-based solutions such as Wi-Fi are not feasible underwater, which makes the low-bandwidth acoustic communications link to be the main method of communication.
Given such a high constraint on the capacity and reliability of the acoustic communication, enabling a communication among ROS-enabled underwater vehicles becomes a challenging task. We propose the following solution:
- present an independent suite of underwater communication protocols called AquaNet, to enable communication over acoustic links – Figure 2 shows a general AquaNet stack of protocols;
- develop a separate ROS application called “ros-aquanet-adapter”, which connects any kind of local ROS applications to a unified underwater communication interface via AquaNet (see Figure 3).
This approach enables inter-vehicle communication among the underwater robots running ROS-enabled mission applications.
AquaNet communication structure
Figure 2 shows a general structure of AquaNet communication stack. It supports various protocols for underwater networks on the L4-transport, the L3-network and the L2-MAC layers. Moreover, the AquaNet provides interfaces to PHY layer as well, that is – to different acoustic modems attached. Besides that, the software is able to emulate the PHY layer, making it possible to test and debug different underwater network configurations before proceeding to the tests in a real environment.
Proposed ROS-AquaNet integration solution
Figure 3 shows a high-level integration concept between ROS and AquaNet stack of protocols. This integration is enabled by introducing an additional “layer” in-between ROS and AquaNet, called “ros-aquanet-adapter”. Some of the features of the aquanet-adapter include:
- ROS-AquaNet-adapter is implemented as a separate ROS package
- Start the AquaNet stack on all communication parties
- Define the list of ROS topics to listen from: aquanet-outbound topic
- Define the list of ROS topics to publish the received data back: aquanet-inbound topic
ROS-aquanet-adapter is developed as an independent ROS application, which is able to gather the data from the other ROS applications and forward it to the other side of a network via AquaNet. This is done by introducing a special ROS topic called “aquanet-outbound”, which stands as an entry point for all outgoing transmissions for the sender ROS applications.
On a receiver side, the ROS-aquanet-adapter advertises another topic called “aquanet-inbound”, which plays a role of a receiver point for all ROS applications on the receiver side. Additionally, the ros-aquanet-adapter on the receiver side is able to publish the received data directly to the topics of the originally intended ROS-application receiver.
Message transport
The adapter provides some message serialization/deserialization techniques, necessary for message transmission over a network. This includes:
- Message encapsulation via DCCLv3 and GPB libraries:
- DCCL – Dynamic Compact Control Language:
- Used for message “marshalling” – i.e., encoding/decoding messages to send over low-throughput links, such acoustic or satellite links
- DCCL – Dynamic Compact Control Language:
- GPB – Google Protocol Buffers:
- Mechanism for serialization/deserialization of the structured data
Future Steps and Design Challenges
- How to forward a message from the original ROS application via ros-aquanet-adapter?
- Handle multiple ROS data types and topics
- How to determine a topic name from the original ROS application?
- Use ROS callback functions to determine the original ROS-sender
- When a message is received on the other side, how to find the right ROS application?
- Create our own aquanet data structure to keep all important information from the original ROS topic, such as:
- Sender’s original topic name
- Sender’s ID, etc.
- Create our own aquanet data structure to keep all important information from the original ROS topic, such as:
Future steps:
- Conduct the first tests using ROS TurtleSim package
- Provide universal API to support different ROS message types
- Test communication scenarios under more complex topologies:
- Point-to-multipoint communication
- Multi-hop communication over number of nodes