Surveyor Robotics Journal
Surveyor Corporation home page
Subscribe to a syndicated RSS feed.
Archives
November 2008
October 2008
September 2008
August 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
Februray 2006
January 2006
Thu, 21 Sep 2006
experiments with the SRV-1 "wander mode" ...
The "wander mode" that is included in recent SRV-1 firmware releases is simple, and occasionally it works pretty well, but it is also prone to spectacular failure. It was never intended as a long-term solution, and now that the SRV-1 protocol is stabilizing, it seems time to revisit the "wander mode" functionality.
Basically, the first version of "wander mode" code divided the near visual field from the onboard SRV-1 camera into 8 regions of 3 x 20 pixels each, took some initial samples of the closest 3 x 40 pixels, and used that baseline to try to match what average colors were seen in each of the 8 regions, using that information to drive the robot through regions that appeared to be clear. As noted, this sometimes worked quite well, but objects at the edges of the field of view would often not trigger avoidance logic, and reflective surfaces would wreck havoc on any color processing.
Though the reflective surface issue will be difficult to overcome, breaking the field of view into smaller segments seems like a move in the right direction, and so we're experimenting with a different approach treats the captured image as a set of vectors, where each column of pixels from bottom to top is processed separately, and then the vectors are recombined for analysis.
As before, we capture a baseline sample (currently hardcoded to an average of the nearest 20 x 4 pixels). We're just using the IMJ3 video mode on the SRV-1 (160x128), and have subsampled the Y, U and V components down to 80 columns of 64 pixels, so that's our field-of-view. What's interesting is that the position of each pixel in each column is more or less linearly correlated with that pixel's position in 2-D space (assuming the surface ahead of the robot is flat), so pixels in a column that are different color from the baseline sample may represent an obstacle for the robot, and the position of the nearest different pixel correlates somewhat with the distance to that object. So by processing each column and finding the first "disturbance" potentially provides a map of object ahead.
Here's a dump from a new version of the 'S' Scan function that's accessible once the robot is in 'w' wander mode. This particular set of samples were taken on a desktop that dropped off about 2 feet (15-20 pixels) in front to one side.
For each "Scan", there is a single number for each column showing the distance to first color mismatch. The pixel distance is actually divided by 8 in order to fit everything on one line, so a measure of 1 might be 1-8 pixel distance, and a measure of 2 is 9-15 pixel distance. The max value is 8 (not shown in this example).
After that, there are 7 sets of 3 numbers. Each set is an accumulation of 20 columns, and each set overlaps by 10 columns, so the first set is columns 0-19, second set is 10-29, etc. The first number is the max pixel distance detected in the set (actual number, not divided by 8 as above), the second number is a mean of the pixel distances, and last is the number of zeros found. A zero distance means that the column isn't open at all (no match with the baseline colors).
Note - every time the 'w' wander mode command is issued, the baseline colors are resampled.
At the moment, there's no motor control attached to the scan/wander function - we're just gathering data, driving the robot around manually, capturing more data, etc. However, the basis for a driving algorithm is fairly obvious - we want to steer toward those areas that have almost no zeros and have the highest mean or max pixel distance.
Anyhow, I've posted the code if anyone wants to experiment. Besides addition of motor control, it would be nice to add some adaptive logic so that the baseline colors can be resampled from time to time to adjust to changing light. We're probably a few days away from posting a fully functioning "wander mode" using this logic, and welcome anyone's comments - there will be a thread in the SRV-1 Software section of the Surveyor Robotics Forum to discuss this.
Here's a link to the above-described code...
- SRV-1 firmware source - srv-092106.zip source archive, including compiled srv1.hex
Posted Thu, 21 Sep 2006 23:05 | HTML Link | see additional stories ...