This journal is maintained by Winlab summer interns Vamsi and Aniket, who are working on robotmobility. Unless otherwise noted, the entries are typed up by me (Aniket) and I refer to myself in first person for simplicity.

Week1 Week2

Week 3

6/18/07 – Day 11

Today was full of reading: reading the API, reading the User's guide, reading sample code, and reading the tutorials. We started using the behavior composer for the first time, and find it has some pretty nifty features. The essential command is behave. A behavior is something the robot does constantly, ask compared to a task which is generally a one time assignment. For example, a task might be to move across a room, whereas a behavior is to repeatedly check for obstacles and change course to avoid one.

We still cannot figure out how to compile our own code or generate makefiles. Instead, we have been writing small code snipets using the same filenames as those in the sample code, (eg simple.cpp) and using the makefiles provided with our fingers crossed.

Right now I believe the most important thing for us to understand is the last three tutorials in the navigation section. These are the tutorials about using vSlam and creating landmarks. Understanding this will be, in my opinion, the critical step towards successfully using the robots in wifi experiments.

Unfortunately (though not surprisingly) the code resists compiling. Navigation Tutorial !#4 is the introduction to vSlam, and consists of 4 programs, only the first of which actually works. This first program causes the robot to move in a "bow-tie" pattern, but does not demonstrate any of the map-building capabilites of the robot. The remaining tutorials give compile errors, often with this error:

error: extra qualification 'Evolution::OccupancyGrid::' on member 'distance_to_obstacle'

I sincerely hope we can overcome our compiler issues shortly. In the meantime, we have python to work in.

A complication we keep running into is that we do not have a joystick here at winlab to operate these robots, and while a joystick is not strictly required, much of the sample code assumes you have one. It is hard for us to study the sample code as we cannot see it in action. Additionally, a joystick is required to run the provided odometry calibration scripts (something we probably should have done by now). We plan to bring in some of our home gaming equipment tomorrow; Vamsi has a USB joystick and I have a USB xbox controller. Hopefully at least one of those will work and allow us to explore the sample code better.

6/19/07 - Day 12

We now feel like we really understand IR sensor calibration. An experiment on Bender shows that some careful manipulation of resource-config.xml makes a tremendous difference in the robot's obstacle avoidance capabilities. Calibration is as follows: First, configure the (x,y,z) coordinates and roll, pitch and yaw for each sensor (remember the origin is located on the floor directly between the back wheels). Then, in the section labeled <dimensions> under <Shape id="body…>, set the parameters (x,y,z) to the center of the robot with respect to the origin, and (lx,ly,lz) are the lengths of an imaginary rectangle which should encapsulate the robot.

Once these parameters are set, obstacle avoidance works very well. It is important to make sure the sensors are in fact pointing in the directions specified under (roll,pitch,yaw).

We played around with joysticks for a little today. Between us, we have one Destroyer Tilt and one MS XBox 360 controller. We were able to get the Tilt working but not the Xbox controller. Oddly however, different applications reacted differently to being joystick controlled. Some programs, such as the odometry calibration script, were reluctant to respond to left and right motions on the joystick. We hope to iron out the details in using the joystick soon as it will be very useful for calibration. Ivan has given the go ahead to purchase one for Winlab.

An exciting end of the day - we began writing a python script which will hopefully cause the robot to seek out the area of best internet connectivity. So far, the script is able to run iwconfig and extract the signal strength. It also has structures in place to keep track of three (x,y) coordinates and the signal strength at each of them. The functions written so far are: GoToXY(x,y) [Moves robot], scanning_thread() [returns signal strength], BigReading() [calls scanning_thread several times and returns average], Say() [calls flite for text to speech], Sort() [Sorts the three points in memory in order: best, good, worst], and PrintPoints() [prints BGW points to screen]. Python scripting is proving fast and easy, and we can probably have this working before lunch tomorrow.