The Transterpreter Project

Concurrency, everywhere.

Robotics Simulators

In working with the Player/Stage simulation environment, we're finding that the use of TCP for data transmission from robot (server) to user's code (client) was a problematic choice. In trying to develop occam programs that make use of the libplayerc library, it becomes very clear that a fundamentally concurrent programming language, capable of running tens of thousands of threads---casually---on modest hardware allows for much more natural control paradigms than a polling loop. Furthermore, the use of TCP means that the network itself becomes a buffer (and bottleneck) for data, whereas I'd rather be guaranteed the most recent data from the robot anytime I ask for it. If I could figure out how to ask the robot to give me data...

As a result, I'm interested in other simulation environments---but only in a casual way. The problem is, we actually have a Pioneer3 robot, which means having a simulator for that particular robot is a Good Thing.

However, I wanted to be able to find these links again, so here they are:

  • RobotBattle, a robot programming game that apparently/probably uses a high-level "scripting language."
  • C++ Robots, which lets you program a bot in C++ and pit it against others in an arena... somewhere.
  • Autonomous robotic soccer, which has a Windows/DOS simulator, but no source.
  • Simbad, a 3D robotics simulator written in Java. Open source.
  • Bugworks, a little robot simulator that looks completely unlike what we want.
  • eyeWyre makes Simulation Studio, which seems to be BASICStamp focused.
  • Webots looks great, but costs an arm and a leg. I cannot afford this, without a substantial grant. And even then, our students wouldn't be able to go home and use it themselves.
  • MOBOTSIM is Windows only, and simulates "differential drive" robots. In other words, no physics, no particular robot.
  • MOBS is another distributed client/server architecture that is probably written to suit C hackers, not people programming in languages like occam and Erlang.

Yes, Player/Stage is "best of breed" in many ways, but it doesn't seem to be trivial to support several thousand robots in the simulator. This is frustrating, especially when you have a language that makes it easy to control this many robots...

Update 20060208: I received some feedback from the P/S mailing list, and it looks like some of the problems we're having might be our own. That's reassuring. And, I found the RoboCup Soccer Simulator, which looks like it could make a great platform for a third-year project. There's a real opportunity for a student or team of students to do some interesting work researching architectures and approaches to robotic team control, and implementing a football team.


  • Posted: February 5, 2006
  • Author: Matthew Jadud
  • Comments: None
  • Tags: None