• This summer, the code is being ported to Player 2.x
• Additional outdoor Pioneers have arrived

Summer 2007 Status

Completed

• HMR3000 player driver (Digital Compass)
• Hokuyo URG laser range finder driver
  • There's one built into player/stage, and we have it working

To Do

• Mount sensors on Pioneer P3-AT
  • Identify power sources for each sensor (some require 9V while others require 5V)
• Get laptop(s) up and running
  • dual/triple boot?
  • Needed software:
    • Player
    • Stage
    • Carmen
    • dependencies for those packages...
• Create Player client

Summer 2005 Status

The previous work on the Grand Challenge is being left here, since it's a good hint at what code we may have lying around somewhere.

Completed...

• Software Library
  • Brian and I (Levi) took most of our code and created a shared library that provides some high-level functions to interface with the Pioneers.
  • This code will be made available on our CVS server (contact us for access)
• Compass
  • We received compasses from Honeywell which update at 8 Hz with an accuracy of 1.0 degree
  • The data from the Honeywell compass (Roll, Pitch, and Heading) can now be read in using the CompassSensor class which runs on it's own thread.
  • After running into issues with multi-threading, we modified the compass code to rely on the system clock to query the compass roughly once per second (1 Hz) to minimize any effects on the rest of the program's execution.
  • Interfaced with Silicon Laboratories USB compass/inclinometer in Linux
  • Determined how to mount the compass to minimize interference from the motors, laptop hard drive, etc.
• GPS
  • Determine which coordinate system to use...
    • Lat-Long: We know it's available directly from GPS, but must be converted to feet.
    • UTM: Measured in meters, may or may not be available from GPS. Easy conversion.
    • State Plane: Measured in feet, may or may not be available from GPS. Easy conversion.
    • I think we have to go with the Lat-Long coordinate system due to the likely fact that our GPS receiver only outputs lat-long.
• Maps
  • We now have maps (thanks to the GMU GIS Center) and access to software to generate modified maps.
• Voice Dictation (i.e. Text to Speech)
  • Using Festival speech libraries (most likely), we need the ability to have the laptop speak out status information.
  • Festival must be installed and configured to work in Linux, then integrating into our code should be trivial (use SpeechProxy class from Player libraries)
• Obstacle Avoidance
  • Brian's algorithm works pretty well. It uses a summation of vectors technique in which each sonar reading represents a vector (direction and magnitude). The summation of these vectors and a "goal" vector allows for obstacle avoidance to be combined with navigation.

Not Completed...

Behaviors

• People Avoidance
• Obstacle/People Avoidance + Navigation

Data Fusion

• Data from various sensors must be combined to produce an optimal solution to our position, heading, speed, etc.
  • Code is now in place to combine the GPS and wheel encoder estimates of our distance to the next waypoint. It's currently doing an equal weighted average, but an adjustable weighting factor is in place.
• Kalman Filtering is one method used to accomplish this, but we must somehow combine different sensor measurements. This can be done by applying appropriate weights (that are proportional to the uncertainty) to each measurement.
• Particle Filter (Brian's favorite choice)
  • Hey, when your only tool is a hammer, everything is a nail
  • Probabilistic model for GPS is a challenge. Maybe just use a uniform distribution within a bounding circle?
    • Bounding circle would be determined by confidence value

Vision

• Color blob detection: Simple option, but this could suffer from inconsistent lighting conditions.
• Vanishing point detection: Utilize the lines on the sidewalk to steer the robot along the pathways.
• Localization: Based on a database of "keypoints" of the campus buildings, we can derive our orientation.
  • Use SIFT algorithm (Scale-Invariant Feature Transform) based probability model
    • The available SIFT code comes in two flavors: Matlab/C or Mono
      • Write our own? There's a patent on this algorithm -- how would that impact us?

Determine how we want to create the graphs

• Also which sort of path planning algorithms do we want to use. A*, B*, Djikstra, ......

Path Planning

• Given the georeferenced raster data, we need to come up with a way to create a graph with waypoints for the nodes, and distance, width, etc. to describe the node links.

GPS

• Determine how to mount the GPS receiver to see the most amount of satellites.

Voice Recognition

• Would also be nice to have.

Wireless Connection

• Set up ad-hoc wifi connection between Linux laptop and another machine for outdoor connection.

Fix Speed Racer

Speed Racer is in need of some overhauling to get it into proper condition to begin testing and programming.

Other pieces for localization need to be decided on. Currently it only has a very inaccurate wheel watcher on one of the back wheels

Get 'em running

There are more things than I have listed so far. Feel free to post things that you think are important to the completion of this project. Anything that you think we have taken a wrong turn with. This is the time to change things. -Conrad