ROS Nodes and Simulators (Tue Sep 10, lecture 4) previous next
Continuing with different ROS Nodes, visualizers and simulators

Homework due for today

Legend: : Participation (pass/fail) | : PDF | : Team | : Attachment

  1. Read PRR Chapters 5,6 (and then do the work using: 5: Actions, 6: Robots and Simulators). Think about the following warmup questions and write your responses to them:
    1. How many degrees of freedom does our TurtleBot3 have and what are they?
    2. If you wanted to have your TurtleBot3 drive one meter forwards and stop, take a guess at what you would publish
    3. What would be an example of a holonomic robot or vehicle? Can you say what you think it means?
    4. Please name any concepts, topics or words that you are still confused about, and what your major take-aways are from this reading.

    Deliverable: Write up your very brief answers to these questions.


PRR Chapter 5: Actions


  • Nodes: all code written for ROS is a Node
    • A node is like a process
    • You run it with, e.g. $ rosrun or (later) $ roslaunch
  • Topics: the fundamental way nodes communicate with each other
    • Topic names
    • Publishers and Subscribers
    • Message with data types
  • Services: Synchronous communication
    • Client/Server
    • Ask and answer
    • Like a function call


  • For long running activities, for example, navigate to somewhere
    • Activity is initiated
    • Activity announces that it has terminated (successfully or not.)
    • From time to time it reports its progress
  • When defined as an action, this corresponds to three submessages
    • Part1: the goal (initiate the request)
    • Part2: the result (report completion)
    • Part3: the action is running (status update)
  • See Github Code

Creating an Action

  • Analogous to topics and services
  • File now has three sections corresponding to the goal, result and feedback
  • Some tricky updates to CMakeList.txt and package.xml
  • cm for Catkin_make

Action Server (

  • Handles the three submessages (see
    1. Initialize node
    2. Declare that we want to serve action requests and start it
    3. Wait for callback to be called.
  • Run the server
    1. Notice that there are now 5 topics generated from that one Timer.action file. (rosmsg list)
    2. Notice that the messages associated with the actions also have had more information attached to them

Action Client (

  • Node which will now ask request an action
    1. Initialize node
    2. Declare that we want to be an action client, and start it
    3. Begin the ball rolling by sending the goal to the action server
    4. Now block and wait for the action to complete.
  • Run the client
    1. Notice that it displays the result of the fake action

Getting fancier - (

  • Callback of the sever handles all three parts
  • First called when the goal is sent
    1. Check whether the goal is reasonable and abort if not.
    2. Begin performing the action.
    3. Reguarly check whether preemption was requested
    4. Whenever desired, send a feedback message
    5. When done send completion message.

Getting fancier - (

  • Create node
  • Connect to action server
  • Send it the goal, while declaring handler for feedback calls
  • Wait for completion or abort.

PRR Chapter 6: Robots and Simulators

Building blocks

  • Robots are made up of many subsystems
  • Subsystems are ‘represented’ in the software
  • Actuation (e.g. wheels)
  • Sensing (e.g. cameras)
  • Computing (e.g. brains)


  • Wheels - Differential Drive
    • Differential drive: Turtlebot3
    • Turning by different speed on two or more wheels
    • Sometimes there is a caster
    • Can only move forward and backward.
    • Not up and down or (directly) sideways
    • With more than 2 wheels, or a track - skid teering
    • Cars have “ackerman” steering (4 wheels, 2 that can steer)
  • Holonomic - non-Holonomic
    • Holonomic - can move in any direction
  • Manipulator Arm
    • Degrees of freedom
    • Coordinate transforms


  • Rotates and uses a laser to measure distance to nearest obstacle
  • Returns a vector of values corresponding to the directions
Limitation Operates in a plane, like a disk. Can't detect an obstacle above or below the plane!
Visual Cameras
  • Webcam sees a color picture
  • Matrix of dots, each dot has a color
  • Dot[x,y] = {r,g,b}
  • Data can be processed for example with opencv
  • A lot of data and a lot of processing
  • Bandwidth limits
Depth Cameras
  • Like a Microsoft Kinect
  • In addition to {r,g,b} also has distance
  • iPhoneX


  • Our Turtlebots have:
    1. Arduino to control the motor. Also with various sensors, lights, and i/o ports. Board is from Robotis and is called OpenCR
    2. Raspberry Pi which runs Ubuntu Mate and ROS
  • Distributed environment, typically:
    1. ROSCORE running on our
    2. Some ROS nodes running on Raspberry Pi
    3. More Ros nodes running on a laptop or other computer
  • Workload is truly distributed across all of those
  • Eventually we may have to have a much beefier computer running all three
  • This would make the robot much more independent


  • Software to allow work even without actual robots
  • A series of nodes which:
    • publish topics that a robot would publish (e.g. /odom)
    • Subscribe to topics that a robot would (e.g. /cmd_vel)
    • Use a “physics engine” to simulate what would happen in the real world
  • For example, simulator
    • Maintains an imagenary x,y where the robot is right now
    • Maintains a 3-d model of the robot
    • Has 3-d models of obstacles like walls
    • Changes all these states based on motion commands it receives
    • Of course, much more complex
NB We will NOT be using simulators called STAGE or STDR
  • Gazebo
    • Really sophsticated 3d simulator plus visualization
    • Can do much more than Turtlebots
    • I have seen Gazebo models of a complete Amazon Warehouse Floor
    • With multiple Robots running around
  • RViz
    • While it looks similar, it is not a simulator
    • It “simply” visualizes topics that it subscribes
    • In a 3-d space

Next Class