Overview

t-bots is the team of simulated robotic units developed at the Robotics Laboratory of the University of Pavia for participating to the simulated contest of CiberMouse'08.

t-bots is a team of co-ordinated mobile units designed for the collaborative search of a target goal at unknown location within a workspace where obstacles limit the mobility of robots. The final goal of the team is to make all the team robots to reach the final target location and to enter a delimited target area. The strategy of each robot depends on the information that are gathered during the exploration. Such information can be acquired by sampling onboard sensors or can be received from other mobile units, thus exploiting the communication capabilities of robots.

A Finite State Machine (FSM) determines the mobility strategy, the co-ordination and operational modes. The FSM’s state change is triggered by the information collected by the robots and by the information received from other robots using wireless communication devices.

Downloads

• The source code of the final version, which actually run during the official competition.
• The paper describing the fatures of t-bots.
• The presentation performed during the competition.

t-bots are implemented in C (what else? :-)). They feature some good characteristics but has also some known but not yet fixed bugs. This is due tu the lack of time for testing and fine tuning, and hopefully I will deal with those issues in the next future.

Anyone who download the code, use it and detect some problems, is highly invited to drop me an e-mail.

Relevant features

• The adjust_angle function implements a proportional controller to rotate the robot to the desired direction. It is the building block of all the implemented strategies.
• The adapt_speed function is used to dynamically scale the speed, adapting the maximum speed while the time is running over.

Known issues

• During the boundary following phase, the robot sometime can’t recognize to be back to the hitting point, so could move around an obstacle indefinitely.

The competition

t-bots won the second prize at the official competition.

t-bots performed very well during the competition. The robotic team won with large discard the first two stages, allowing in both cases 4 of the total 5 robots to enter the target area, while the remaining one was just outside the area.

One of the most effective strategy consisted in gradually increase the robot speeds, starting with very low speed to spread the robots, and increasing the speed after a while, when robots would not interfere anymore each other.

The entering strategy was not used, since the short time available per each run did not suggested to keep the robots alive when inside the target area. A pity.

In the final round, t-bots scored 510 points, while the winner scored 504. There is to say that, due to the hang of the network interface on my laptop (couldn’t ping the server…), 2 out of the 5 robots lost control, and just stopped working. Strangely, the third robot running on my machine continued to work… I’m really curious to know what could have happened from the log files stored by the organizers.

Others teams was featuring more complex strategies than t-bots (in my opinion), but maybe due to such complexity, most of them failed in having an effective mobility control. One of the features that was more impressing and interesting has been the mapping of the environment to detect visited areas, in order to optimize the search of the goal.

Tools

For working on t-bots I used the following tools:

• Operating system: Debian GNU/Linux
• Compiler: GCC, the GNU Compiler Collection, version 4.3.2 (Debian 4.3.2-1)
• Editor: GNU Emacs, version 22.2.1
• Versioning management: Mercurial

My “ideal” robot

Looking at t-bots compared with other teams I saw during the competition, I elaborated some ideas (guidelines?) for my “perfect” robot:

• the noise on the GPS readings are the main limitation for implementing a precise mobility strategy; I think a good filtering based on a Kalman filter would solve lots of problems, since we would get a more precise estimation of the current position!
• a simple but effective mapping could improve a lot the effectiveness of the QUEST mode; dividing the arena in small chunks and visiting all of them, while keeping the connectivity among the robot will be perfect; moreover, after having found the target area, the information on the map would allow to use some graph-based strategy to reach the target faster than using the tangent bug;
• in the BEACON FOUND mode it would be interesting to elaborate a strategy based on the Bug 2 algorithm rather than on the tangent bug, since we don’t know the exact target location but just the direction to the target.