ROBOWORKS Robofleet Orin Nano x3 ROS Robot User Manual

ROBOWORKS Robofleet Orin Nano x3 ROS Robot

SUMMARY

This document mainly explains the usage of the multi-robot formation function package named wheeltec_multi.

This document is divided into four parts:

• The first part is mainly about the introduction of the multi-robot formation method;
• the second part mainly describes the ROS multi-machine communication settings, including ROS construction of multi-machine communication and the problems that may be encountered in the process of ROS communication;
• the third part mainly describes the operation steps of multi-machine time synchronization;
• the fourth part expounds the specific use of the multi-machine formation function package.

The purpose of this document is an introduction to multi-agent robotic system and allows user to start the multi-robot formation project quickly.

INTRODUCTION TO MULTI-AGENT ALGORITHMS

Multi-agent formation algorithms

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.

Obstacle avoidance algorithms

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 SETUP

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

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.

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 multimachine 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.

7. You can use the Little Turtle simulation demo to verify whether the communication between the robots is successful:
   a. Run from the master
   roscore #launch ROS services
   rosrun turtlesim turtlesim_node #launch turtlesim interface
   b. Run from the slave
   rosrun turtlesim turtle_teleop_key #launch keyboard control node for turtlesim

If you can manipulate the turtle movements from the keyboard on the slave, it means the master/slave communication has been established successfully.

Automatic Wifi connection in ROS

The below procedures explain how to configure the robot to automatically connect to the host network or router network.

Automatic Wifi connection setup for Jetson Nano

1. Connect Jetson Nano via VNC remote tool or directly to the computer screen. Click on wifi icon on the top right corner then click “Edit Connections..”
   

2. Click the + button in Network Connections:
   

3. Under the “Choose a Connection Type” window, click the drop-down menu and click “Create…” button:
   

4. In Control Panel, click Wifi option. Enter the Wifi name to connect in “Connection Name” and SSID fields. Select “Client” in “Mode” dropdown menu and select “wlan0” in “Device” dropdown menu.
   

5. In Control Panel, click the “General” option and check “Automatically connect to this network…”. Set the connection priority to 1 in the “Connection priority for auto-activation” option. Check “All users may connect to this network” option. When the option is set to 0 in “Connection priority for auto-activation” for other wifi, this means this is the preferred wifi network in the past.
   

6. Click “Wi-Fi Security” option in Control Panel. Select “WPA & WPA2 Personal” in “Security” field. Then enter the Wifi password in
   

Note :

If the robot cannot automatically connect to the wifi network after booting when the wifi priority is set to 0, it may be caused by a problem of weak wifi signal. In order to avoid this problem, you can choose to delete all the wifi options that have been connected in the past. Only keep the wifi network created by the host or the router.

Click the “IPv4 Settings” option in the network settings control panel. Select “Manual” option in the “Method” field. Then click “Add”, fill in the IP address of the slave machine in “Address” field. Fill in “24” in “Netmask” field. Fill in the IP network segment in “Gateway”. Change the last three digits of the IP network segment to “1”. The main purpose of this step is to fix the IP address. After this is completed for the first time, the IP address will remain unchanged when connecting to the same WIFI subsequently.

After all settings are configured, click “save” to save the settings. After the saving is successful, the robot will automatically connect to the network of the host or router when it is powered on.

Note :

1. The IP address set here needs to be the same as the IP address set in the .bashrc file in Section 2.1.
2. The IP address of the master and each slave must be unique.
3. The master and slave IP addresses need to be in the same network segment.
4. You must wait for the host or router to send out WiFi signal before the slave robot can be powered on and automatically connect to the WiFi network.
5. After the setting is configured, if the robot cannot automatically connect to the WiFi when it is turned on, please plug and unplug the network card and try connecting again.

Automatic Wifi connection setup for Raspberry Pi

The procedure for Raspberry Pi is the same as Jetson Nano.

Automatic Wifi connection setup for Jetson TX1

The setup in Jetson TX1 is almost the same as in Jetson Nano with one exception that Jetson TX1 should select the device of “wlan1” in “Device” in the network settings control panel.

MULTI-AGENT SYNCHRONISATION SETUP

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.

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.

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.

sudo date -s “2022-01-30 15:15:00” # Manual time setup

MULTI-AGENT ROS PACKAGE

ROS Package Introduction

Set up slave name

n 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.

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.

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, as shown in Figure 4-1-3.

If the user wants to customize the initial position of the slave, he or she only needs to set the slave_x and slave_y values as shown in Figure 4-1-4 in wheeltec_slave.launch. The slave_x and slave_y values will be passed to turn_on_wheeltec_robot.launch and assigned to the pose_setter node. Just place the robot in a custom position before running the program.

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.

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.

The relevant parameters of the formation algorithm are as follows:

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.

Operation Procedure

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

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>