to mark a step as This ROS package presents a typical problem of multi-agents in collaborative control during a formation drive. This tutorial lays a foundation for future development on this topic. Formation control algorithm refers to an algorithm that controls multiple agents to form a specific formation to perform a task. Collaboration refers to the cooperation between multiple agents using a certain constraint relationship to complete a task. Take the multi-robot formation drive as an example, collaboration means that multiple robots form a desired formation together. Its essence is a certain mathematical relationship is satisfied between the positions of each robot. Formation methods are mainly divided into centralized formation control and distributed formation control. Centralized formation control methods mainly include virtual structure method, graphical theory method and model predictive method. Distributed formation control methods mainly include leader-follower method, behaviour-based method and virtual structure method.
This ROS package applies the leader-follower method in distributed formation control method to execute the multi-robot formation drive. One robot in the formation is designated as the leader, and other robots are designated as slaves to follow the leader. The algorithm uses the movement trajectory of the leading robot to set the coordinates to be tracked by the following robots with certain direction and speed. By correcting the position deviations from the tracking coordinates, the followers eventually will reduce the deviation between the follower and the expected tracking coordinates to zero in order to achieve the objectives of formation drive. In this way, the algorithm is relatively less complicated.
A common obstacle avoidance algorithm is the artificial potential field method. The movement of the robot in a physical environment is regarded as a movement in a virtual artificial force field. The nearest obstacle is identified by LiDAR. The obstacle provides a repulsive force field to generate repulsion to the robot and the target point provides a gravitational field to generate gravitational force to the robot. In this way, it controls the motion of the robot under the combined action of repulsion and attraction.
This ROS package is an improvement based on the artificial potential field method. Firstly, the formation algorithm calculates the linear and angular velocity of the Slave follower. Then it increases or decreases the linear and angular velocity according to the obstacle avoidance requirements.When the distance between the Slave follower and the obstacle is closer, the repulsion force of the obstacle to the Slave follower is greater. Meanwhile the change of the linear velocity and the angular velocity variations are greater. When the obstacle is closer to the front of the Slave follower, the repulsion of the obstacle to the Slave follower becomes greater (the front repulsion is the biggest and the side repulsion is the smallest). As a result, the variations of the linear velocity and the angular velocity are greater. Through the artificial potential field method, it improves a solution when a robot could stop responding in front of an obstacle. This serves a purpose of better obstacle avoidance.
Multi-agent communication is one of the key steps to complete a multi-robot formation. When the relative positions of multiple robots are unknown, the robots need to share each other's information through communication to facilitate the establishment of connections. ROS distributed architecture and network communications are very powerful. It is not only convenient for inter-process communication, but also for communication between different devices. Through network communication, all nodes can run on any computer. The main tasks such as data processing are completed on the host side. The slave machines are responsible for receiving environmental data collected by various sensors. The host here is the manager that runs the Master node in ROS. The current multi-agent communication framework is through a node manager and a parameter manager to handle communications among multiple robots.
The steps to set up multi-agent communications:
1. Set up ROS Controls in the same network
There are 2 ways of setting up Master/Slave ROS Controls under the same network.
Option 1:
The Master Host creates a local wifi by running the Master node manager. Generally, one of the robots who is designated as the master creates this wifi network. Other robots or virtual machines join this wifi network as slaves.
Options 2:
The local wifi network is provided by a third-party router as an information relay center. All robots are connected to the same router. The router can also be used without internet connection. Select one of the robots as the master and run the Master node manager. The other robots are designated as slaves and run the master node manager from the master.
The decision on which option to choose depends on your project requirements. If the number of robots that need to communicate is not at a large amount, Option 1 is recommended since it saves cost and it is easy to set up. When the number of robots is at large quantity, Option 2 is recommended. The constraint on computing power of the ROS master control and limited onboard wifi bandwidth can easily cause delays and network disruptions. A router can easily fix these issues.
Please note that when performing multi-agent communication, if the virtual machine is used as a ROS slave, its network mode needs to be set to bridge mode.
2. Configure Master/Slave environment variables
After all the ROS masters are all in the same network, the environment variables for multi-agent communication need to be set. This environment variable is configured in the .bashrc file in the main directory. Run the gedit ~/.bashrc command to launch it. Please note that both the .bashrc files of the master and the slave in multi-agent communication need to be configured. What needs to be changed are the IP addresses at the end of the file. The two lines of are ROS_MASTER_URI and ROS_HOSTNAME, as shown in Figure 2-1-4. The ROS_MASTER_URI and ROS_HOSTNAME of the ROS host are both local IPs. The ROS_MASTER_URI in the ROS slave .bashrc file needs to be changed to the host's IP address while ROS_HOSTNAME remains as a local IP address.
ROS multi-machine communication is not constrained by ROS release version. In the process of multi-machine communication, one should be aware of the following:
1) The operation of the ROS slave program depends on the ROS master program of the ROS master device. The ROS master program must launch first on the master device before executing the slave program on the slave device.
2) The IP addresses of the master and slave machines in multi-machine communication need to be in the same network. This means the IP address and the subnet mask are under the same network.
3) ROS_HOSTNAME in the environment configuration file .bashrc is not recommended to use localhost. It is recommended to use a specific IP address.
4) In the case that the slave IP address is not set correctly, the slave device can still access the ROS master but cannot input control information.
5) If the virtual machine participates in the multi-agent communication, its network mode needs to be set to bridge mode. Static IP cannot be selected for the network connection.
6) Multi-machine communication cannot view or subscribe to topics of message data type that do not exist locally.
In the multi-agent formation project, the multi-agent time synchronization setting is a crucial step. In the process of the formation, many problems will be caused due to the asynchronous system time of each robot. Multi-agent time synchronization is divided into two situations, namely, the situation that both the master and slave robots are connected to the network and the situation that both are disconnected from the network.
1. Successful master/slave network connection
After the multi-agent communication is configured, if the master and slave machines can successfully connect to the network, they will automatically synchronize network time. In this case, no further actions are required to achieve time synchronization.
2. Troubleshooting network dis-connections
After the multi-agent communication is configured, if the master and slave devices cannot successfully connect to the network, it is necessary to manually synchronize the time. We will use the date command to complete the time setting.
First, install the terminator tool. From the terminator tool, use the window splitting tool to place the control terminals of the master and slave into the same terminal window (right-click to set a split window, and log in to the master and slave machines by ssh in different windows).
sudo apt-get install terminator # Download terminator to split terminal window
Click the button on the top left, select the option [Broadcast to all]/[Broadcast all], enter the following command. Then use the terminator tool to set the same time for the master and slave.
1. Set up slave name
In the wheeltec_multi function package, it is necessary to set a unique name for each slave robot in order to avoid errors. For example, No. 1 for slave1 and No. 2 for slave2 etc..
The purpose of setting different names is to group running nodes and distinguish them by different namespaces. For example, the radar topic of slave 1 is: /slave1/scan, and the LiDAR node of slave 1 is: /slave1/laser.
2. Set up slave coordinates
The wheeltec_multi package can implement custom formations. When different formations are required, just modify the desired coordinates of the slave robots. Slave_x and slave_y are the x and y coordinates of the slave with the master as the original reference point. The front of the master is the positive direction of the x coordinate, and the left side is the positive direction of the y coordinate. After the setting is completed, a TF coordinate slave1 will be issued as the expected coordinate of the slave.
If there are one master and two slaves, the following formation can be set:
1) Horizontal formation: You can set the coordinates of the slave on the left to: slave_x:0, slave_y: 0.8, and the coordinates of the slave on the right to: slave_x:0, slave_y:-0.8.
2) Column formation: The coordinates of one slave can be set to: slave_x:-0.8, slave_y:0, and the coordinates of the other slave can be set to: slave_x:-1.8, slave_y:0.
3) Triangular formation: The coordinates of one slave can be set to: slave_x:-0.8, slave_y: 0.8, and the coordinates of the other slave can be set to: slave_x:-0.8, slave_y:-0.8.
Other formations can be customized as needed.
Note:
The recommended distance between the two robots is set to 0.8, and it is recommended not to be lower than 0.6. The distance between the slaves and the master is recommended to be set below 2.0. The farther it is from the master, the greater the linear speed of the slave is when the master is turning. Due to the limitation of the maximum speed, the speed of the slave will deviate if it does not meet the requirements. The robot formation will become chaotic.
3 Initialisation of the slave position
The initial position of the slave is at the expected coordinates by default. Before running the program, just place the slave robot close to its expected coordinates to complete the initialization.
This function is implemented by the pose_setter node in the file named turn_on_wheeltec_robot.launch in the wheeltec_multi package.
4. Position Configuration
In a multi-agent formation, the first problem to be solved is the positioning of the master and the slave. The master will construct a 2D map first. After creating and saving the map, run the 2D navigation package and use the adaptive Monte Carlo positioning algorithm (amcl positioning) in the 2D navigation package to configure the positioning of the master.
Since the master and the slaves are in the same network and share the same node manager, the master has launched the map from the 2D navigation package, all the slaves can use the same map under the same node manager. Therefore, the slave does not need to create a map. In wheeltec_slave.launch, run Monte Carlo positioning (amcl positioning), the slaves can configure their positions by using the map created by the master.
5. How to create formation and maintain formation
In the process of formation movement, the master movement can be controlled by Rviz, keyboard, remote control and other methods. The slave calculates its speed through the slave_tf_listener node in order to control its movement and achieve the goal of the formation.
The slave_tf_listener node limits the slave speed to avoid the excessive speed by the node calculation, which will cause a series of impacts. The specific value can be modified in wheeltec_slave.launch.
6. Obstacle avoidance in formation
In a multi-agent formation, the master can use the move_base node to complete obstacle avoidance. However, the initialization of the slave does not use move_base node. At this point, the multi_avoidance node needs to be called in the slave program. The obstacle avoidance node is enabled by default in the package. If necessary, avoidance can be set to “false” to disable the obstacle avoidance node.
Some relevant parameters of the obstacle avoidance node are shown in the figure below, where safe_distance is the obstacle safe distance limit, and danger_distance is the obstacle dangerous distance limit. When the obstacle is within safe_distance and danger_distance, the slave adjusts its position to avoid the obstacle. When the obstacle is within danger_distance, the slave will drive away from the obstacle.
Enter execution command
Preparations before starting multi-agent formation:
The master and slave connect to the same network and set up multi-agent communication correctly
The master builds a 2D map in advance and saves it
The master is placed at the starting point of the map, and the slave is placed near the initialization position (the default slave formation position)
After logging in to Jetson Nano/Raspberry Pi remotely, perform time synchronization.
sudo date -s “2022-04-01 15:15:00”
Step 1: Open 2D map from the master.
roslaunch turn_on_wheeltec_robot navigation.launch
Step 2: Run formation program from all the slaves.
roslaunch wheeltec_multi wheeltec_slave.launch
Step 3: Open keyboard control node from the master or use joystick to remote control the master movement.
roslaunch wheeltec_robot_rc keyboard_teleop.launch
Step 4: (Optional) Observe the robot movements from Rviz.
rviz
Note:
1. Be sure to complete the time synchronization operation before executing the program.
2. When controlling the master of a multi-agent formation, the angular velocity should not be too fast. Recommended linear speed is 0.2m/s, angular speed degree below 0.3rad/s. When the master is making a turn, the farther the slave is from the master, the greater the linear speed is required. Because of the limit on the linear speed and angular speed in the package, when the slave car cannot reach the required speed, the formation will be chaotic. Overall, the excessive linear speed can easily damage the robot.
3. When the number of slave is more than one, due to the limited on-board wifi bandwidth of the ROS host, it is easy to cause significant delays and disconnection of the multi-agent communication. Using a router can solve this problem well.
4. The TF tree of the multi-robot formation (2 slaves) is: rqt_tf_tree
5. The node relationship diagram of the multi-robot formation (2 slaves) is: rqt_graph