Designing and implementing a slightly more complicated ROS program
- Teleop is a common term for “remote controlling” a robot
- It’s a perfectly respectable way go, and there are plenty of real world examples which are teleoperated
- Campus Rover will be autonomous, meaning there’s no person overtly streering it
- That does not preclude, for example, having a person give commands to the robot, like where to go
- CampusRobot will have a small tablet interface mounted on it to give it commands
- That tablet will be directly wired to the robot (as it is mounted!)
- Notice that with a slightly more capable computer (processor, memory and storage) directly mounted on the robot it is perfectly possible to run roscore directly on the robot
- Recall that Topics are the names of the publish/subscribe “channels” and the content that is sent and received is a Message.
/cmd_vel messages tell a mobile robots ‘base’ to move in all the possible directions
- Depending on the hardware and type of robot, it has up to 6 degrees of freedom to move
- Our robots can move forward (and backward) and can spin (left or right) in place, or both at the same time. They cannot go sideways, up or down or pitch (tip forward) or yaw (tip sideways). Drones can go in all 6
- The message type sent over
- which includes two fields,
- each of which has an
- Notice that Twist is generic and general, but depending on what kind of robot is receiving it, there are limits in which direction it will be told to move.
- Notice also that Twist is about motion, not about location
Lab Instruction: rostopic and rosmsg
rosmsg to examine /cmd_vel topic and Twist message
Structure of an “idiomatic” ROS program
- ROS is distributed, with nodes talking to each other
- Nodes should be small and have one job
- Make nodes small and simple
- Use a
.launch file to launch all the nodes at once.
- Node 1 - Keyboard Driver
- listens to keystrokes, interprets them
- Publishes the ‘semantic’ commands
- Node 2
- Subscribes to ‘semantic’ commands
Lab Instruction: Keyboard Driver
- You can find key_publisher.py in the src/prrexamples directory. If it’s not there try doing a git pull.
- You will need two Terminals (plus roscore running somewhere)
rosrun roscore key_publisher.py
rostopic echo keys
- Verify that the topic is being published any time a key is pressed
- All that is happening is that the letter is being sent as the content of the message
- If the letter is not printable then you won’t be able to see it
- Questions to ponder:
- Could you write a graphical interface to control the robot given what you know?
- What features could you add to the basic key_publisher.rb?
Lab Instruction: Motion Generator
- You can find keys_to_twist.py in the src/prrexamples directory
- Run it with key_publisher from before and then monitor both topics with two separate instances of rostopic echo. This will require two terminals!
- Questions to ponder:
- How are you going to test it?
- Does it work?
- How long will the robot move in the requested direction as the result of a single cmd_vel?
Lab Instruction: Generating a stream of cmd_vel
- We will update the program to generate a stream of cmd_vels, around 10 per second
- You can find keys_to_twist_using_rate.py in the src/prrexamples directory. If it is not there try doing a git pull.
- Run it and verify that it works
- How would you verify that?
- Try running
$ rqt_plot to view the information in a graph
Where we are
- Two nodes:
- key_publisher: waits for user input and publishes the keys typed on topic
- keys_to_twist_using_rate: subscribes to
keys and generates cmd_vels based on decode
cmd_vel is published at a constant steady stream
- Meaning of the keys is part of
keys_to_twist_using_rate.py which to me is not a great Design
- Better would to keep the translation of a key to an intended motion inside key_publisher
- And instead of publishing the letters, publish something with semantic meaning, e.g.
- stop = cmd_stop
- turn left = cmd_turnleft
- turn right = cmd_turnright
- forward = cmd_forward
- backward = cmd_backward
- The encoding could be part of a class.
- Being a distributed operating system means brings configuration hassles
- Just about any code that is written will have some parameters, e.g. “how far from the wall should I get before trying to turn?”
- We know that hardwiring constants inside code is a very bad idea (at least for any kind of production code.)
- Usual way of providing parameters is either command line arguments or Environment variables
- Parameters are a ROS specific way, well adapted to the distributed nature
- Parameter server is ‘built into’ roscore and is a simple ‘key/value’ store
- Private and Public Parameters
- Private: node name is automatically pre-pended to parameter name to avoid name conflicts
- Public: parameter name “as-is”
- In this example we are running a script and at the same time assigning values to two private parameters
- They will be known as
keys_to_twist/angular_scale with values of 0.5 and 0.4 respectively
- The values can be accessed from the code as follows:
rospy.has_param('~linear_scale') => returns True or false
rospy.get_param('~linear_scale') => returns 0.5
~ tilde preceding the parameter name means that the parameter is “private”, which means that it is prepanded with the node’s name
- Oddly enough, the
- hyphen preceding the paratmer in the command line argument, means the same thing!
- A default value can be supplied
Lab Instruction: Command Line
- It is possible to set paramters directly from the command line
$ ./keys_to_twist_parameterized.py _linear_scale:=0.5 _angular_scale:=0.4
- When a robot with mass is commanded to change speed or direction too suddenly
- Cant defy physics so you can see misbehavior: skidding, slipping, shuddering, even damaging the motor
- So we overrule the human’s command and just change speed gradually and up to a maximum
- Take a close look at keys_to_twist_with_ramps.py
- Make sure you understand how the ramp works
Lab Instruction: Using Gazebo to test
- Gazebo is a simulator which can simulate physical things with 3d rendering and realistic physics
- In our case we configure it to simularte a tb3 and reasonable surroundings.
- Note that I have not gotten gazebo to run with any stability on VMWare
$ roslaunch turtlebot3_gazebo turtlebot3_world.launch
- If you look around the turtlebot3_gazebo package (
roscd turtlebot3_gazebo) you will see different ‘worlds’. These correspond to different initial configurations of obstacles, walls, bookcases, and so on.
- Dont forget that you need to have roscore running as well
- Unlike Gazebo, RViz is NOT a simulator
- RViz == ROS Visualization
- RViz visualizes the data coming through topics onto a 3D graphical world
- Note that in ROS, whenever a set of coordinates are given (x,y,z) they always are accompanied by a “frame of reference” (or a tf)
- The odometry TF has an origin where the robot was powered on (or where the odometry was most recently reset)
Lab Instruction: Running RViz
- You run rviz as follows with the fake robot. It comes up with a fake robot and the landscape
$ roslaunch turtlebot3_fake turtlebot3_fake.launch
- You can zoom and rotate and move around that world
- In order to run rviz with your actual robot you need two commands:
# In a terminal window:
$ roslaunch turtlebot3_bringup turtlebot3_remote.launch
# In a second separate terminal window:
$ rosrun rviz rviz -d `rospack find turtlebot3_description`/rviz/model.rviz