| 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.
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.
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.
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 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
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 Public License. What is that?
19. Doesn't the GPL require that I give my code away?
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.