Surveyor Robotics Journal
Surveyor Corporation home page
Subscribe to a syndicated RSS feed.
Archives
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
Wed, 30 Aug 2006
proposed definition for communication protocol between SRV-1 and host
Per my earier post, here is a proposal for a revised protocol between SRV-1 and host, adding a handshake response from the robot to all commands, and changing from 'push' to 'pull' for the video stream, so that frames are only delivered when requested. With a few exceptions, these are already the commands used by the SRV-1 as defined in SRV1Console's srv.config
All commands are single byte ASCII characters, and all commands receive an acknowledgement, with is either a '#' character followed by the command, or '##' for variable length responses
| Command | Response | Description |
|---|---|---|
| '7' | '#7' | robot drift left |
| '8' | '#8' | robot drive forward |
| '9' | '#9' | robot drift right |
| '4' | '#4' | robot drive left |
| '5' | '#5' | robot stop |
| '6' | '#6' | robot drive right |
| '1' | '#1' | robot back left |
| '2' | '#2' | robot drive back |
| '3' | '#3' | robot back right |
| '0' | '#0' | robot rotate left 20-deg |
| '.' | '#.' | robot rotate right 20-deg |
| '+' | '#+' | increase motor speed |
| '-' | '#-' | decrease motor speed |
| 'a' | '#a' | set capture resolution to 80x64 |
| 'b' | '#b' | set capture resolution to 160x128 |
| 'c' | '#c' | set capture resolution to 320x240 |
| 'w' | '#w' | turn on "wander mode" |
| 'W' | '#W' | turn off "wander mode" |
| 'p' | '#p' | turn on "proximity detect" |
| 'P' | '#P' | turn off "proximity detect" |
| 'I' | '##IMJxssss....' | grab compressed video frame |
| j=resolution (1,3,5) | ||
| ssss=frame size | ||
| .... = image data | ||
| 'V' | '##Version ...\n' | read firmware version info |
| response is terminated by newline character | ||
We haven't yet added commands for IR comm functions and a video-based range finder function, but these will follow. We will maintain this protocol definition on http://www.surveyor.com/SRV_protocol.html. As before, all comments and suggestions are welcome.
Posted Wed, 30 Aug 2006 16:01 | HTML Link | see additional stories ...
SRV-1 + WiFi ... some work in progress
Recently, we started to investigate the possibility of running the SRV-1 with 802.11 Wi-Fi radios as an alternative to Zigbee, given that we can now pull frames from the camera at 921kbps, but can only transmit them via Zigbee at a bit less than 115kbps. We came across 2 commercially released WiFi modules with serial interfaces, plus one module that hasn't yet been released but is quite promising.
The released modules come from DPAC Technologies (now part of Digi) and Lantronix, and are respectively called the DPAC "Airborne Embedded Wireless Device Server Module" and the Lantronix WiPort. Both devices appear to be quite capable, and cost is about the same ($120 per module), but the WiPort seemed easiest to customize/extend with onboard code, so we now have a couple of WiPort developer kits ($299 ea).
Connecting the WiPort developer kit to the SRV-1 was a simple matter - we just had to configure the WiPort to talk with our in-house WiFi network via a telnet login, then configure a telnet port on the WiPort to map to the serial port. We still have to modify SRV1Console to connect to the robot via telnet, but we're already able to send motor control commands and see the binary image data streaming from the robot via a console telnet connection.
Beyond extending SRV1Console, the next step is to remove the WiPort module from the developer kit board and directly connect it to the SRV-1 in place of the Zigbee module - we're just waiting for some connectors, as the 40-pin 1mm header from the radio is not easily sourced (Samtec FTMH-120-03-F-DV). We also have to add a 3.3V regulator, as the existing regulator for the ARM7 is borderline in providing enough current. In theory, we'll have all of this going in a few days.
At least at the moment, we don't plan to resell the WiPort, as it's widely available through distribution, but we will provide integration assistance to those who are interested. As mentioned above, there is a 3rd module in prototype form due for release before year-end that we will most likely offer as an option on future sales, as well as an upgrade for existing SRV-1's. The new module is roughly equivalent in cost to the current Zigbee radios, so we could offer it without changing the SRV-1 pricing. However, we intend to continue supporting Zigbee, as Zigbee offers somewhat better range than WiFi (if you ignore the possibility of WiFi repeaters and multiple access points) and lower power consumption (100mA transmitting with Zigbee vs 300mA+ with WiFi). Of course, the ability to connect into existing network infrastructure with WiFi is a very nice feature.
We'll provide updates as this integration moves further along. Those who are interested in experimenting with WiFi on the SRV-1 in advance of a formal product release should contact us - support@surveyor.com subject:WiFi
Posted Wed, 30 Aug 2006 13:00 | HTML Link | see additional stories ...