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
Tue, 31 Oct 2006
Draft Proposal for SSLV (Small Scale Local Vision) sub-league of RoboCup F180 League
The intent of the SSLV is to promote the development of fully autonomous small-scale RoboCup players based on an emerging class of low-cost commercial off-the-shelf mobile robots, employing and extending the state-of-the-art in self-localization, object recognition/tracking, self-organization of multiple robots, sensory data sharing, etc.
To the extent possible, rules of the existing structure of the F180 league will be used, along with some ideas drawn from the Aibo Four-Legged League ("FLL"), though no global vision is allowed.
- Law 1 - The Field of Play
dimensions are not absolutely critical - in fact, robots should be able to adapt to varying field conditions, though the field should be in the range of 4-meters x 5-meters, as defined for F180 or FLL, with colors and markings set to provide minimal visual confusion for the robots. Colors and markings should follow guidelines used in F180 or FLL play, with the addition of colored beacons used in FLL for localization
- Law 2 - The Ball
orange golf ball, same as F180
- Law 3 - The Number of Robots
suggest reducing this to 4 in order to reduce interference in localization - Law 4 - The Robotic Equipment
- robotic equipment must be fully autonomous. human operators are not permitted to enter any information into the equipment during a match, except at half time or during a time-out
- robot markings are similar to F180, except that colored markers are visible on the sides of robots instead of the top.
- robots should ideally be based on unmodified commercial-off-the-shelf products with only the addition of a passive ball-handling fixture in order to facilitate "one-design classes". in any case, no active ball handling mechanism is allowed (e.g. dribbler, kicker).
- ball-handling fixture is a simple arc (10-cm radius ?), with a span of no more than 10cm, height of no more than 2cm, and ground clearance of no more than 1cm. ends of the fixture should be shaped as to provide minimal damage in case of contact with other players, refs, etc.
- "one design" sub-classes of same-type robots are provided if 4 or more teams are entered in a given competition
- wireless communication between robots allowed. off-board processing is allowed, but maximum allowable bandwidth allocation for each robot is 100kbps. it must be possible for referee to verify level of bandwidth usage
- a device will be supplied to each team that converts the referee's signals into a serial communication signal that is transmitted to both teams
- Law 5 - The Referee
- Law 6 - The Assistant Referee
same as F180 - Law 7 - The Duration of the Match
suggest reducing this to 2 x 10 minute periods, same as FLL rules. teams switch goals at half-time. - Laws 8-17 - Game Play
based on F180, with some simplification. no free kicks. robots are free to touch the ball multiple times without penalty. no offsides.
references:
F180 rules - http://www.cs.cmu.edu/~brettb/robocup/rules/f180rules2006.pdf
Four-legged rules - http://www.tzi.de/4legged/pub/Website/Downloads/Rules2006.pdf
(last update: 31 Oct 2006 15:00GMT)
check for additional updates on http://www.surveyor.com/robocup-SSLV.html
Posted Tue, 31 Oct 2006 11:47 | HTML Link | see additional stories ...
Mon, 30 Oct 2006RoboCup Soccer
One of our more interesting projects at the moment is a proposal to the RoboCup Federation for creation of a sub-league within the Small Size League for robotic players with on-board vision and autonomous control as an alternative to the current systems employing overhead "global vision" camera systems. It's a significant technical challenge, but there seems to be a lot of interest from other robot manufacturers in the same size class as the SRV-1, so we're trying to come up with a set of rules that would encourage broad-based industry participation.
We started doing some prototyping, and while it will take some time before we have fully functional 4 player vs 4 player game demonstration, the mechanical aspects are pretty simple. The idea is that we would try to engage participation from existing commercial off-the-shelf robots meeting the size constraints (robots fit within 180mm diameter cylinder) that use on-board cameras as their primary sensor with just the addition of a passive ball-handling fixture. We've already had some debate about whether to allow any off-board processing, as this would greatly simplify the programming task for many participants, and the current thought is that if we significantly limit the bandwidth of connections between the robots and their hosts (e.g. 100kbps per robot). Anyhow, here's an example of the proposed robot modification - it's quite simple and reasonably functional ...
The main challenge at this point in completing a proposal is to work out details of game play as they vary from the rules that apply to existing Small Size League competitions. Anyone interested in this concept, especially if you have first-hand experience with RoboCup competitions, is encouraged to contact us with comments / suggestions.
Posted Mon, 30 Oct 2006 21:24 | HTML Link | see additional stories ...
Sat, 28 Oct 2006first simulator images of the SRV-1 in Webots
I had to share these great images - they were generated from a 3D model of the SRV-1 in Webots 5, Cyberbotic's fast prototyping and simulation tool for mobile robots (click here for an overview of Webots).
We're looking forward to offering a demo version of Webots with SRV-1 support in the near-term.
Posted Sat, 28 Oct 2006 11:31 | HTML Link | see additional stories ...
Thu, 26 Oct 2006extending the range of Zigbee radios to 40 miles !
The manufacturer of our Zigbee (802.15.4) radio modules just announced a long distance bridge - MaxStream Extends ZigBee Range Up To 40 Miles
The XBee XTender RF Bridge is expected to be available in December with pricing (per bridge) in the $400 range. We're pretty happy with the range of the XBee Pro modules we currently ship, but we occasionally get requests for longer range radios, and this certain fits that description.
Posted Thu, 26 Oct 2006 12:17 | HTML Link | see additional stories ...
Thu, 12 Oct 2006"wander mode" continued...
We received good feedback on the firmware version posted yesterday, and it seems that we're on the right track with "wander mode". The only issue that was raised is that we broke with our protocol format in the "Scan" command, so we've fixed that problem and formally included the Scan command in the SRV_protocol specification
This is how the display of the scan data now looks from a console -
There's also a command - 'm' - to turn off autonomous movement during "wander mode", which makes it easier to anayze the scan data because the robot just moves under operator control. The motors are reenabled with the 'w' command that initiates "wander mode". In this screenshot, at the top you can see the ACKS from turning on wander mode (#w), turning it back off (#W), turning it back on (#w), disabling the motors (#m), then viewing the scans (##Scan -)
It would be nice to be able to overlay the scan data onto the image display of the console programs, as this would give us a nice tool for evaluating different image processing techniques in "wander mode". Once we add an object tracking mode, we'll want to provide a similar display.
Here's the latest version of code -
- srv1.hex.101206 (rename to srv1.hex)
- srv1-101206.zip (firmware source archive)
Posted Thu, 12 Oct 2006 12:47 | HTML Link | see additional stories ...
Wed, 11 Oct 2006more adjustments to "wander mode" ...
There's a new test version of SRV-1 firmware that has a somewhat different approach to thresholding in "wander mode", using a range of Y, U and V values instead of an averaged sample and fixed threshold range. Initial experiments are promising, so it will be helpful to get feedback from users.
If you try controlling the robot from a console, you can look at the data that the robot is processing in making its navigation decisions. Hit 'w' to initiate "wander mode", and then hit 'S' from time to time to view the "Scans", as seen here -
The top line of each scan is ##Scan - xxxxxxxx, where xxxxxxx shows the open/blocked status of the regions ahead, and the following 80 numbers are the distance in each pixel column to the first non-matching pixel. The minimum possible value is 0, indicating that the pixel column is completely blocked, and the maximum possible is 64, which is the height of each of the 80 pixel columns.
If you want to just look at the numbers in this mode without having the robot driving around, just comment out line #515 (we probably should add a function to disable the motors for testing):
// set_motor(motor_cmd[tflag], base_speed, &lspeed, &rspeed);
Here are the download links - please post your comments on the Surveyor Robotics Forum:
- SRV-1 robot firmware - srv1.hex.101106 - rename to srv1.hex
- SRV-1 firmware source - srv-101106.zip source archive
Note - this code includes all of the "swarm mode" additions, and while we've tried to test all functionality, it is possible that we've broken something from earlier versions, so please let us know over in the robot forum if there are any new problems that this code has introduced.
Posted Wed, 11 Oct 2006 16:15 | HTML Link | see additional stories ...
Sat, 07 Oct 2006more SRV-1 "swarm mode" adventures ...
After starting to consider how to employ IR beacons for localization and navigation in a multiple robot environment, we recognized a benefit to assigning specific ID's instead of random ID's to robots that were acting as beacons, as that would give us control over the positioning of the beacons. Fortunately, there's a convenient mechanism on the SRV-1 controller which enables us to assign fixed addresses using some of the unassigned i/o pins.
As seen in the photos below, we added 2.7k-ohm pull-up resistors to some of the robots to connect any combination of E5 E6 E7 and E8 pads to the +3.3V connection on the right rear edge of the controller. Basically, this gives us 4 bits of addressing (16 combinations), though 0x00 (no connection) is a reserved address. As you can see in the first photo, we've connected E5 to +3.3V through a 2.7k resistor, and when we read the data bits, we find that this robot has been assigned ID = 0x01.
With a second robot, we connected E6 to +3.3V through a 2.7k resistor, which provides this robot with a fixed ID = 0x02.
Robots that don't have fixed ID's are still assigned a random ID, as described earlier. Beyond this, we added commands to enable/disable a beacon transmit (xmit) function and commands to enable/disable a beacon locate function. Putting this all together with the "swarm mode" addressing functions, we have a control mechanism that provides a lot of flexibility without a lot of complexity.
| Command | Response | Description |
|---|---|---|
| 'x' | '#x' | enable "xmit IR beacon" mode - |
| robot in this mode will transmit 1's complement of its ID number | ||
| e.g. if ID = 0x01, bit pattern 0xFE will be sent via IR xmit function | ||
| 'X' | '#X' | disable "xmit IR beacon" mode |
| 'laa' | '##laa' | enable "locate beacon" mode - search for beacon with ID = 'aa' |
| only functions in "wander mode" - if beacon is detected, robot will steer toward it | ||
| though "wander mode" function will prevent collisions | ||
| 'L' | '#L' | disable "locate beacon" mode |
| Swarm Mode | ||
| 'r' | '##raa' | read robot ID bits (E8 E7 E6 E5) or pick a random robot ID number for swarm operation |
| 'aa' is an 8-bit binary value that can't equal 0x00 or 0xFF | ||
| once robot ID is set, robot goes automatically into "swarm mode" and only processes '@' commands | ||
| 'R' | '##raa' | pick a different robot ID number (used if several robots picked duplicate random ID's) |
| 'aa' is an 8-bit binary value that can't equal 0x00 or 0xFF | ||
| '@abc' | '#c or ##c...' | swarm mode command - only active after robot ID is set ('r' or 'R' commands) |
| ab = robot id, a=high digit, b=low digit, c=command | ||
| e.g. '@275' tells robot 27 to stop | ||
| if ab = 'FF', command goes to all robots | ||
| e.g. '@FFw' tells all robots to enter "wander mode" | ||
| response code is identical to non-swarm mode response for command | ||
Here's a 600kb Quicktime clip of 4 SRV-1's operating in close proximity in "wander mode", where the robot (0x01) in the lower right of the video has been designated as the beacon, and the other robots have been instructed to locate the beacon. As before, the robots are controlled by a single base station on a common radio channel using the new "swarm mode" commands. You can click on the screen shot to launch a viewer -
Posted Sat, 07 Oct 2006 22:02 | HTML Link | see additional stories ...
Fri, 06 Oct 2006some progress with "swarm mode" ...
Here's a demonstration from a first attempt at implementing new commands to support swarm operation, as described a few days ago. It seems that this will be an effective approach, and in general, the communication channels are staying clear so that there isn't much confusion, even when we ask a given robot to send images.
The only real problem we've encountered so far is with the command acknowledgment strings from a bunch of robots flooding the incoming data buffer of a robot that has been busy doing other things, and therefore causing the robot to miss a command from the host. In the worst case, the solution is to send commands individually to each robot instead of relying on the "broadcast mode" (FF addressing) to reach all robots.
Here's a 2.3Mb Quicktime clip of 4 SRV-1's operating in close proximity in "wander mode". The robots here don't have any goal except to stay within a defined area and avoid running into obstacles or each other. The robots are controlled by a single base station on a common radio channel using new "swarm mode" commands defined in the SRV-1 communication protocol update. You can click on the image below to launch a viewer ...
The next step may be to do the IR beacon experiment that was proposed earlier, but a more exciting extension would be the addition of object tracking ... so stay tuned for more news.
If anyone with multiple SRV-1's wants to experiment with this, let us know via email at support@surveyor.com.
Posted Fri, 06 Oct 2006 15:39 | HTML Link | see additional stories ...
Wed, 04 Oct 2006building a robot swarm ... some initial efforts
Part of the goal in restructuring the SRV-1 communication protocol was to build a foundation for coordinating the simultaneous operation of multiple robots on a shared communication channel. To test feasibility, we have built a version of firmware that allows multiple robots to operate on the same shared radio channel without confusion, and are preparing to take that capability to the next level by providing individual addressability of the robots on a shared channel.
The key to individual addressability is the assignment of unique ID numbers to each robot. We experimented with several approaches (e.g. radio hardware address, random memory probe, etc), and ultimately decided to let each robot pick its own ID randomly (using the on-board clock as a seed), requiring only that we add a mechanism to force selection of new ID's if there is any duplication.
From there, it's just a matter of adding some commands that are specific to multiple robot operation. As the '#' character signifies an ACK for single robot commands, we will likely use the '@' character to start any multiple robot commands, where the command format might look like:
'@' robotID command
To start, we'll use 2-digit (hex) ID's, reserving "00" for the base station and "FF" as a broadcast ID which applies to all robots. This gives us up to 254 unique robot ID's operating simultaneously on the same radio channel, so we'll likely use 8-bits initially, and using ASCII characters for the ID string allows us to test operation from a console. So as an example, a command that tells robot 27 to move forward would be '@' '2' '7' '8' ("@278").
The next step is to build some behaviors that test multiple robot operation. The first test we've planned uses the IR functionality, assigning one robot to act as an IR beacon, and assigning the other robots to converge on that beacon without any colliding with the beacon or each other. We will use the BounceIR command from the beacon, and a combination of the ListenIR command and the "wander mode" Scan function to locate and navigate toward the beacon. We'll post a video of our results once we have something to show.
Posted Wed, 04 Oct 2006 17:35 | HTML Link | see additional stories ...