Rossum -> Frequently Asked Questions
Link to The Rossum Home Page Simulator | User Forums | Project Management
Installing and Running RP1
Frequently Asked Questions
Who was Rossum? Answers to that, and other questions,
can be found here in our FAQ.



Some Questions
[1.] What is Rossum's Playhouse?
[2.] Why do you call it Rossum's Playhouse?
[3.] What does the simulator offer?
[4.] There are other robot simulators out there, many of them far more sophisticated than RP1. Why would I be interested?
[5.] If the simulator is written in Java, doesn't that mean that any client applications will need to be in Java too?
[6.] So how does a client talk to the server?
[7.] Have you implemented code to allow RP1 to talk to clients written in C?
[8.] How does one write a client? Any chance that there might be documentation?
[9.] Your demo robot doesn't look anything like the one I want to build. Did you say that the robot body is configurable?
[10.] Where does the floor plan come from?
[11.] Is Rossum's Playhouse related to the Trinity College Fire-Fighting Home Robot Contest?
[12.] A 2-D simulation is nice. Have you considered 3-D?
[13.] How many clients can the server support?
[14.] How much computer power do I need to run the simulator?
[15.] Can I run the simulator with a faster-than-real-time speed.
[16.] I would like to look at the code and perhaps collaborate on the simulator's development. How complicated is the system?
[17.] How can I contribute to the Rossum Project?
[18.] I see that the copyrighted code is distributed according to something called the GNU General Public License (GPL). What is that?
[19.] Doesn't the GPL require that I give my code away?


Some Answers

1. What is Rossum's Playhouse?

Rossum's Playhouse (RP1) is a mobile-robot simulation intended to aid developers implementing robot control and navigation logic. It allows applications to build a data configurable robot which can interact with a two-dimensional (2D) landscape. RP1 is free software. The source code and binaries are available on The Rossum Project web site.

The simulation is in its infancy. Much work remains to be done, but the design is well suited to a collaborative effort. My hope is that Rossum's Playhouse will follow the model of other "Open Source" software projects such as the Apache Web Server, the GNU C compiler and the Linux operating system (though, of course, on a much smaller scale). I am actively seeking interested parties to help with the effort.

2. Why do you call it Rossum's Playhouse?

Rossum's Playhouse is named in honor of Karel Capek's classic science fiction work Rossum's Universal Robots. In 1921, Capek's play introduced the term "Robot" (from the Czech word for "worker"). I also call Rossum's Playhouse "RP1" for short... an acronym which is useful since the full name is, well, a little too playful to be used in some circles.

Dennis Jerz sent me a link to his page where he provides more information on the story and history of the play. Rossum's Universal Robots is well worth the visit.

3. What does the simulator offer?

The RP1 simulator allows users to create robot models by specifying physical layout, wheel actuators, optical (or IR) sensors, range (or proximity) sensors, and bumper sensors. It also allows the developer to specify the floor plan for a 2-Dimensional playing area (think of a maze or a suite of offices). The simulator detects wall collisions and models sensor interactions. At present, the simulator features a simple GUI (which can be turned off) showing the robot as it goes about its motions.

4.a There are other robot simulators out there, many of them far more sophisticated than RP1. Why would I be interested?

The interesting thing about RP1 is not its implementation, but rather what it is intended to accomplish.

The goal of the simulator is to make it easier for people to build real robots. Like any simulator, RP1 lets developers test and refine the ideas more quickly than they could working with a real platform. It allows them to run tests series over-and-over again, in a simplified environment, without worries about battery life, mechanical failure, or the complexities of operating in the real world.

RP1 also offers an important economy. A robot builder who develops a system using a simulator puts a lot of effort into getting his code to work. That effort should not be wasted when it's time to move on to the real thing. When RP1 was conceived, a key consideration was that much of the code written to work with the simulator should to the actual robot more-or-less intact.

Rossum's Playhouse attempts to accomplish that end through the use of a client-server architecture.

4.b. A Client-Server Architecture?

Yes. Developers work on all sorts of systems, using all sorts of languages. Some work on big Unix boxes, others on PicStics, or Lego systems. Some write in C, C++, Forth, Lisp, Prolog, even Basic. As I said above, I want them to be able to code for their target platform, in whatever language they need to use. My simulator happens to be written in Java. Now Java is my language of choice, but I don't expect everyone else to feel the same way.

So how does code written for an embedded controller interface with a simulator running in Java on a PC? One solution is to go with a client-server architecture.

The simulator acts as the server. It provides a world in which a simulated robot can move about and interact with its environment. The thing that the robot model DOESN'T have is brains. It does not implement navigation logic. It does not have a system for mapping and exploring a new environment. Left to itself, it cannot even ask the robot to move.

