ROS Framework
Introduction
The ROS Framework acts as a nexus between all the different devices and modules required to command a robot. Ranging from the controller that gathers data, to the controller that conducts the robot, including any module involved in the tasks in between, them being, data treatment, path planning, IA algorithms, etc…
Technical Specifications
The software architecture will have to guarantee the integration of several control devices (from both, software and hardware elements) and a proper synchronization between the different modules ((collaborative) robots, planners, vision systems, data management, cloud, collaborative manipulator, etc...).
To ensure these requirements, the software control architecture will include the following specifications: - ROS: The external control will be developed using the environment provided by ROS. - Real-Time: Those control nodes, critical for the management and regulation of the control loops should be executed under Soft Real Time requirements. - Modularity: All the implementations should allow enabling and disabling specific modules depending on the needs of a particular operation. - Integration and compatibility: Different technologies, hardware devices and programming languages will be used, therefore they should be able to be integrated in an agile and easy way. Therefore, there shouldn’t exist any particular hardware dependencies and the developed software should be easy to deploy. - Programming: The control system will be developed using different programming languages, highlighting the use of C++ and Python since those are the only allowed languages compatibles with ROS. The necessity of using additional programming languages will require additional Frameworks outside the ROS one. - Cloud connection: The ROS framework will require a connection with a cloud server to rely on both, its storing and computing capabilities.
Software and hardware Requirements
The ROS base framework is meant to be installed on embedded devices with a processor based on ARM64 architecture. A recommendable device would be Jetson Orin which uses said architecture and has a high processing power in order to process highly demanding computational tasks.
Other boards, such as the Jetson Nano or the Jetson Xavier could also be suitable for development purposes.
ROS2 Humble is required for this project and, therefore, the Ubuntu Linux - Jammy Jellyfish (22.04) Operating System is recommended, which is also compatible with ARM64 devices:
The following packages are required to deploy and run the AI-PRISM Base Image:
Usage Manual
Assuming we already have an embedded device with Ubuntu Linux - Jammy Jellyfish (22.04) installed, the following steps help us into deploying the AI-PRISM Base Image.
A Docker Image has been built with all the necessary nodes already inbuilt.
It can be easily downloaded using the following steps.
0. Install Docker:
Open a terminal and run the following commands:
# Update the repos
sudo apt update
# Install the certificates
sudo apt install apt-transport-https ca-certificates curl software-properties-common
# Import the Docker GPG key to ensure the authenticity of the Docker packages:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# Add the Docker repository to your system's sources.list.d directory:
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# Update the package index again to include the Docker repository:
sudo apt update
# Finally, install Docker by running the following command:
sudo apt install docker-ce docker-ce-cli containerd.io
After the installation is complete, verify that Docker is running by checking the Docker version:
docker --version
We can give docker, sudo privileges to avoid having to do so constantly:
# Add the user to the docker group using the following command:
sudo usermod -aG docker <username>
IS recommended to restart the device after this point to allow all the changes to take effect.
# To verify that the user has Docker admin permissions, you can run the following Docker command without sudo:
docker run hello-world
1. Pull AI-PRISM Base Image:
We will proceed by downloading a ROS2 Humble Image already prebuilt to run on an ARM64 embedded device. Open a terminal and run the following command:
docker pull dustynv/ros:humble-desktop-l4t-r35.3.1
2. Run the AI-PRISM Base Image:
Run the downloaded Docker Image by opening a terminal and run the following command:
docker run -itd --name aiprism_base ustynv/ros:humble-desktop-l4t-r35.3.1 bash
If you require to connect to the aiprism_base container with several parallel sessions, you can do so by opening another terminal and running the following command:
sudo docker exec -it aiprism_base bash
Use Cases
One of the ROS most useful utilities is its capacity of exchanging messages between the Nodes contained within, in a simple way. We can find three types of interactions between Nodes (programs) depending on the nature off said interaction, depending on whether, when you send a message, a reply is expected, or, in case the message triggers a long process, if feedback is expected while executing thee.
Stated this, ROS was clearly meant to allow communication between devices and prepared to interact with not so fast devices (as it could be a robot). Also proves to be very convenient as a communication middleware between different pieces of software.
Use Case 1.
Publish-Subscribe
The first and most simple of these interactions, is the Publish-Subscribe interaction, where a Node, simply publishes messages to a Topic, and any other Node subscribed to said Topic receives a copy of said message.
Use Case Diagram
Use Case Mock-ups
Using the following Mock-up, we can provide the users with very simple and understandable example regarding how a Publish Node and a Subscribe Node interact with one another.
Every time the Publisher Node, broadcasts a message to a given topic, any Node subscribed to said topic will receive any published message.
Use Case 2.
Server-Client
The second kind of interaction is the Client-Server interaction, where a Node Client sends a request to a Node Server and this Server Node sends back a reply.
Use Case Diagram
Use Case Mock-ups
Using the following Mock-up, we can provide the users with very simple and understandable example regarding how a Service Client Node and a Service Server Node interact with one another.
Every time the Client Node, asks for a request to the Server Node, the Server performs its pertinent tasks and finally returns the result to the Client Node. To exemplify it even better, it would be the equivalent of having a function in another file, where the function would be the Service, and the other file would be another Node.
Action
Finally, the most complex of them all interactions, is the action interaction. This interaction is meant for long processes where just receiving a reply wouldn’t be enough. The action interaction is like a combination of the Publish-Subscriber and the Client-Service interactions since it relies on both. The Node requesting an action, needs to first makes a service call to the action server through the goal service. The action server will reply whether the goal was successfully set or not. Then the action client proceeds by sending a server call to the action client through the response server. The action server will start streaming the status of the given task/action through the “current state topic”. Once the action has finished (successfully or unsuccessfully), the action server will reply to the action client whether the action execution finished successfully or not.
Use Case Diagram
Use Case Mock-ups
Using the following Mock-up, we can provide the users with very simple and understandable example regarding how a Client Action Node and a Client Server Node interact with one another.
Every time the Action Client Node sends a Goal to the Action Server Node, the Action Server performs its pertinent action (normally long lasting tasks) and finally returns a result to the Action Client Node. During this process the Acton Server will keep publishing a feedback to a topic (meaning not only the Action Client Node but also any other Node can subscribe to it) and also, the task can be aborted from the Client ACtion Node side at any moment just by sending a cancel request.
Functional Specifications
The ROS Framework holds the programs or nodes capable of commanding the robot, as well as the drivers to use of any piece of equipment that can be connected to it, being it a robot or a sensor. If any piece of gathered data needs to be evaluated, it can also be done inside the ROS environment. ROS will command the robot into performing its duties, no matter if the specific task its collaborative or not.
ROS2 uses a Fast DDS as a middleware technology to enables communication between different components in a distributed robotic system. The Fast DDS provides an abstraction layer, which allows different components to communicate regardless of their underlying implementation details. The Fast DDS server acts as a bridge between publishers and subscribers in a ROS2 system. It manages topic discovery, facilitates data transmission, enforces QoS settings, and provides a standardized communication layer for components to interact with each other effectively.
Functional Block Diagram
This DDS server is in charge of receiving the details and information of a Node when this one is initialized. The server repeats said information to the rest of the nodes, so each node is aware of all the rest.
Main interfaces
List of main interfaces between functional components shown in the figure.
| ID | Component | Name | Description | Sense |
|---|---|---|---|---|
| 1 | Node | Node Identifier | Each node has its unique identifier used to know which nodes exist and distinguish from one another | Out |
| 2 | DDS Server | Node Identifier | The DDS manages all the nodes identifiers. Every time a node connects its identifier is sent to the DDS to manage it | In |
Sequence Maps
As soon as the DDS is online, any new node that is launched, sends its identifier to this DDS Server.
The DDS Server checks which topics are involved with this new node, and sends its identifier as well as the rest of the other nodes' identifiers to all the nodes involved with the previously mentioned topics.