Welcome to ROSMASTER X3 repository

1. Multi-machine handle control

1.1. Multi-machine configuration

When using multi-machine handle control, you first need to ensure that the robots are under the same LAN and configured with the same [ROS_MASTER_URI]; multiple robots can only have one host to control their movements. In the case of this section, the virtual machine is set as the host machine, and other robots are slave machines. There are several slave machines. Of course, you can also set a certain robot as the master machine and the others as slave machines.

1.1.1. Multi-machine communication settings

Check the IP of the virtual machine

xxxxxxxxxx
ifconfig

xxxxxxxxxx
#Raspberry Pi 5 master needs to enter docker first, please perform this step
#If running the script into docker fails, please refer to ROS/07, Docker tutorial
~/run_docker.sh

Next, you only need to modify the .bashrc file of the slave machine (Robot side). There are several slave machines and several configurations.

xxxxxxxxxx
sudo vim ~/.bashrc

Find the following line of content

xxxxxxxxxx
export ROS_MASTER_URI=http://IP:11311

The [IP] here uses the IP (virtual machine side).

xxxxxxxxxx
export ROS_MASTER_URI=http://192.168.2.106:11311

After setting the IP, it is best to refresh the environment variables.

xxxxxxxxxx
source ~/.bashrc

1.1.2. Multi-machine time synchronization

Install

xxxxxxxxxx
sudo apt install ntp ntpdate

time view command

xxxxxxxxxx
date -R

When there is a network, the system will automatically synchronize the network system time without setting. If there is no network, the time needs to be set when the time between robots is different.

• Internet available

Automatically synchronize network time command

xxxxxxxxxx
ntpd pool ntp.ubuntu.com

• No network

The test case is using two robots.

Command to manually set time

xxxxxxxxxx
sudo date -s "2020-01-1 01:01:01"

1), Server-side (host-side) configuration

Open the [ntp.conf] file

xxxxxxxxxx
sudo vim /etc/ntp.conf

Add at the end of the file

xxxxxxxxxx
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

The first line is to enable the machine on the 192.168.2.xxx network segment to synchronize time with this machine (specifically, it depends on whether your IP is 192.168.2.xxx. If it is different, change it to your actual format) The second and third lines are for time synchronization between the local hardware time and the local ntp service.

After making the changes, restart the ntp service

xxxxxxxxxx
sudo /etc/init.d/ntp restart

The server-side settings are completed, let’s start the client-side settings.

2. Client (slave side) configuration

Open the [ntp.conf] file

xxxxxxxxxx
sudo vim /etc/ntp.conf

Add [server]+[IP] at the end of the file

xxxxxxxxxx
server 192.168.2.106

3), time synchronization

On the [server side], execute the following code to check whether the ntp service of the [server side] is running.

xxxxxxxxxx
service ntp status

If it is not started, restart the ntp service.

Network updates (required for all devices)

xxxxxxxxxx
sudo /etc/init.d/networking restart

Time synchronization

xxxxxxxxxx
sudo ntpdate 192.168.2.106

If the client's NTP is also enabled, you need to close the NTP service first and then perform time synchronization.

xxxxxxxxxx
sudo /etc/init.d/ntp stop

1.2. Use

Take the virtual machine as the host machine and the two robots as slave machines as an example.

1.2.1. Start the robot

Virtual machine side

xxxxxxxxxx
roscore

Start the command (robot1 side). For the convenience of operation, this section takes [mono + laser + yahboomcar] as an example.

xxxxxxxxxx
roslaunch yahboomcar_multi laser_bringup_multi.launch ns:=robot1 # laser + yahboomcar
roslaunch yahboomcar_multi laser_usb_bringup_multi.launch ns:=robot1 # mono + laser + yahboomcar
roslaunch yahboomcar_multi laser_astrapro_bringup_multi.launch ns:=robot1 # Astra + laser + yahboomcar

Start the command (robot2 side). For the convenience of operation, this section takes [mono + laser + yahboomcar] as an example.

xxxxxxxxxx
roslaunch yahboomcar_multi laser_bringup_multi.launch ns:=robot2 # laser + yahboomcar
roslaunch yahboomcar_multi laser_usb_bringup_multi.launch ns:=robot2 # mono + laser + yahboomcar
roslaunch yahboomcar_multi laser_astrapro_bringup_multi.launch ns:=robot2 # Astra + laser + yahboomcar

More robots and so on.

1.2.2. Turn on handle control

Method 1: One controller controls multiple robots at the same time

Connect the controller receiver to the USB port of the virtual machine and start the command

xxxxxxxxxx
roslaunch yahboomcar_multi joy_multi.launch

Note: The [launch] file defaults to three robots.

joy_multi.launch

xxxxxxxxxx
<launch>
     <arg name="first_robot1" default="robot1"/>
     <arg name="second_robot2" default="robot2"/>
     <arg name="third_robot3" default="robot3"/>
     <param name="use_sim_time" value="false"/>
     <node name="joy_node" pkg="joy" type="joy_node" output="screen" respawn="false"/>
     <!-- ############################ first_robot1 ################ ############# -->
     <include file="$(find yahboomcar_multi)/launch/library/joy_base.launch">
         <arg name="ns" default="$(arg first_robot1)"/>
     </include>
     <!-- ############################ second_robot2 ################ ############# -->
     <include file="$(find yahboomcar_multi)/launch/library/joy_base.launch">
         <arg name="ns" default="$(arg second_robot2)"/>
     </include>
     <!-- ############################ third_robot3 ################ ############# -->
     <include file="$(find yahboomcar_multi)/launch/library/joy_base.launch">
         <arg name="ns" default="$(arg third_robot3)"/>
     </include>
</launch>

If there are 2 robots, just comment out the part of the third robot. If you don't comment it out, it will not have any effect. If there are 4 robots or more, you can add it according to the samples of the first 3 robots.

Method 2: One handle controls one robot alone

<PI5 needs to open another terminal to enter the same docker container

Connect the handle receiver to the corresponding robot, and start the command on the corresponding robot side (take robot1 as an example)

xxxxxxxxxx
roslaunch yahboomcar_multi joy_each.launch ns:=robot1

1.3. Handle control analysis

Node view

xxxxxxxxxx
rqt_graph

1.3.1. Control multiple robots

It can be seen from the figure that when one controller controls multiple robots at the same time, only one [joy_node] node is needed to receive the controller signal, and different [yahboom_joy] nodes are set for different robots to control the corresponding robots.

1.3.2. Control a robot

It can be seen from the figure that when a handle controls a robot, each robot must be set and controlled separately.