All of that is the work of the client. A developer wishing to test his concepts may do so by writing a client. The client tells the robot things like "move forward." The simulator may tell the client that a contact sensor has bumped a wall or that an IR sensor has detected an emitter. The developer can use the data and control the robot motions as appropriate.

5. If the simulator is written in Java, doesn't that mean that any client applications will need to be in Java too?

No. Recall that in the classic client-server architecture, the client and server are two separate programs. They don't even need to be running on the same computer. So it doesn't matter what language a client program uses or upon what kind of box it runs. The only real requirement is that it be able to manipulate standard data formats (integers, floats, etc.) and talk to a tcp/ip connection. Even in the case of an embedded controller that does not implement a tcp/ip stack, it may be possible to run the code for the embedded system on a PC while working with the simulator. Once the client logic out-grows the simulation environment, it could be ported to the embedded system relatively intact.

6. So how does a client talk to the server?

The client communicates through a socket connection. The server does not need to be on the same host as the client, though it often will (using the "loopback" IP address 127.0.0.1).

RP1 implements a simple protocol for client-server communications. The client sends messages called "requests" to the server. The server sends messages called "events" to the client. If you look at the RP1 code, you will note Java classes corresponding to each:

   RsWheelMotionRequest.java     (request that wheels begin motion)
   RsPositionRequest.java        (request position of robot simulacrum)
   RsSensorStatusRequest.java    (request status of a sensor)

   RsMotionHaltedEvent.java      (notifies client that motion halted)
   RsPositionEvent.java          (generated in response to position request)
   RsSensorEvent.java            (generated upon request or change in sensor status)

Each of the messages supported by the system is represented by a Java class. They are simply collection of data elements, similar to C structures or Pascal records. Java has a very nice mechanism for communicating data objects between applications (object serialization) but, to support non-Java clients, RP1 does not use it. Instead, it transfers messages using data primitives such as doubles and 4-byte integers.

7.a. Have you implemented code to allow RP1 to talk to clients written in C?

Absolutely! It was a long time coming, but it's finally here. In the classic open-source tradition, a C/C++ API was contributed by a volunteer who needed an API for his own work. You can find James Y. Wilson's excellent API on our downloads page.

7.b. You documented the RPI comm's protocol, right?

Unfortunately, no. But I did the next best thing. Knowing that I wouldn't have time to write a protocol document, I decided to write the Java code in such a way that it would be easy for an interested party to figure out how to do the job himself (or herself). Ignoring the cannons of object-oriented programming, I concentrated most of the code for client-server communications into two big switch statements. While it's not my favorite way to create an architecture, that approach should make it easy to find what you need.

The three main classes for RP1 communications are:

      | RsClient     |----- >|           |
                             |RsProtocol |
      | RsConnection |----- >|           |


      RsClient.java        Code for Client-side communications
      RsConnection.java    Code for Server-side communications
      RsProtocol.java      Code for data elements and methods (functions)
                              common to both client and server;

A couple of other classes, RsBodyEncoder.java and RsBodyDecoder.java include functionality that should really be rolled into RsClient and RsConnection.

8. How does one write a client? Any chance that there might be documentation?

Yes. I am pleased to say that the Users Guide is finally done. It is available from this site in the widely-used Adobe .pdf (Acrobat) format.

Also, I've worked hard to make the source code accessible. Two demonstration clients are available: Client (in the clientzero directory) and Demo (in demozero). Client is a good place to start. Demo simply extends client by adding a Graphical User Interface. Even if you don't work in Java, the code for these clients will help give you some idea of how the system is put together.

9. Your demo robot doesn't look anything like the one I want to build. Did you say that the robot body is configurable?

Yes. The first thing a client does when it connects to the simulation is to upload a body plan. There is no default robot, you have to specify yours. Look at ClientZero.java for code showing how a robot is created.

10. Where does the floor plan come from?

The floor plan comes from a text file in a format which is, as you might expect undocumented. The initial release includes one floor plan, a file named "trinity98.txt" which models the arena for the Trinity College Fire-Fighting Home Robot contest . Floor plans are kept in a subdirectory called FloorPlan. Using the trinity plan as a model, it should be straight-forward to write new ones.

Incidentally, the number one item on my "wish list" for contributor code is a simple CAD tool for building floor plans. This would be a great project for somebody who wants to "flex their graphics programming muscles."

11. Is Rossum's Playhouse related to the Trinity College Fire-Fighting Home Robot Contest?

RP1 has no association with the Trinity Contest. The contest was the inspiration for the simulator. Building a robot for the competition seemed like an interesting problem. Lacking the time, skill, and resources to do so myself, I wanted to make some contribution to those who were. I thought that having a simulator like Rossum's Playhouse might help improve the baseline of navigation and control software available to the robot builder.

Anyway, Trinity is a nice college. The contest is a serious blast. I encourage you to check it out.

12. A 2-D simulation is nice. Have you considered 3-D?

