Day 4

Today

    • Proportional Control
    • Gazebo
    • Work on Warmup Project

For Next Time

    • Work on Warmup Project
    • Be ready to discuss your strategies / challenges in implementing the behaviors

Proportional Control

Last class we programmed robots that would choose between a small set of motor commands (move forward, turn left, etc.) based on sensor readings. Today, we will be experimenting with a slightly different control architecture where the magnitude of the motor command is proportional to the error between the robot's current position and the desired position.

To get the idea, program the Neato to adjust its position so that it is a specified (target) distance away from the wall immediately in front of it. The Neato's forward velocity should be proportional to the error between the target distance and its current distance. Note: it's tricky to get the sign correct, run through a few mental simulations to make sure the robot will move in the right direction.

A helpful tool for visualizing the results of your program is to use the rqt_gui tool. First, start up the GUI:

$ rosrun rqt_gui rqt_gui

Next, go to plugins -> visualization -> plot.

Type /scan/ranges[0] (if that is in fact what you used to calculate forward distance) into the topic field and then hit +.

To make your node more configurable, use (see rosparam and topic remapping for more information). For instance, if you want to make the target_distance configurable, consider launching your node like this:

$ rosrun  in_class_day04_section2 wall_approach.py _target_distance:=1.5 _k:=0.5

To access the parameter inside of your Python code use:

target_distance = rospy.get_param('~target_distance')

For more depth in this area, read up on PID control.

Gazebo

Robotic simulators can be useful for tuning your robotic algorithms. A simulator allows a virtual robot to drive around in a virtual environment. The effect of its motor commands on the environment and the sensations the robot would get if it were in a particular situation are also provided by the simulator.

A few questions:

    1. When might a simulator be useful?
    2. Is rviz a simulator? Why or why not?
    3. When might a simulator be not so useful?

ROS comes with a simulator called Gazebo. To startup the simulator, run the following command:

$ roslaunch neato_simulator neato_playground.launch

If this is your first time running the simulator, you may have to wait a while for the simulator to download the appropriate model files.

If you happened to have a connection to the robot when you ran the command above you are probably seeing a lot of warning messages like these:

[ WARN] [1442331399.383284631]: TF_OLD_DATA ignoring data from the past for frame base_laser_link at time 259.9 according to authority unknown_publisher
Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained

The reason for this is that Gazebo uses publishes its own clock rather than using the system clock (which is what happens when you use the real robot). To understand this better type:

$ rostopic echo /clock

And you will see what Gazebo thinks the time is. This is very different than the system clock which is based on the number of seconds that have elapsed since January 1st, 1970 (see Unix time).

Part of what rospy.init_node does is initialize ROS time. Depending on whether you are using a simulated robot or a real robot, ROS time will either use the /clock topic or the system time. In most cases you won't have to worry about this since if a node starts up while the simulator is already running it will automatically use the /clock topic. You will run into trouble, however, in the following scenarios:

    1. You had a node running with the real robot, and now you fire up the simulator. This will cause the nodes that were initially running to use the system clock while any new nodes and the simulator will use the /clock topic.
    2. You were running the simulator, and now you fire up the real robot. Even if you have closed the simulator, sometimes the new nodes will still use the /clock topic.

There are less heavy-handed ways of fixing this, but I recommend shutting down all ROS nodes (including roscore), and starting fresh whenever you switch between using the simulator and the real robot.

Exercise: try moving the robot around. Visualize the results using rviz. Probe the topics of the simulated robot using $ rostopic list. What are the similarities with the real robot, what are the differences? Try running some of your proportional controllers you coded earlier in class. Do they work with the simulated robot?