1. Multi-vehicle control

1. Program function description

Connect the handle to the virtual machine and set the virtual machine to connect to the handle. After the programs on the virtual machine and the car are started, you can control two cars at the same time through the handle, and the movements of the two cars are synchronized.

2. Program reference path

Raspberry Pi PI5 master control, you need to enter the docker container first, Orin motherboard does not need to enter,

The location of the function source code is

The file for virtual machine startup, the source code location is,

3. Program startup

Note: Here you need to set up multi-machine communication in advance, that is, the virtual machine and the car (taking two cars as an example) need to be in the same LAN and the car ros environment, the virtual machine's ROS_DOMAIN_ID must be the same, in order to be able to perform distributed communication. Setting method reference: [06], Linux operating system -> [04], multi-machine communication configuration

3.1, startup command

** For Raspberry Pi PI5 master control, you need to enter the docker container of car 1 and car 2 respectively, but you do not need to enter the docker container of Orin motherboard.**

According to the actual model, enter in the terminal

[robot_name] indicates the serial number of the vehicle to start. Currently, the program can choose to start robot1 and robot2.

3.2. View topic nodes

Enter the following command in the virtual machine terminal,

image-20230727101808020

3.3. View the node communication diagram

Enter the following command in the virtual machine terminal,

image-20230727101643106

It can be seen that the virtual machine published the topic speed of /cmd_vel, and the chassis of robot1 and robot2 have subscribed to the topic, so when the virtual machine publishes the topic data, both cars will receive it and then control the movement of their respective chassis.

4. Core code analysis

The code on the virtual machine side is the same as the handle control code on the car side. I won’t go into details here. We mainly look at the content of the car side and the startup.

The file takes the X3 car as an example. The startup file is X3_bringup_multi_ctrl.launch.xml.

The xml format is used here to write the launch file, which facilitates us to add namespaces in front of multiple nodes. Adding namespace is to solve the conflict caused by the same node name. We have two cars here. Take the chassis program as an example. If both chassis nodes are named driver, then after establishing multi-machine communication, this will not work. It is allowed, so we add the namespace namespace before the node name. In this way, the chassis node name of car 1 is /robot1/driver, and the chassis node program of car 2 is /robot2/driver. In the launch file in XML format, a group is used to specify that within this group, both the node name and the topic name need to be added with namespace.

To reference the parameters defined in the launch file in XML format, use $(var robot_name). The parameter passed in here is robot_name. When entering the command, you can enter it in the command line.

One thing to note here is that after adding the namespace, we remapped the topic name of /robot1/cmd_vel to /cmd_vel in order to receive topic messages sent by the virtual machine.

Regarding the passing of parameters, adding the namespace needs to be stated in the launch file, such as the following parameters,

It can be seen that the odom_frame parameter is assigned to $(var robot_name)/odom, and the base_footprint_frame parameter is assigned to $(var robot_name)/base_footprint.

If some parameters do not require a namespace, then pass them in in the form of a parameter list, for example,

What needs to be noted in this parameter table is that you need to add the namespace to find it accurately. If we start robot1, then the started node becomes robot1/ekf_filter_node, so the beginning of the parameter file should be,