Project 1: Student Feedback


If you recall, on the page, we requested that you submit the following:

  • a text file called 'LESSONS' in the root directory that lists the following things:
    • all of the secrets that you wish you knew at the beginning of the project about matlab/ros/gazebo/planning
    • all of the project details that you felt should have been posted on the wiki at the start of the project but weren't

We thank you very much for your input! We hope to use your suggestions and feedback to improve the course for future students. Below is what you and your classmates had to say...




Overall, I was pretty satisfied by the amount of information that was provided for the project, and the ROS background that was required. I thought that the amount of information that was posted for the project was appropriate. So were the instructions for ros/gazebo/planning/matlab. I have no complaints whatsoever.


Things I wish I knew before: (and still do)

- How to use RVIZ for vizualization. I missed class for a while though, so maybe this had been covered. - How to debug in ROS better. Segmentation faults were pretty hard to debug. The only debugging experience I've had is with MATLAB and MS Visual C# (which has a pretty darn good debugger).

Project details that I wish were posted before:

- I thought things were posted at a decent enough time.


The biggest secret that I wish I had known was to use the ground truth pose in order to evaluate how bad the odometry was. I also wish that the world files had been correct from the start. Finally, don't try to run Ubuntu in VMWare on a mac with Gazebo + RVIZ: use the ROSLab.


The following were things I wish I had known going into the project.

  • How to create filled circles on an image in matlab.
  • How to change the color pallete for an image in matlab.

I strongly feel that the following things should have been posted in the wiki during the course of the project.

  • Standards for controller (How much error is considered acceptable and how fast should the robot drive).
  • Dimensions of robot. These were required for writing the controller.

Secrets I wish I knew: Write your controller in whatever language you write your planner in, otherwise interfacing them will waste precious time

Project Details that should have been posted but weren't: They were all fine, but it might have been nice to have all the details finalized earlier for each phase


1) A* doesn't care if it is cutting too close to an obstacle. You need to either pad the obstacles out so much that they can't impact, or introduce a potential field push the robot away from the obstacles.

2) Odometry is a horrible measure of where you are. The errors are cumulative, so the longer you roll, the worse your prediction of where you are gets. In addition, if you brush against, let alone bump, anything, your data is all wrong. We have sensors people, lets use them!

3) Well-engineered code and controllers can often be beaten with the simplest, dumbest hacks you can find. Don't make it any more complicated than it absolutely has to be. (This is an old lesson for me, but I tend to get it drummed into me by life on a regular basis)

4) Version control saved my sanity multiple times. It allowed me the freedom to rip apart large amounts of working code without regard to rolling back to a known-good copy because I always had a known-good copy committed to the repository.

As for the wiki, it was fairly clear. Once the world files were up, we could experiment and ask questions as necessary. My suggestion would be to get them up earlier, so that we'd have more time to test what we're doing. Other than that, no complaints.


1) I didn't know Linux/ROS/gazebo at all, and I would have liked better tutorials for how to install it on my home computer. I did dual boot my home computer with Ubuntu, but I could not get MATLAB, ROS, gazebo and the ipc bridge to work harmoniously together; I always had to come to the ROS lab, which is just how it is I suppose.

2) We did not go into depth about A* and I had never really programmed an algorithm of this nature before, so a little more info on implementation would have been nice. The general ideas are easy and relatively intuitive, but sitting down and writing it was difficult.

3) I actually implemented the controller verbatim and it worked really well except for acute turns. The fact that it was a 'broken' controller would have been nice to know from the get-go.

4) Finally, the gazebo simulation did not act the same every time, I suppose the noise from the odometry... .


Secrets I wish I knew at the beginning: 1.Matlab is really horrible with large loops, I should try my best to avoid large loops. 2.The parameters of controll part have some reasonable range and we should choose them carefully to avoid driving the robot crazy.

Project details may be added to wiki:

  1. What kind of information we can get from odometry, and how to convert the information to parameters we need in the controller, for example,the relationship between w and theta.
  2. Odometry gets robot position relatively to the start position, if the planner give a path of the world map and the start point is not (0,0), add the start position value to odometry position can easily match the controller with the planner.

The robot's odometry starts @ 0,0 no matter where it is on the map

The control distance L can cause singularities even if it is a small value (not just zero)

There is noise introduced into the Gazebo world

There is not an easy way to control the theta of the robot while turning


  • Integrate logging and visualization from the get-go. Make it principled and useful. I really should know better on this one, having failed miserably on this front several times.
  • Learn useful recipes for mencoder / ffmpeg / etc.
  • Coordinate system, coordinate systems, coordinate systems
    • i.e. planner's "knowledge" vs. the robot's knowledge/odometry
  • Using GDB with roslaunch...
    • Why, oh why do my messages get lost (i.e. no odometry) when using gdb launch-prefix? It seems like a simulation/time problem, but I can't figure it out.

  1. The odometry is not accurate.
  2. Random noise affects the path taken, so trial runs can yield different results.
  3. Although the robot can travel at 2m/s, slippage occurs unless the robot travels at less than 0.5m/s.
  4. The optimal path is too narrow. The robot travels too close to the obstacles.
  5. The c-space needs to be padded with a much larger radius than the true robot radius.
  6. Gazebo crashes when minimized...
  7. Gazebo and Matlab both need to be restarted every time you want to rerun the code.
  8. glc (wrapping Gazebo) records everything overlaying the Gazebo window, so you need to keep Gazebo on top of all other windows.
  9. While encoding the video using glc, you see a misleading constant 0% in progress until it finishes encoding.
  10. Making the A* heuristic inadmissible allows paths to be found more quickly, but the paths are not optimal.

MATLAB implementation

  • The feature Desktop -> Profiler is very useful for improving code. It tells you how much time each section of code takes and really helped speed up my code. As a non-CS person, finding out about this was pretty amazing.
  • MATLAB does not like for loops, they run pretty slowly for reason. Vectorizing things really speeds it up.

ROS things

  • When using the ipc bridge, make sure that the launch file for Gazebo has the ipc nodes in it. A lot of staring at the screen wondering why it won't talk to the robot will be saved by checking this first.

Things I wish I had

  • For each phase, it would have been nice to have environment files (either final or just examples) posted earlier so I could get an earlier start on some of this.
  • Posting all the phases at the start (at least a high-level description) would have been nice so I could make the different pieces easier to integrate together.
  • More experience with Linux. Before this project I had only used Windows, so it took some getting used to. Having a link to a tutorial, or a brief summary of common terminal commands such as ls, less, mv, and rm would be nice for new users. Talking to fellow students and turning to Google works for the most part, but a centralized reference like this would have saved me some time/headaches. Ben Charrow told me about this site a little while back:

Secrets: Just use the ROSLab machines. That way, MATLAB works fantastically, and you need not worry about setting anything up on your own computer. Everything works well here!

Details: I don't think there were any details missing, save for "objectives" of each stage. For Phase 2, it was clear that speed was the objective, but in Phase 3, I was not sure if position error, velocity error, or time to completion was the objective.


Things I wish I knew at the beginning or could have benefited from if there was a wiki on the subject

> How to use RViz correctly (understanding the frames etc) - this would have been great to visualize the path the robot was taking during the simulation rather than plotting the paths at the end

> Tips for efficient planning and control