Robomagellan contest disappoints

This weekend I attended the annual “Robogames” competition, which took place here in the Bay Area. Robogames is mostly a robot battle competition, with a focus on heavily armed radio-controlled robots fighting in a protected arena. For several years robot fighting was big enough to rate some cable TV shows dedicated to it. The fighting is a lot of fun, but almost entirely devoid of automation — in fact efforts to use automation in battle robots have mostly been a failure.

The RC battles are fierce and violent, and today one of the weapons of choice is something heavy that spins at very high speed so that it builds up a lot of angular momentum and kinetic energy, to transfer into the enemy. People like to see robots flying through the air and losing parts to flying sparks. (I suspect this need to make robots very robust against attack makes putting sensors on the robots for automation difficult, as many weapons would quickly destroy a lot of popular sensors types.) The games also featured a limited amount of automated robot competition. This included some lightweight (3lb and 1lb) automated battles which I did not get to watch, and some some hobby robot competitions for maze-running, line following, ribbon climbing and LEGO mindstorms. There was also semi-autonomous robot battle called “kung fu” where humanoid robots who take high level commands (like punch, and step) try to push one another over. There is also sumo, a game where robots must push the other robot out of the ring.

I had hoped the highlight would be the Robo-magellan contest. This is a hobbyist robot car competition, usually done with small robots 1 to 2 feet in length. Because it is hobbyists, and often students, the budgets are very small, and the contest is very simple. Robots must make it through a simple outdoor course to touch an orange cone about 100 yards away. They want to do this in the shortest time, but for extra points they can touch bonus cones along the way. Contestants are given GPS coordinates for the target cones. They get three tries. In this particular contest, to make it even easier, contestants were allowed to walk the course and create some extra GPS waypoints for their robots.

These extra waypoints should have made it possible to do the job with just a GPS and camera, but the hobbyists in this competition were mostly novices, and no robot reached the final cone. The winner got within 40 feet on their last run, but no performance was even remotely impressive. This was unlike past years, where I was told that 6 or more robots would reach the target and there would be real competition. This year’s poor showing was blamed on budgets, and the fact that old teams who had done well had moved on from the sport. Only 5 teams showed up.

The robots were poor for sensors. While all would have a GPS, in 1 or 2 cases the GPS systems failed and the robots quickly wandered into things. A few had sonar or touch-bars for obstacle detection, but others did not, and none of them did their obstacle detection well at all. For most, if they ran into something, that was it for that race. Some used a compass or accelerometers to help judge when to turn and where to aim, since a GPS is not very good as a compass.

All the robots tended to have a video camera, but the only purpose of the camera was to look for the bright orange colour of the cones when the robot got close enough to aim for it. The cameras were not used for obstacle avoidance.

I had hope for the youngest contestant, an 18 year old named Tony, as his robot could back up when hitting obstacles and tried a slow but steady course. Unfortunately hardware issues with his touch-bar kept his XO powered robot stymied. This race was an important reminder of how much hardware failure and circumstances on the ground can lead to failure in a driving robot. Sensors and motors will fail. Wires will come lose in low-budget robots not used to rolling on rough surfaces. Our robocar simulators, when we build them, just regularly simulate mechanical and electrical failures. In a simulated world, having backup sensors is “free” but it’s important that the algorithms be designed to detect and deal with failures, and to switch to backups if they are available. In the real world, there will be fewer backups, but they will be there.

The biggest reason for the failures here was the inexperience and low budgets of the teams. While LIDAR is the sensor of choice in almost all autonomous wheeled robotics today, LIDARS are beyond the budget of these teams. Open source robotics tools like ROS and OpenCV are helping hobbyists do more with robotics, but there is still much more to be done. And this particular contest seemed to just have a bad set of circumstances.

I hope that if we can get the simulator project off the ground it will encourage both hobbyist creation of robot algorithms, but also active contribution of elements of the simulator to make it match the real world more and more. The simulated world needs to have bumpy terrain, varying traction, and sensors and other elements which fail. It needs to have varying lighting and as much as it can from the real world.

Here a heavy robot throws another in the air with its lifter, another common weapon.

This robot was the winner, but here it’s hitting a bonus cone entirely by accident, and giving up.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options