Surveyor Robotics Journal
Surveyor Corporation home page
Subscribe to a syndicated RSS feed.
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, 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 ...
Tue, 29 Aug 2006some thoughts about the SRV-1 communication protocol
The current communication protocol between the SRV-1 robot and the base station host is quite simple - we've defined a set of single byte commands that control robot motion, video resolution, wander mode, etc, and associated a set of buttons with those commands. The definition of the commands can be found in the main SRV1Console directory on the host in the srv.config file.
The commands are defined in hex, but if you translate these to ASCII, you'll see that all of the commands are simple keystrokes, so if you had a terminal program connected to the USB radio's serial port on the host, you could type the commands and control the robot directly.
In fact, if you have a numeric keypad, you'll see the '8' key (hex 38) drives the robot forward. The '7' key is "drift left", the '9' is "drift right, the '4' is turn left, the '5' is stop, etc ...
Look at srv.config and you'll see a series of definitions like these which set the order in which the buttons appear in SRV1Console and match the button graphics with the actual commands -
button.1=buttons/driftleft.png
command.1=37
button.2=buttons/forward.png
command.2=38
button.3=buttons/driftright.png
command.3=39
If you were connecting to the radio through a serial port, you would see a spew of weird characters that actually represent the binary data in the stream of JPEG frames that are being sent from the robot. If you could slow down the flow of characters, you would see that each frame starts with a 12 byte header. The first 4 bytes are the characters "SVFR" (short for Surveyor video frame), followed by the image type - "IMJ1" is 80x64 JPEG, "IMJ3" is 160x128 JPEG, "IMJ5" is 320x240 JPEG, then followed by a 4-byte length, which is the size of the JPEG frame in bytes (sent low byte first). We've defined some other image types, including raw uncompressed pixels and binary images that are useful for showing thresholded pixel data after image processing, but we only use those in testing, so they aren't part of the typical SRV-1 operation.
As noted above, this is a very simple interface. However, we're starting to find that it might be a bit too simple, as there's no handshake or acknowledgment mechanism between the host and robot, and because the radio is effectively half-duplex (the Zigbee radio really doesn't support sending and receiving at the same time, though it works sometimes), some commands that get sent from the host are getting clobbered by the JPEG data and are not reaching the robot.
We're considering a change to a handshake-based protocol, so that every command that is sent from the host receives an acknowledgment, and video frames are only sent in response to a frame request. We didn't use this approach originally because of latencies it would create in receiving freshly captured frames. However, with the increase of the camera interface to 921kbps from 115kbps, the delays in pulling frames from the camera are greatly reduced, and the robot can respond quickly with a fresh frame when a frame request is received. This approach also simplifies the interface on the host side, as the host code will no longer have to parse incoming data to try to find frame headers or try to extract other data from incoming streams.
We haven't settled on a format for the messages yet, but would like to keep them simple, so that a terminal program can still be used for debugging. The commands could still be single byte, and the ACK response might be simple 1 or 2 character header, e.g. # or ## followed by the command ... e.g. '8' to drive forward would get the response #8 or ##8, and the command to grab a 160x128 video frame would receive the SVFRIMJ3xxxx ....
It seems that change in this direction is a good idea, but I thought it would be worthwhile to ask for comments from code developers who are already working (or considering working) with the SRV-1 to see if there are any issues or suggestions. Please email your thoughts to support@surveyor.com subject:SRV-1 protocol. Thanks !
Posted Tue, 29 Aug 2006 15:21 | HTML Link | see additional stories ...
Mon, 28 Aug 2006SRV-1 now offered by robot-italy.com (Italy) and nodna.com (Germany)
As a high percentage of SRV-1 robots have been traveling to Europe, we have been very fortunate to attract the attention of two highly regarded robotics developers/integrators, robot-italy.com and noDNA.com, and both have begun to offer the SRV-1 robots to their customers.
Robot Italy represents Robonova, Solarbotics, Lynxmotion and other top level robotics kit and components manufacturers. They host a robotics forum, and are very knowledgeable about robotics development. They are offering complete SRV-1 starter kits as well as the controller-only version of the SRV-1 for integration with other robotics platforms.
Established 2000, noDNA now offers the largest selection of robots in Germany, including Kondo KHR, Robotis, Robonova, Lynxmtion, as well as manufacturing and distributing human body worn motion capture devices such as DataGloves, FaceTracker, BodyTracker. They also host a robotics forum, and are currently located in Koln. noDNA is offering complete SRV-1 starter kits.
Posted Mon, 28 Aug 2006 15:21 | HTML Link | see additional stories ...
Thu, 17 Aug 2006programming the RS232 version of the ARM7 processor via radio
We produce a small number of SRV-1 controllers with RS232 connectors, as the original SRV-1 robots used these processor cards. We wanted to note that it's possible to upload firmware to these cards via the radio, but you have to first remove the 4 jumpers on the processor card, as shown here -
and then follow the normal programming steps as described in SRV_setup.html, placing the jumper on JP4 before starting LPC21ISP, as shown here -
Note that you can also upload firmware via the RS232, but you have to replace the 4 processor card jumpers, and then removing the left-most radio jumper at JP2 that is shown in the photo above.
If you don't have an RS232 version of the SRV-1 controller board, just ignore this post. If you do have the RS232 version, you'll find that this approach to programming via radio is a lot more convenient than an earlier suggestion we made about making a special DB-9 connector.
Posted Thu, 17 Aug 2006 16:19 | HTML Link | see additional stories ...
test version of SRV-1 firmware with camera interface at 921600 baud
Thanks again to suggestions by Per Dalgas Jakobsen of the Danish Technological Institute, we found that the interface data rate between the camera module and the ARM7 can be increased from 115200 to 921600 baud, which significantly increases our frame capture rate. Note that this doesn't result in an improvement in viewing frame rate, as the bandwidth of the radio interface has remained the same, but for applications which use the onboard ARM7 for real-time image processing, the increased frame rate is very important.
We have created a test version of code with this functionality. We haven't posted a link on the main SRV-1 download page, but SRV-1 users are welcome to give this a try.
http://www.surveyor.com/srvdownload/srv1.hex.081706
The corresponding firmware source code snapshot which was used to build this version is found here - http://www.surveyor.com/srvdownload/srv-081706.zip
Please note that live viewing using this version will seem to be somewhat less smooth with longer latency than before, as we have to buffer the full incoming frame before sending. Previously, we were interleaving receive and send because incoming (from camera) and outgoing (to radio) baud rates matched, thus providing a smoother flow. Not certain yet, but we might want to create a dual-mode version of firmware that supports the old 115200 capture rate for users who just want to view and don't care about the image processing functions. In any case, the higher capture rate is a big boost for development of applications which use image processing, and this is an area in which we have keen interest.
Posted Thu, 17 Aug 2006 15:31 | HTML Link | see additional stories ...
Mon, 14 Aug 2006more camera code tweaks, also a baud rate issue
We've made some additional camera code changes, in part thanks to suggestions by Per Dalgas Jakobsen of the Danish Technological Institute. In particular, some small changes in timing have increased the stability of the connection between the camera and processor, plus when resets occur, they don't clobber the colors. We've also fixed an old bug that caused the camera resolution to always return to 160x128 after a reset, even if it was at a different resolution.
We've posted an updated version at
http://www.surveyor.com/srvdownload/srv1.hex.081406
Just download and save as srv1.hex, and follow the instructions on the SRV-1 setup page for uploading new versions of firmware. Please let us know if you have any problems with this version.
Also, we've posted a new firmware source code snapshot which was used to build this latest version at http://www.surveyor.com/srvdownload/srv-081406.zip
One additional note - we just found out from the XBee radio module manufacturer that the serial interface baud rate of the module is 112400 instead of 115200. Apparently, the ARM7 UART doesn't care about the difference, except when it comes to using the LPC21ISP.EXE firmware loader. Next time you try updating the SRV-1 robot firmware via radio, try
lpc21isp -hex srv1.hex com4 112400 14746
instead of
lpc21isp -hex srv1.hex com4 115200 14746
assuming com4 is the location of your USB radio dongle. Let us know if this makes any difference on the performance of the LPC21ISP firmware transfers.
Posted Mon, 14 Aug 2006 17:19 | HTML Link | see additional stories ...
Tue, 01 Aug 2006another small SRV-1 firmware change
After further testing of the July 30 firmware update to correct camera issues, we've made one more small change, reducing the maximum frame capture retry count from 50 down to 10, which significantly reduces any time-out delays. The number might be reduced even further, but we haven't had a chance to test that yet. We encourage those who are working with SRV-1 source code to experiment with this.
Anyhow, it's a single line fix in the vicinity of line 291 of main.c. Just edit following line of code -
if (++retry_count > 50)
changing it to
if (++retry_count > 10)
Let us know your results with smaller retry_count numbers. We've posted an updated version of the firmware at
http://www.surveyor.com/srvdownload/srv1.hex.080106
Just download and save as srv1.hex, and follow the instructions on the SRV-1 setup page for uploading new versinos of firmware. Please let us know if you have any problems with this version.
Posted Tue, 01 Aug 2006 13:55 | HTML Link | see additional stories ...