ROS architecture
Some ROS architecture details
Our system
As mentioned earlier in the Swarm Manipulation section, our work is integrated with the original Clover vehicle through the ROS framework. As a result, our project builds upon the fundamental motion and odometry functionalities of a single Clover provided, via topics and services, by the Clover package and extends it to enable the manipulation and control of multiple Clovers simultaneously. It's important to mention that our project was developed using ROS Noetic in Ubuntu 20.04 and clover image v0.23.
Simulation environment
Enabling the swarm manipulation requires individual access to the services and parameters of each drone. Therefore, a launch file was configured to launch each Clover with a unique namespace. To implement this, we separated the tasks that were originally called together, such as the single_vehicle.launch file. We now have several launch files that initiate the main Clover services, along with a Python script called launch.py that manages the entire launch sequence.
Once initiated, it will launch all standard clover parameters and services for each vehicle, using namespaces as:
'clover0', 'clover1', ' clover2 ' ...
and so on, based on their ID. This ID separates each drone and its attributes since now each one is an object from the Swarm class. Everything related to that specific frame should be referenced with its ID. Eg:
since the node simple_offboard is launched for each namespace.
Real-life swarm
Transitioning to a real-life scenario, the proposed code architecture is very similar to the one applied in the simulation; however, attention must be paid to the new complexities that arise from an uncontrolled scenario, unlike the stable one found in the simulation. All the implementation methods described in this section consider a central computer running the swarm package, thus avoiding the need for expensive processing for each Raspberry Pi.
This can be done in different ways, but we'll present 2 solutions we found the most reliable ones.
Method 1: Defining different Namespaces
Similar to the simulation, we must ensure that all drone data sent and received is handled individually. This can be accomplished by following a similar approach to what was employed in the simulation, which involves defining unique namespaces for each drone. However, in this case, it is also necessary to configure the ROS environment of each drone to ensure that the data published is shared on the same network.
In our project, the definition of namespaces is done through a launch file (realClover.launch), as previously explained in the launch modes section. Additionally, to ensure that the data published by the drones is shared on the same network, we can define the URI of the ROS Master that the system should use to connect to the ROS network in the Raspberry Pi terminal of each drone. The URI consists of an IP address, which in this case should be the IP address of the central computer and a port that defaults to 11311. Below is the commands that should be executed in the terminal of each Clover before running the launch file:
The ROS Master manages communication in a ROS system by providing information about which topics, services, and parameters are available. Therefore, by setting the URI of the ROS Master to that of the central computer, we will have all the relevant data available for manipulation on the same network.
Method 2: Creating a MQTT server
Another possible alternative is to build our local server to deliver the necessary commands to each drone individually, avoiding conflicts. In this scenario, it is interesting to use the MQTT protocol for structuring the server due to its practicality of use and similarity in architecture to ROS.
This method proposes that the master (central computer) running the swarm package sends to the server the services that must be called from each drone in the same way as is done with the namespace method. However, the server will adapt the request and forward the command to the corresponding drone. In each drone, there needs to be a running client responsible for receiving the messages sent by the server and calling the required Clover services. It is important to note that the services would not need individual identification since they would not be shared on a network with the data of other drones from the swarm.
We plan to develop this method yet.
Conclusion
Using an MQTT server can resolve the conflict issues that arise when implementing distinct namespaces for each drone and simplify the creation of larger swarms, since it frees the local network from having to deal with a lot of sockets from each drone. This makes this method a lot more scalable than using namespaces, and leaves a more clean environment. However, its application needs substantial adaptations to the rest of the swarm package, requiring changes in how the services of each drone are called and manipulated.
Thus, it was decided to use the namespaces method similarly to what was done previously in the simulation. However, it is intended to transition to an MQTT server for future projects.
Last updated