Last updated Sept 30, 2006, 2:15pm
Simulation and Logged Data
In Lab 1, an invaluable productivity tool for you was the
fake-car-imu-odo module, which simulated IMU and odometry outputs
based on the gas/steer inputs of an imaginary car. This allowed you to
implement and finish most of your code for the dead-reckoner and controller
before you tested on the real vehicle. By the time you ran your code on the
real vehicle, only refinement was necessary.
In Lab 2 it is also important to be able to write and test code without
constantly requiring the real robot. Since simulating laser scans and camera
data is more difficult than IMU/odometry, we will provide real data, logged
from a sample run of the robot. These data logs will allow you to test your
algorithms on the same data repeatedly in order to improve performance on a
data set that does not change for every run and allows you to work anywhere.
The only drawback of a log file compared to a full simulation is that with the
log, any control inputs generated by your algorithm will have no effect on the
robot's movements. You will have to use the real hardware in order to close
the control loop.
Getting the logs
To get the log files on a machine that does not already have them, run these
commands:
cd /tmp
wget http://courses.csail.mit.edu/6.142/fall2006/pub/labs/laser-2006-09-26
wget http://courses.csail.mit.edu/6.142/fall2006/pub/labs/camera-2006-09-28
Note that these instructions place both logs in the /tmp directory of the
machine, where any user can reach them, and they will not take up space on your
Athena account. Warning! The camera log file is 219MB in size, and you
will likely overflow your Athena quota if you attempt to download it to
your home directory.
Using the Laser Log File
In our software architecture for the DGC, we have a tool called logger
that records log files. It simply listens to any traffic that occurs over LC, and
saves each data packet to a file. There is another tool logplayer
which reads the file and resends all the LC packets over the network. Thus,
modules that receive these retransmitted packets will behave just as if they
were running on the live robot. For example, to retransmit the data from the
laser log file, from the software/bin directory run:
./logplayer -f IMU,ODOMETRY_UPDATE,LASER /tmp/laser-2006-09-26
This means that only the IMU, odometry, and laser packets will be played back.
Other data will be ignored. At this point, any other modules such as dead-reckon
and viewer can be started that will use the data. We have provided a procman
configuration file that does just that. From the software/bin directory, run:
./procman_simple ../config/pm-play-laser-data.txt
This command will spawn the log playback, the dead-reckoner, and the viewer.
You will see the raw laser scans denoted by red dots (each return from a
laser reflection is a single dot, of which there are 180 per scan). The robot
will move forward, weaving through a number of obstacles. Once your own obstacle
avoider is ready for test, run it along side these modules on this sample data.
Although you will obviously not be able to affect the path of the logged robot,
you can visualize the desired trajectories computed by your algorithm and ensure
that they are correct. Feel free to modify the viewer to include any of this
necessary visualization. Important: If you make modifications to the
viewer, please send them to the TAs so that we may update everyone's copy of the
viewer. This will make integration easier when the time comes.
Your task for Lab 2 is to listen to the messages of type laser_t
being transmitted, generate an obstacle map, plan a safe trajectory, and
emit gas/steer messages that execute the trajectory. Naturally, you will
probably want to draw on your experience from Lab 1 in converting your
desired trajectory into gas/steer messages.
Using the Real Laser Scanner
The laser scanner is manufactured by a company in Germany called SICK. We
have provided a module called sick that connects to the laser
scanner and manages the low-level communications. It then broadcasts LC
messages of type laser_t at approximately 75 Hz which you will
use in your obstacle avoider.
Using the Camera Log File
Since live camera data has such high bandwidth, it is not suitable for
transmission between modules using LC/LCM. Instead, the vision processing all
takes place in a single application. We are providing a relatively complete
set of software for reading camera data and making it available to your
application. The source code in
software/src/rss-lane-finder/rss-lane-finder.c should serve
as your starting point. On line 210 a call to
slf_find_lane_center() is made, where the bulk of the vision
processing occurs. Naturally, we are not providing that code,
but we are including a number of useful code routines as discussed in the
lab handout, such as code to find connected components.
The logged video can be viewed (with no vision processing) using the
application camview. Incidentally, the live camera can also be
viewed with this application. The view the log file, start
camview, select Filters->"Add Bayer Demosaic", then select
Filters->"Add OpenGL Output", then select File->"Open Log File...",
select /tmp/camera-2006-09-28, and click OK. The video should start
playing.
The application rss-lane-finder can also read from the
log. To do that, run:
./rss_lane_finder -l /tmp/camera-2006-09-28 -g 60 255 255 20 200 160
The first three numbers are the target Hue, Saturation, and Value of the lane
markings. The last three are the thresholds for those quantities. In other
words, hue must be between 40-80, saturation between 55-255, and value between
95-255 in order to classify a pixel as part of a lane marking. You will most
likely have to modify these values depending on the lighting and exposure
settings during a test run of your own. If you want to find a good set of
values, take a screenshot of camview as it is running using an
image editing program such as The GIMP. Use the eyedropper tool in HSV mode to
inspect the color of the line markings. Note that most image editing programs
display these three values in range of 0-360, 0-100, and 0-100 instead of the
0-255 used by rss_lane_finder, requiring you to scale
accordingly.