Surveyor Robotics Journal
   



email:
support@surveyor.com

web:
Surveyor Corporation

rss:
Subscribe

Archives
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
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

        
Fri, 22 Sep 2006
further exploration of the SRV-1 "wander mode" ...

Continuing from the discussion yesterday, there is now a version of SRV-1 test code that has the motors activated in wander mode. The field of view is broken into 7 overlapping regions that are each 20 pixel columns wide, and each region is flagged as open (1) or blocked (0) ...

  tflag = 0;
    for (ix=0; ix<7; ix++)
    if (tzeros[ix] <5)
      tflag += (0x40 >> ix);

producing a 7-bit pattern that has 128 possible combinations. There's a lookup table for all 128 patterns, where a motor control keypad command is assigned to each pattern (8 = forward, 2 = back, 0 = rotate left 20-deg, . = rotate right 20-deg, 7 = drift left, 9 = drift right, etc) ...

unsigned char motor_cmd[128] = {
// assign motor command to each 7-bit tflag pattern
// 1's in the bit pattern represent clear regions for movement
// 0000000, 0000001, 0000010, 0000011, 0000100, 0000101, 0000110, 0000111,
'.', '.', '.', '.', '.', '.', '.', '6',
// 0001000, 0001001, 0001010, 0001011, 0001100, 0001101, 0001110, 0001111,
'0', '.', '.', '6', '2', '7', '6', '6',
// 0010000, 0010001, 0010010, 0010011, 0010100, 0010101, 0010110, 0010111,
'0', '0', '2', '.', '0', '.', '2', '6',
// 0011000, 0011001, 0011010, 0011011, 0011100, 0011101, 0011110, 0011111,
'0', '0', '3', '.', '4', '4', '9', '9',
// 0100000, 0100001, 0100010, 0100011, 0100100, 0100101, 0100110, 0100111,
'0', '.', '0', '.', '0', '2', '2', '6',
// 0101000, 0101001, 0101010, 0101011, 0101100, 0101101, 0101110, 0101111,
'3', '3', '2', '.', '0', '2', '2', '6',
// 0110000, 0110001, 0110010, 0110011, 0110100, 0110101, 0110110, 0110111,
'0', '0', '0', '1', '4', '4', '8', '8',
// 0111000, 0111001, 0111010, 0111011, 0111100, 0111101, 0111110, 0111111,
'4', '4', '4', '4', '4', '4', '8', '9',
// 1000000, 1000001, 1000010, 1000011, 1000100, 1000101, 1000110, 1000111,
'0', '0', '0', '.', '0', '.', '.', '6',
// 1001000, 1001001, 1001010, 1001011, 1001100, 1001101, 1001110, 1001111,
'0', '0', '0', '1', '.', '.', '6', '6',
// 1010000, 1010001, 1010010, 1010011, 1010100, 1010101, 1010110, 1010111,
'0', '0', '0', '.', '0', '2', '2', '6',
// 1011000, 1011001, 1011010, 1011011, 1011100, 1011101, 1011110, 1011111,
'3', '3', '3', '3', '4', '8', '8', '8',
// 1100000, 1100001, 1100010, 1100011, 1100100, 1100101, 1100110, 1100111,
'0', '0', '0', '2', '0', '0', '.', '6',
// 1101000, 1101001, 1101010, 1101011, 1101100, 1101101, 1101110, 1101111,
'3', '3', '3', '3', '0', '0', '.', '6',
// 1110000, 1110001, 1110010, 1110011, 1110100, 1110101, 1110110, 1110111,
'4', '4', '4', '4', '4', '4', '7', '8',
// 1111000, 1111001, 1111010, 1111011, 1111100, 1111101, 1111110, 1111111,
'4', '4', '4', '4', '7', '7', '8', '8'
};

It would be worth trying different motor commands for the different patterns, and there's definitely room for improvement in the logic that determines whether a region is open (1) or blocked (0), also taking into consideration the mean and max pixel column measurements rather than just looking a zeros, but the basic approach is reasonable, and should yield a significant improvement over the original wander mode once the code is dialed in.

Here's a link to the above-described code...

Posted Fri, 22 Sep 2006 14:25 | HTML Link | see additional stories ...


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...

Posted Fri, 22 Sep 2006 14:20 | HTML Link | see additional stories ...