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:
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.