|Surveyor Robotics Journal|
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.
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
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.
Sat, 28 Oct 2006
first 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.
Thu, 26 Oct 2006
extending 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.
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 -
Wed, 11 Oct 2006
more 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:
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.
Sun, 08 Oct 2006
more 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.
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 -
Fri, 06 Oct 2006
some 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 email@example.com.
Wed, 04 Oct 2006
building 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.