Move a robot
This tutorial aims to take control of a pibot robot. A pibot is a turtlebot2 robot (based on a kobuki platform) equipped with a laser range to navigate in a cluttered environment and a Rapberry Pi3 to provide a ROS2 interface to the robot.
Connect the pibot:
The Rapberry Pi3 on each pibot are pre-configured with Ubuntu Server 22.04, ROS2 Iron, and all the necessary drivers for the robot.
- By default, the pibot connects to the IoT WiFi network.
- The robot's control nodes are automatically launched at pibot startup via the
mb6-tbot
service, which executes theminimal_launch.yaml
launch file from atbot_node
package.
(More details about the IMT driver packages for turtlebot2 on github)
To avoid any conflict in mesages, each pibot has its own ROS_DOMAIN_ID
.
ROS environment has to be configured proprely to interact with a robot.
For instance for the pibot20:
export ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET
export ROS_DOMAIN_ID=20
ros2 node list
ros2 topic list
Reminder: You can also explore the existing node with rqt_graph
.
Finally, you can try to take control in an available terminal with keyboard control:
ros2 run teleop_twist_keyboard teleop_twist_keyboard cmd_vel:=/multi/cmd_teleop
Close everything with ctrl-c
.
The teleop publishes a geometry_msgs twist
message.
It is composed of two vectors \((x, y, z)\), one for linear speed \((m/s)\), and the second for angular speed \((rad/s)\).
However a nonholonomic ground robot as the tbot would move only on x
and turn only on z
(It is not as free as a drone).
- Try to control the robot with
ros2 topic pub
command publishing in the navigation topic (/multi/cmd_nav
).
Tbot drivers integrate a subsumption multiplexer.
The node listens different topics with different priorities (by default: /multi/cmd_nav
and /multi/cmd_telop
) and filter the appropriate commands to send to the robot.
The topics cmd_nav
and cmd_telop
stend for autonomous navigation and operator teleoperate.
The human operator has a higher priority.
Publishing messages into cmd_telop
makes the multiplexer to trash the cmd_nav
commands.
A dedicated node to control
The goal is to create a process connecting a topic and publishing velocities as a twist message:
This tutorial supposes that you already perform the previous package tutorial and that you have a first package tutorial_pkg
to work on it.
- First we have to create a file for our script.
touch tutorial_pkg/scripts/test_move
- The script state that it requires python3 interpreter and it depends on several ROS2 resources.
#!/usr/bin/python3
import rclpy
from rclpy.node import Node
from geometry_msgs.msg import Twist
print("test_move :: START...")
- You can try that everything is correct by turning the script file executable and execute it:
In a shell:
chmod +x tutorial_pkg/scripts/test_move
./tutorial_pkg/scripts/test_move
- Finally, we must declare our node as one of the package node into
CMakeList.txt
and build again your packages. You can also addgeometry_msgs
as dependency on thepackage.xml
file.
colcon build
source ./install/local_setup.bash
Then, our node should be accessible from ros2
commands.
ros2 run tutorial_pkg test_move
A Simple Move order
The node we aim to generate is similar to talker
,
except that we publish a twist
message on the appropriate topic.
The callback method of our class would be
def timer_callback(self):
velocity = Twist()
# Feed Twist velocity values
...
# Publish
self._publisher.publish(velocity)
A look at the geometry_msgs
at index.ros.org
Inform that Twist is composed by \(2\) Vector3 attributs also in geometry_msgs
.
Velocities are in \(m.s^{-1}\) and \(\mathit{rad}.s^{-1}\).
Now, a ros2 run tutorial_pkg test_move
should continuously move the robot, with a constant speed.
Notice that you can also test your code on turtlesim
by changing the name of the topic.
Move Script
At the end we want our robot to follow a predefined choreography. Something like moving forward for \(X \mathit{cm}\) backward, turn left then turn right, etc. The choreography should end on the exact position it begins to perform an infinite loop safely.