| Rossum | |
Frequently Asked Questions |
|
|
|
 |
|
|
Simulator |
User Forums |
Project Management Installing and Running RP1 |
|
| Frequently Asked Questions |
|
|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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."
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.
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.
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.
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.
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.
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.
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:
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.
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