To Do list for the Flat Robot Simulator
Mike Hewett
9 March 2000
Current version: 4.1
Capabilities:
- Accurate physical simulation of Spot, an RWI robot.
- Simulation of a static physical world containing
walls.
- User-level startup files for problem-specific configuration.
- Sonar simulation, including an optional noisy model.
- Laser rangefinder simulation for one or two
rangefinders, including an optional noisy model.
- Two operating modes: simulation mode, where simulated
time progresses at constant time intervals; and
real-time mode, where the simulation travels at the
same speed that the control law executes.
- Several routines for processing rangefinder data:
- Creating line segments from data.
- Detecting large jumps in the data.
- A simple open doorway detector.
- An open-space detector.
- Turning rangefinder readings into robot-centric readings.
- The Flat Display, which is a separate program that
can display multiple robots in a simulated environment,
and has separate sensor displays for each robot. In
addition, the sensor displays can be overlaid with other
information such as points and line segments.
Rangefinder data can also be logged.
- Several utility displays for: replaying laser data,
displaying dynamic bar graphs or a strip chart, etc.
- Several example controllers, in LISP, Java, C and
LabView. The LISP controller (flat-client) is currently
the most full-featured of the examples.
- A full-fledged controller (flat-lisp) in LISP and Scheme,
that is used with the wheelchair.
Completed updates
-----------------
v4.2: Curently, if the rangefinder simulator calculates a
distance greater than the maximum range of the rangefinder,
it sets the reading at the maximum range (currently 25m).
This is incorrect. There should be no reading at that
distance.
Fix: If the distance is greater than the maximum range,
the result will become -1. These readings will then
be filtered out when calculating robot-centric readings.
Users should be aware that there will now be "holes"
in the rangefinder readings.
Estimated date: March 15, 2000
Completed: March 15, 2000
Future versions:
---------------
v4.3: Currently, Flat sends rangefinder readings to the
controller on every simulation cycle. These readings
are in rangefinder coordinates, which is not a good idea,
since the client has to know where the rangefinders are
in order to interpret them.
Fix: Change the content and format of data sent to the
Flat clients so that the content is robot-centric
and the format is (r theta) ordered from left to right.
*NOTE: INCOMPATIBLE CHANGE. ALL CLIENTS MUST BE MODIFIED.
Estimated date: March 31, 2000
v4.4: Flat Display changes:
- Add the ability to specify whether data sent to a
sensor display should replace the current display,
or be overlaid on the current display.
- Have Flat tell the display which sensors a robot has.
This will eliminate the display space used by
the seldom-used sonar display.
- Make the LaserCanvas and other displays be auto-resizable
so if the user resizes the window, the individual displays
change too.
- Add a Vulcan robot type, in which the the robot's shape is
different than the Spot robot type.
- Add replacements for the remaining Flat displays,
so that the Flat dependence on X-windows and its
antiquated Graph package is gone.
Estimated date: April 15, 2000
v4.5: Modify Flat so that it doesn't die every time a
client quits.
v4.6: Create wheelchair-specific parameter files for Flat,
similar to robot/rwibase.h and robot/rwisonar.h.
Make minor structural changes to Flat to allow multiple
models to be available, and to allow the client to
specify which model should be active.
v4.7: Add odometry as a sensor.
Allow the user to turn sensor streams on/off at runtime,
not just in the configuration file.
v4.8: Implement, using the Java JMF libraries, and the JMPlayer
application as a model, a video data stream, so that movies
or images can be used as simulated robot sensors.
- Modify Flat Display so that the sensor panel can
contain video images.
v4.9: Add code to Flat so that a video stream can be
a sensor.
v5.0: Allow Flat to simulate a dynamic environment containing
moving objects.
v5.1: Allow a Flat world to contain multiple robots.
The best way to do this is probably to separate the
world simulator from the robot simulator to become
the FlatWorld server.
Robot simulators like Flat would then contact FlatWorld
to tell it where their robot is. This would allow other
simulators besides Flat to use FlatWorld.
FlatWorld would return sensor readings to the different
robot clients (using a separate SensorSimulator server?).
The current Flat Display will serve as the display
for the world simulator without any changes, or at least
without any major changes.
*** Possibly at this point we Open Source the code to
*** allow the world to hack on it and create the next version:
v6.0: Flat3D. Complete rewrite, possibly using Java3D or
a one of the C graphics packages. We should have enough
processing power by now to do 3D world simulation,
including simulated camera input.