I would like nothing better than to implement a 3-D system. But the level of effort is considerable. Building one would be a full-time job. I hope that 3-D is something we can work on in the future, but I think we need to see how the 2-D version shapes up before we even consider it.

Also, don't underestimate the value of a 2-D simulation. While a real robot is a three-dimentional entity, there are broad classes of navigation and control problems which take place almost entirely in two dimensions.

13. How many clients can the server support?

In the current release, just one. The system is designed to support multiple clients, but not all the necessary functions are implemented at this time.

14. How much computer power do I need to run the simulator?

Not a lot by contemporary standards.

Most of my development has been on a 166 MHz Pentium running Windows 95. It's more engine than I need for the current version. The simulator does run better with a Just-In-Time compiler (JIT). JIT compilers are available in most Integrated Development Environments (JBuilder, Symmantec Cafe, etc.) or in the current JDK which can be downloaded directly from Sun Microsystems.

The current version requires about 400 kbytes disk space for the compiled class files, source, and documentation. About 150 kbytes without the source.

15. Can I run the simulator with a faster-than-real-time speed?

Absolutely.

The simulator is designed to run just as fast as system performance will let it go. Of course, this works better when the GUI is turned off. Such an approach allows you to perform high-volume testing of your client logic and would be useful for genetic algorithms or other such approaches.

The simulation speed is specified in the Server.ini file located in the main directory of the software directory. You may set the speed value as high as you please, but you should keep an eye on system timing issues. The time spent on client-server communication becomes more and more important as you increase the simulation speed.

16. I would like to look at the code and perhaps collaborate on the simulator's development. How complicated is the system?

The RP1 server is a multi-threaded Java application, and you might have a bit of trouble following it if you do not know the basic outlines of Java threading. The User's Guide provides a "structural overview" of the simulator... this will at least give you a starting point for looking at it. You may also look at the RsProtocol classes mentioned above. Check out SimTaskQueue.java, SimScheduler.java, and then the SimRequestHandler classes.

In terms of the mathematics... there isn't anything a bright high school student shouldn't be able to follow. An especially bright high school student should be able to improve on it.

In terms of algorithmic complexity... there's nothing worth an Undergraduate Thesis. The simulator is actually a lot simpler than I thought it would be when I started. The real impressive stuff is going to happen in the clients.

17. How can I contribute to the Rossum Project?

If you have an idea about something you’d like to do, email me at gwlucas@users.sourceforge.net.

What I'd like to see most is some smart client implementations. I think that offers an opportunity for somebody to garner major coolness points. At this point, these would best be written in Java.

There are plenty of things that can be done in software. We can talk about these. The GUI is pretty bare-bones and could stand to be dressed up a little. Because things are still in flux, it is probably premature to write a C-language API (unless you were willing to keep updating it as the Java implementation changed).

The other thing I need, though, might surprise you. At this stage, what I am really hoping for is feedback from users and potential developers. What features need to be added to the simulator? How can we make it better serve the community of robot developers? How do we model different kinds of wheel systems? Should we implement a robot simulacrum that has moving parts (such as a gripper or a rotating sensor turret)? If so, how?

Here are some of the areas that have potential for collaboration:

18. I see that the copyrighted code is distributed according to something called the GNU Public License. What is that?

The GNU Public License (GPL) is a widely recognized software license. The GPL was chosen because it provides a framework in which developers can write and share code. It has been used for several important collaborative software efforts including the Linux operating system and the GNU C compiler (gcc). The GPL was developed by free-software advocate Richard Stallman and is a key component of the free-software movement (which is sometimes also referred to as as the "Open Source" software movement).

The statement of the GNU Public License is provided in a text file, gpl.txt, which is provided with the RP1 software distribution. The file also provides a nicely written, quite readable explanation of what the GPL is all about. A web page with the GPL is at the Free Software Foundation.

19. Doesn't the GPL require that I give my code away?

Absolutely not.

The only mandatory application of the GPL is to any work derived from GPL-licensed code. For example, if you were to modify the RP1 simulator, which is distributed under the GPL, you could not sell it as your own product (you would have to distribute it under the GPL). On the other hand, if you were to develop robot software using the RP1 simulator as a tool, you would in no way be required to apply the GPL to your own work (unless it included components from the RP1 software distribution).

Furthermore, GPL code is not in the public domain. It is copyrighted and distributed under a generous, but not unconditional, license. The Free Software Foundation also offers a licensing document for people who wish to distribute binaries.

Of course, I would like to see people contribute code. But the last thing I want to do is to erode anybody's livelihood. Your own work belongs to you and you may do with it as you please.


Return to our Home Page

Copyright (C) 1999 by G.W. Lucas.
Permission to distribute verbatim copies of this FAQ is granted provided that the contents are not modified and the copyright notice remains intact.