Surveyor Robotics Journal
   



email: support@surveyor.com

SRV-1 home page

Surveyor Corporation home page

Subscribe to a syndicated RSS feed.

Subscribe with Bloglines

Archives
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

        
Wed, 27 Sep 2006
release candidate for SRV-1 firmware and SRV1Console ...

We've posted a release candidate for SRV1Console and corresponding SRV-1 firmware that support the new communication protocol and adds the two command line options for SRV1Console: -c (connect on startup via last comport used) and -p portnum (change port number for webcamsat from default 8888)

The frame rate problem seems to have been resolved, failsafe mode has been added (in place of "avoid") to turn off motors if the robot hasn't heard from the base station for more than 1 second, issues with 320x240 resolution seem to have been addressed, and general responsiveness to commands seems to have improved. Note that "wander mode" is still limited to 160x128 resolution.

Here are the download links - please post your comments on the Surveyor Robotics Forum.

Posted Wed, 27 Sep 2006 18:10 | HTML Link | see additional stories ...

Tue, 26 Sep 2006
new SRV-1 firmware and SRV1Console test version updates ...

There's a new version of SRV1Console and corresponding SRV-1 firmware that support the new communication protocol and add two command line options for SRV1Console -

  -c (connect on startup via last comport used)
  -p portnum (change port number for webcamsat from default 8888)

This isn't a formal release, as we are still working on frame rate issues, though progress has been made. Also, the release version will enable the "fail safe" option that was discussed on the Surveyor Robotics Forum, and the IR Avoid function which is partially disabled at the moment will be fixed before we post a release version.

Here are the download links - please post your comments on the Surveyor Robotics Forum.

Posted Tue, 26 Sep 2006 14:50 | HTML Link | see additional stories ...

Sat, 23 Sep 2006
improving SRV-1 battery performance ...

There have been a few discussions about the heat of the voltage regulator on the SRV-1 controller board on the Surveyor Robotics Forum, and some users have added heat sinks to the board's LM7805 +5VDC linear voltage regulator. While this is a simple solution, there's actually a more efficient alternative, changing the linear regulator to a switching regulator.

Linear voltage regulators achieve their voltage drop by dissipating the difference between the input and output voltages as heat, so it's not unusual for 30%-50% of the battery's power that passes through a linear regulator to be wasted. A switching regulator moves small chunks of energy at a time in such a way that the voltage drop is not lost as heat, and switching regulators typically achieve 90%+ efficiency.

Switching regulators are not simple circuits, usually requiring a number of external components. They are also quite a bit more expensive than linear regulators (typically $9-$10 vs $0.25). As such, we don't use them on production versions of the robots, but encourage users to consider them as an after-market upgrade. There are several manufacturers building switching regulators that are pin-compatible with the standard LM7805 regulators, and we gave one of these a try ...

Here are a couple of photos of a Recom R-785.0-0.5 +5VDC switching regulator, installed in place of the LM7805 (U4) on the SRV-1 controller.





We ran some tests, and found that nominal power draw dropped from 170mA-240mA with the LM7805 to 100mA-150mA with the switcher. We're not running motor power through the regulator - that comes direct from the battery, but this does measure the power usage of components that run off the regulator - processor, camera, radio, IR, etc. Excluding motor usage, changing the regulator effectively extends the duration of a battery charge by 50%+.

Here are information links for the Recom and Datel parts -

- Recom R-785.0-0.5 -
- Datel 7805SR -

Posted Sat, 23 Sep 2006 01:18 | HTML Link | see additional stories ...

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:12 | HTML Link | see additional stories ...

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

Posted Thu, 21 Sep 2006 23:05 | HTML Link | see additional stories ...

Sat, 16 Sep 2006
update for test version of firmware and SRV1Console using new protocol ...

There's an updated version of SRV-1 firmware and the SRV1Console for testing. The new code adds a direct motor control command to new handshake protocol, described in http://www.surveyor.com/SRV_protocol.html, and can be downloaded here -


This is still a test version of code, and is not a release candidate, as there are several known problems:
  • we're still having some problems with character loss in the java serial interface, and had to slow down image transfer rate by about 20% to compensate, though the telnet interface (for WiPort) now works and doesn't experience the character loss - we're still trying to figure this out
  • the java console will sometimes continue to issue 'I' commands even after being disconnect. it doesn't do any harm, but is a bit annoying
The 'M' direct motor control command is nice, as it allows users to customize their own motor controls. The "srv.config" file that defines the SRV1Console commands now uses this function in place of the previous '1'-'9' keypad commands, though those are still supported.

Two other protocol note - we modified the "BounceIR" command so that there is no longer a redundant "ListenIR" function. Also, we added a "Scan" ('S') function which allows the raw decision data used in "Wander Mode" to be accessed. The function may change, so it's not yet documented on the SRV protocol listing, but it is activated.

We're already getting feedback from testers of these new versions, and there are active discussions on the Surveyor Robotics Forum, so please leave your comments/questions there.

Posted Sat, 16 Sep 2006 14:57 | HTML Link | see additional stories ...


