Welcome to RDK X3 Robot repository
1. Multi-vehicle synchronous control
1. Multi-vehicle synchronous control
1.1. Program Function Description
Connect the handle to the virtual machine end, set the virtual machine to connect to the handle, after the program of the virtual machine and car end is started, you can control two cars at the same time through the handle, and the movements of the two cars are synchronous.
1.2. Program Reference Path
After SSH connecting the car, the location of the source code of this function is located at.
xxxxxxxxxx~/yahboomcar_ws/src/yahboomcar_multi/launch/yahboomcar_bringup_multi_ctrl.launch.xml
The VM-side control code location is located at.
xxxxxxxxxx~/dev_ws/src/yahboomcar_multi/launch/multi_ctrl.launch.xml
1.3 Starting the programme
Note: Here you need to set up multi-machine communication in advance, that is, the virtual machine and the car (two cars as an example) need to be on the same LAN and ROS_DOMAIN_ID must be the same, in order to be able to carry out distributed communication. Setting method reference: [06] development environment setup -> [4], multi-machine communication configuration, setup and verification.
VM terminal input.
xxxxxxxxxxros2 launch yahboomcar_multi multi_ctrl.launch.xml
After SSH connecting to car 1, the terminal enters.
xxxxxxxxxxros2 launch yahboomcar_multi yahboomcar_bringup_multi_ctrl.launch.xml robot_name:=robot1
After SSH connecting to car 2, the terminal enters.
xxxxxxxxxxros2 launch yahboomcar_multi yahboomcar_bringup_multi_ctrl.launch.xml robot_name:=robot2
After the programme starts, press L1 to enter the control.
1.4. Viewing the node communication map
VM terminal input.
xxxxxxxxxxros2 run rqt_graph rqt_graph
As can be seen, the VM publishes the /cmd_vel topic speed, to which the chassis of robot1 and robot2 are subscribed, so when the VM publishes the topic data, both cars receive it, which in turn controls the movement of their respective chassis.
1.5. Core Code Analysis
The code on the virtual machine side is the same as the handle control code on the car side, so we won't go into details here, and we will mainly look at the contents of the car side, and look at the startup file yahboomcar_bringup_multi_ctrl.launch.xml.
xxxxxxxxxx<launch> <arg name="robot_name" default="robot1"/> <group> <push-ros-namespace namespace="$(var robot_name)"/> <!--driver_node--> <node name="driver" pkg="yahboomcar_bringup" exec="Mcnamu_driver" output="screen"> <param name="imu_link" value="$(var robot_name)/imu_link"/> <remap from="cmd_vel" to="/cmd_vel"/> </node> <!--base_node--> <node name="base" pkg="yahboomcar_base_node" exec="base_node" output="screen"> <param name="odom_frame" value="$(var robot_name)/odom"/> <param name="base_footprint_frame" value="$(var robot_name)/base_footprint"/> </node> <!--imu_filter_node--> <node name="imu_filter" pkg="imu_filter_madgwick" exec="imu_filter_madgwick_node" output="screen"> <param name="fixed_frame" value="$(var robot_name)/base_link"/> <param name="use_mag" value="false"/> <param name="publish_tf" value="false"/> <param name="world_frame" value="$(var robot_name)/enu"/> <param name="orientation_stddev" value="0.05"/> </node> <!--ekf_node--> <node name="ekf_filter_node" pkg="robot_localization" exec="ekf_node"> <param name="odom_frame" value="$(var robot_name)/odom"/> <param name="base_link_frame" value="$(var robot_name)/base_footprint"/> <param name="world_frame" value="$(var robot_name)/odom"/> <param from="$(find-pkg-share yahboomcar_multi)/param/ekf_$(var robot_name).yaml"/> <remap from="odometry/filtered" to="odom"/> <remap from="/odom_raw" to="odom_raw"/> </node> </group> <include file="$(find-pkg-share yahboomcar_description)/launch/description_multi_$(var robot_name).launch.py"/></launch>Here we use the xml format to write the launch file, which is convenient for us to add namespaces in front of multiple nodes. Add namespace is to solve the conflict generated by the same name of the node, we have two cars here, take the chassis program, if the two chassis node name are driver, then the establishment of the multi-machine communication, this is not allowed, so we will add the namespace before the name of the node, so that the name of the chassis node of car 1 is / robot1/driver, car 2 chassis node program is / robot2/driver, the chassis node program is / robot2/driver. robot1/driver, and the chassis node program for robot2 is /robot2/driver. in the XML-formatted launch file, a group is used to specify that within this group, both node names and topic names need to be prefixed with the namespace.
xxxxxxxxxx<group> <push-ros-namespace namespace="$(var robot_name)"/></group>Parameters defined in the launch file are referenced in XML format using $(var robot_name). The parameter passed in here is robot_name, which can be entered on the command line when typing the command.
xxxxxxxxxxros2 launch yahboomcar_multi yahboomcar_bringup_multi_ctrl.launch.xml robot_name:=robot1
One thing to note here is that after we added the namespace, we then remapped the topic name of /robot1/cmd_vel to /cmd_vel, this is to be able to receive topic messages from the VM.
xxxxxxxxxx<node name="driver" pkg="yahboomcar_bringup" exec="Mcnamu_driver" output="screen"> <param name="imu_link" value="$(var robot_name)/imu_link"/> <remap from="cmd_vel" to="/cmd_vel"/></node>Regarding the incoming parameters, plus the namespace is to be stated in the launch file, for example the following parameters, the
xxxxxxxxxx<node name="base" pkg="yahboomcar_base_node" exec="base_node" output="screen"> <param name="odom_frame" value="$(var robot_name)/odom"/> <param name="base_footprint_frame" value="$(var robot_name)/base_footprint"/></node>As you can see, the odom_frame parameter is assigned as $(var robot_name)/odom and the base_footprint_frame parameter is assigned as $(var robot_name)/base_footprint.
If there are parameters that don't need to be namespaced, then they are passed in as a parameter list, e.g., the
xxxxxxxxxx