TeamBots is a system for developing and running multi-robot control systems on mobile robots and in simulation. TeamBots is freely distributable, but it is copyrighted by the Georgia Tech Research Corporation. TeamBots was developed at Georgia Tech's Intelligent Systems and Robotics Group by Tucker Balch, Juan Carlos Santamarķa and David Huggins.
Download it from http://www.cs.cmu.edu/~trb/TeamBots
Instructions are on the main page: http://www.cs.cmu.edu/~trb/TeamBots
Unzip and Java 1.2 or newer. You need gmake if you want to (elegantly) revise and recompile.
Probably the best source is the example file in Forage/forage.dsc. It is fairly well documented.
Robots have two components, the physical part and the control system part. Both have takeStep() methods that are called on every cycle.
Use the "timeout" and "trials" keywords in the description file. "timeout 10000" for example, will run the simulation for 10 seconds, then terminate the simulation. If you also add a "trials 100" statement, then your simulation will run 10 seconds 100 times. Note that the trialEnd(), trialInit() and quit() methods of your control system will be called at the appropriate times. This allows you to log data and open and close files as the need arises. quit() is only called once at the end of the simulation.
You may also want to run your simulation using TBSimNoGraphics instead of TBSim. This program runs about 10 times as fast but with no graphics.
Yes. Use the TBSimNoGraphics application instead of TBSim. The program runs about 10 times as fast. The command line is
java TBSimNoGraphics description_file
Maybe. There is a working version of TMSim designed to run as an applet (TBSimApplet). The reason for the uncertainty is that TeamBots requires Java 1.2 support and under Linux (where TeamBots is developed), Netscape does not seem to fully support the 1.2 AWT, so it can't be tested.
Testing and debugging this feature is definitely on the ``to do'' list for the next release.
Some researchers are concerned that Java is too slow to support real time robot control. Our experience contradicts this conclusion. As an example, in simulation (without graphics) our Java coded behavior-based control systems run at up to 30 KHz rates on conventional 200 MHz Pentium machines.
The primary bottleneck to runtime efficiency on real robots is sensor and control I/O. On Nomad 150 robots for instance, we are limited to 10Hz control rates because this is the maximum rate control commands can be transmitted to the robot (control programs written in C cannot run any faster).
The benefits of Java (portability, correctness, ease of use, rapid development) far outweigh the negligible runtime overhead.
Finally, Java compilers that offer runtime speeds as fast as C++ are already available (take a look at the compiler by Tower for instance).