new SRV-1 representative for Singapore and Taiwan ...

Please welcome Robotics World to our growing family of highly qualified international representatives for SRV-1 robots.



Robotics World has offices in Singapore and Taiwan, and sells primarily to schools, universities, research labs, and government. They carry a very sophisticated product line, and we're really pleased to be able to work with them.

Posted Sat, 16 Sep 2006 14:51 | HTML Link | see additional stories ...

Thu, 14 Sep 2006
test versions of SRV-1 firmware and SRV1Console using new protocol ...

We've posted a new version of SRV-1 firmware and the SRV1Console for testing. The new code supports the new handshake protocol, described in http://www.surveyor.com/SRV_protocol.html, and can be downloaded here -


This is a test version of code, and is not a release candidate, as there are several known problems:
  • we're having some problems with character loss in the java serial interface, and had to slow down image transfer rate by about 20% to compensate. we had this problem in early versions of SRV1Console, so hopefully we will track it down soon, but in the mean time, the frame rate is slightly reduced
  • the camera interface is again being fussy, so the frame capture rate is lower than it should be. once we figure out the java serial interface issue, we'll focus on this
  • the telnet network interface (for WiPort) is not 100% at the moment. problems seem to be related to the character dropping noted above
Other than that, the code seems to be stable, but we need others to verify that. The most noticeable benefit of the new code is the handshake protocol which seems to largely resolve the problem of lost motor commands, but there are other benefits, including significantly easier integration with other base station control programs, and a set of commands that lend themselves to controlling multiple robots simultaneously.

We will likely add a few more commands to the protocol definition, including direct motor control (in addition to the steering commands), so we're probably 1-2 weeks away from a formal version release. In the mean time, we're hoping to get some feedback from testers, and will set up a topic to discuss this on the Surveyor Robotics Forum.

Posted Thu, 14 Sep 2006 13:08 | HTML Link | see additional stories ...

Sat, 02 Sep 2006
update on SRV-1 + WiFi ...

An SRV-1 is now running with an on-board WiFi module (the Lantronix WiPort). It's not pretty, but it actually works quite well.



It was actually a simple installation. After removing the Zigbee radio, 2 hex spacers (3/4") were added in place of the SRV-1 controller mounting screws on the left side of the circuit board. (3/4"). After acquiring a small circuit board (1.8" x 2.8" or 47mm x 72mm) from Radio Shack, the WiPort module and antenna were removed from the WiPort evaluation kit, added a 3.3V regulator (LD1117) to the circuit board, some holes were drilled, and the WiPort was mounted on the new circuit board.



Because the spacers are grounded, it was only necessary to attach the WiPort ground to the rear spacer through the screw. A WiPort PCB connector was available from www.gridconnect.com for $10, though it's likely possible run wires directly into the WiPort connector. In any case, only 3 wires had to be attached from the WiPort - the 3.3V supply (WiPort pin 1), which came from the center pin of the voltage regulator, the RXD0 receive data signal (WiPort pin 5), which went to Pin 3 of the XBee radio connector, and the TXD0 send data signal (WiPort pin 4) which went to Pin 2 of the Zigbee radio connector. Finally, a wire was run from the battery input connector on the edge of the SRV-1 controller to the rightmost pin on the voltage regulator.



The WiPort module was first fired up with just the 3.3V and ground lines connected first just to make certain it was happy with the voltage regulator, testing that it was accessible via the WLAN, and then we connected the serial lines. Once the serial lines were connected to the Zigbee radio socket, the robot fired up and ran without problem.



A few notes about operation - it was possible to run SRV1Console and LPC21ISP without modification on Windows, using a "com port redirector" that maps a virtual com port to a telnet connection, and data flowed transparently. It is even possible to run LPC21ISP this way to program new versions of firmware to the ARM7. However, there were limitations in the WiPort such that LPC21ISP couldn't run at data rates higher than 230kbps, and SRV1Console couldn't run faster than 460kbps (the data is pretty badly scrambled at 921kbps). This has been reported to Lantronix tech support, as the module is spec'd to handle 921k, but in any case, the robot runs well at the lower data rates.

The WiFi connectivity is good with a couple of Belkin54g 802.11b/g router/access points, and handoff seems to be seamless as the robot drives around. We haven't tried to measure power consumption, but it's clearly higher than the XBee radios. Also, while the frame rate was probably 4x faster with the 460kbps connection that connections via Zigbee, it seems that the frame rate could be higher, so another look at timing in the camera interface code will be on the to-do list.

We're waiting on another WiFi module to integrate in approx 2 weeks, though it won't be in production for a few months. The Lantronix WiPort is certainly promising, and we'll be happy to share our results with others who wish to experiment with adding WiFi to the SRV-1.

Posted Sat, 02 Sep 2006 23:00 | HTML Link | see additional stories ...


Surveyor Robotics Forum now exists ...

Please visit http://www.surveyor.com/robot_forum.html, and let us know if there are any issues in setting up accounts or generating posts.

Posted Sat, 02 Sep 2006 23:00 | HTML Link | see additional stories ...