OOMRM Mobile Robot Simulator and Workshop

The OOMRM Workshop

Before, there existed several applications:

• Mobile Robot Simulator
• Scene Editor
• Platform Specification Editor (new)

Workshop Functions

As previoiusly mention, the workshop incorporates several different functions into one application. These functions break down as follows:

• The Map tab contains the Simulator and the Scene Editor. These two functions both use the same map interface. The intended use is that when designing a scene. The simulator's function are not simply activated. But in reality, The map can be dynamically modified in the middle of a simulation run (not suggested).
• The Platform tab contains the Platform Editor. The mobile robot specifications can be quickly reviewed or edited from this screen. In addition, many of these can be easily downloaded into the robot or uploaded from the robot when needed.

  Platform Editor

  The platform editor is divided into two sections:

  1. Invariant/Playback: These are the invariant parameters that represent the "ideal" dimensions of the robot used in the simulator (See Error Model for more information. The invariant robot is displayed during playback mode.
  2. Simulant : The represent the parameters that will be used in the simulator.
  The platform editor allows inspection of the mobile robot's specifications. This includes the wheelbase, wheel diameters, platform maximum velocities, stall currents, and JAUS node identification for host or target.

  Scene Editor

  The scene editor allows not only for external maps (Scene files or Autocad DXF files) to be loaded into the simulator, but also allows for the initial placement of the robot. This is controlled by the Input box in the terrain bar; the initial value is Terrain. You can also select Robot to select the initial robot position or Waypoint to change a waypoint. Before changing a waypoint, you must first select (highlight) the waypoint in the waypoint window to the left. If there are no waypoints, then you must add a waypoint via the add button below the waypoint window.

  Simulator

  In short, the simulator takes the same code base for the OOMRM library and compiles it using the Windows GCC rather than the 68332 cross chain. In addition it installs a core host interrupt handler (or uC/OS-II).

  A basic GUI interface was created to be able to view certain "core" objects like the oEncodedMotor, Waypoint_Driver, etc. This is supported by the Object_List class that maintains a list of objects as they are instantiated. Thus, As long as the basic program does most of its work using the class interfaces (and in interrupts), it provides a decent feedback. This is especially true of simple navigational classes.

  The real key to the simulation is in the emulation of the encoder count on the oEncodedMotor--given the configuration of the robot in the platform_specification, it estimates the number of clicks to output to the encoder channel.

  Getting Started

  The four buttons along the top left RUN, PAUSE, CONT, and NEXT control the simulation. The RUN (F5) must be pressed to start the simulation. To run the simulation one increment at a time, the NEXT (F8) button is used, and CONT (F6) causes the simulation to perform the increments continuously in the frequency indicated by the "freq." slider. Lastly, PAUSE (F4) pauses the simulation where it must be stepped or continued again.

  The step slider next to the Freq. slider indicates how many steps are performed for each iteration of the simulator--in this case, for each iteration of the simulator, only one call to the scheduler is performed. Each step performed is equal to the oScheduler period (usually 10 milliseconds). To the right of this is the time slider Freq., this simply controls how fast the simulator scheduler will run-it does not affect how the simulation runs. The steps and frequency together can be used to control the speed of the simulation. There is a maximum speed dependent upon the speed of the host processor running the simulation.

  NOTE: running the time too fast along with low increments will occasionally slow the simulation greatly as the interrupts begin thrashing.

  Simulator Menu

  Host Submenu

  Load Grid From File

  Loads an existing grid file into the simulator. The grid can be loaded either to robot's grid or the world grid or both.

  Load Checkpoint Log

  Loads an previously recorded checkpoint data log that was created via the log class.

  Import DXF

  Imports a AutoCAD format file into the simulator into either the robot's grid or the world grid.

  Exit

  On exit, the simulator saves the invariant defaults into the OOMRM.ini file and the persistent memory into the RAM.ini initialization file.

  Target Submenu

  The Target functions all require an attached target 68332 or other supported processor.

  Upload Robot Grid

  Allows the transfer of the target's robot internal grid to an attached host into a file (scene.scn).

  Upload Log

  Allows for the transfer of the checkpoint log from the target 68332 to an attached host.

  Download Scenario to Robot

  Allows transfering of the robot's internal grid into a host file scene.scn. Currently, the file will be overwritten without prompting.

  Emulate Download

  Most likely not needed. forces the transfer of data into the SCI port (and RX data buffers), thus allowing debugging of the 68332 SCI sci_handler callback function itsself. Of course, no data is actually transferred, but it allowed the running of the SCI callback on the host; the was useful in debugging an internal SCI data overflow problem.

  View Submenu

  Refresh

  Performs screen refresh. Should no longer be needed.

  Show Path Area

  Shows the outline of the region marked as an obstacle internally in the A* routine. useful for detail debugging of A* behavior.

  Show Path

  Displays the entire path between two waypoints as a series of solid lines.

  Show World

  Toggles display of the World Grid

  Show Robot

  Toggles display of the robot's grid.

  Show A*

  Toggles display of the internal A* algorithm's grid. This grid is often different from both the robot's grid and the world grid.

  Control Submenu

  These allow control of the simulation. See Getting Started for more information.

  Map Lines Submenu

  Screen Layout

  In Figure 1, we see the screen has 60 "Divisions", this implies that 60 lines are displayed on the screen (if possible). The maximum number of lines is determined by the GRIDX and GRIDY dimensions of the OGrid class. Changing divisions allows for more or less of the map to be displayed on the screen at one time. Also notice, the map is divided visually into different tiles-in the above display, it is set at 12 meaning that every 12th line will be visually differentiated. This is simply to ease visual identification. Finally, notice the "mm/div" pull-down tab is set to 25.4 which means that each cell on the map represents 25.4 millimeters (one inches). Thus, in the above display the map represents about 3'x3.5' area with easy identification of one foot tiles-the tiles allow for easy tracking of distances. The coordinate units the simulator displays can be changed by changing the "Unit" pull-down tab. Currently, inches, millimeters, and centimeters are supported. Note that internally, everything is done in millimeters, thus some displacements like the map "mm/div" is set to millimeters regardless of how the unit is set. The grid lines can be hidden by deselecting the "Map lines" menu. Currntly, you can select to show all, hide all lines, or show only the major divisions; in this case, the one foot tiles only. Also, below the map are the various tabs for objects (classes) that are defined in your program. There is usually one tab for each class defined, but not every class is tracked in the simulator. These tabs allow for inspection of most of the low level attributes of that class while the simulator is running.

  Tools Submenu

  Range Sensor Stimulator

  The range sensor stimulator (RSS) allows for simulation of events like waving your hand in front of the robot; i.e., it allows a range sensor to register an object a given distance away independent of current map content. Currently, this does not get reflected back on any of the maps. Refer to oomrm/src/host/fluid/fl_rss.fl for implementation.

  Navigational Paths

  OOMRM generates different levels of paths. On the lowest level, the Primitive_Driver, it generates a path from a single point to another point. The Init. Position display shows the first point (X/Y coordinates) in the Primitive_Driver. This path is represented by a thin line on the map and cannot be toggled off. The path generated from the Waypoint_Driver is shown as line segments with filled cells where the line passes. Thus, the Waypoint_Driver pass will usually eclipse the Primitive_Driver path. The Waypoint_Driver path can be toggled via the View->Show Path toggle. Lastly, internally the simulator creates an imaginary region that the robot cannot enter, this region can be displayed via the View->Show Path Area toggle.

  Navigation and Internal Occupancy Grids Arrangement

  There are three internal grids that can be displayed at any one time. There is the top level real world map marked by an "W" checkbox. Under this level is the robot's scenario grid used by the robot ("R" checkbox). This oftentimes starts blank and is incrementally filled in as the robot scans the environment. Notice also, that due to sensor error, the robot may mark cells as occupied that are not occupied in the scenario. Lastly, the A* internal grid ("A*" checkbox) can be displayed; usually this grid is initialized with the robot's map, but it also alters the grid. Note, at each level, there may be discrepancies between maps due to the error associated at each level.

  The world grid usually never changes. The scenario will usually not change also, but will incrementally change as objects are deleted or added. Also, once the A* grid is initialized, it also never changes, even if the robot sees new obstacles. If the new obstacle lies on a path planned by the navigational planner, then it will abort the current planning event, and cause a re-planning episode to occur re-initializing the A* grid with the new robot's grid.

  Simulated Hardware

  The simulator emulates several different actuators and sensors. Each has different unique characteristics.

  oEncodedMotor

  As mentioned previoiusly, the battery method allows configuration of the encoded motor. This allows the initial power setting to achieve a given speed to be derived. The simulator reverse engineers based upon these parameters how many encoder clicks it would take to get the robot moving a given speed.

  oServo

  The servo is not directly emulated, but is emulated when used in tandem with the sensor bases (IR_base and sonar_base). The sensor base class allows for a positioning of the servo at the given position. Note, that I have not accounted for mounting the servo upside down (this needs to be validated).

  IR_base

  The IR base allows one of the currently supported IR sensors to be mounted on the robot at a certain position with a given facing. With this information, in addition to the world map, the simulator can determine how far to the nearest obstacle.

  sonar_base

  Currently the sonar uses the same algorithm as the IR. This does not account for the wider field of view nor for reflections. This is an area for improvement in a future release.

  oCameraGB

  The Gameboy Camera is emulated to a limited extent. I used the camera for line following where the filled in cells represent a black line rather than representing obstacles; once again, the line was reverse engineered by calculating the position of the camera relative to the lines in the world grid. A more complex algorithm would be required to emulate an actual image capture.

  Error Model

  Part of the design of the simulator includes the foundation for an error model for testing local localization due to dead-reckoning error accumulation. These terms are collectively referred to as the invariant parameters. Within the invariant class is also the World Grid. In any mobile robot there are many sources of errors introduced including:

  1. Inaccurate measurements (wheel diameter, wheel base).
  2. Calculation drift (float versus fixed point etc.)
  3. Initial Placement error (pose)
  4. Map Correspondence errors or misalignment/map size discrepancies.

  The simulator currently allows for simulation of the former two error sources, but it requires setup before the error model can be used. First enter the invariant parameters in the simulator; these allow entry of actual values that differ with the values used internally in the robot (the entered values are stored in a configuration files between runs). Simply select "Model->Platform Invariants" from the menu and input the following terms:

  • wheelbase: The wheelbase has an effect only when turning.
  • wheel diameters (left/right): The wheel diameters will affect
    • Straight line motion if only the ratio between the left and right wheel diameters are incorrect.
    • Both straight line and pure turning motion when the average of the two actual wheel diameters differs from the nominal wheel diameter. Usually this can be compensated for by simply measuring distance robot actually travels compared to expected distance.
  • Motor "stall" current: this will affect how fast or slow the robot starts as the initial power setting is based upon these parameters, but if they are unequal, then this will result in a natural left or right robot drift. Note, this has nothing to do with the software, but is simply one motor being more efficient than the other. Usually drift is compensated for because with cruise control enabled, then both motors will attempt to maintain the same speed; consequently, the speeds will only be unequal for a short period of time.
  • Motor maximum speed: Similar to stall current affects how fast or slow the robot initially starts or drift if unequal.

  Note: Currently, there is no way to simulate an error in the encoder count per revolution; if incorrect, the speed of the simulator will look right, but the robot will actually travel slower/faster depending upon the magnitude of the error.

  These represent what the real world dimensions are--why should these differ from what is input into the robot? In order to understand this, lets look at what kinds of error the invariant shows:

  1. The error resulting from fixed point calculations can be seen.
  2. Sometimes only integers or fixed point are input into the actual robot whereas the invariants are all float.
  3. No one can ever get the exact figures for the wheel base. Trial and error is sometimes useful to see how large an error is introduced by introducing an error in one or more of the invariants.

  The normal simulation robot is displayed in red whereas the actual position of the robot as calculated from a parallel floating point calculation using the invariant parameters is black. Thus, there are two primary anticipated uses for the invariants: one, if you actually measure where the robot does travel versus where the simulator says it should travel, you can enter different values to experiment if the wheel base or wheel diameters can explain the discrepancy. Two, the error model potentially allows for future local localization to be simulated; in this case, the error is simply assumed to exist, and the result is a simulated position of the robot that differs from the actual position. For more information on correcting odometry errors refer to Measurement and Correction of Systematic Odometry Errors in Mobile Robots by Johann Borenstein and Liqiang Feng (IEEE Transactions and Robotics and Automation, Vol 12, No 6, December 1996, pg. 869-880).

  Note that all sensor simulation is based upon the invariant robot (the black one) because this is actually what the robot's sensors are measuing independent of where the robot may think it is. Thus, more importantly the behavior of the robot in the simulator will be based upon the invariants also.

  Model Invariants and Error Terms

  Internally, the invariant class is instantiated (and thus defaults set within constructor) within the simulator's main routine. Also, The error model can be toggled on or off by using the invariant::error_model(bool); method. The following error terms are present:

  Governing Slippage of Wheel

  • invariant::systematic_error_X();
  • invariant::systematic_error_Y();

  These terms represent how much per interrupt the speed of each wheel may vary (in mm/sec) from the actual linear speed along the X and Y axis. Currently, the must be assigned before using as the default is 0.

  Governing Range Sensor Distances

  • invariant::systematic_error_IR(CENTIMETER);

  Currently, this is for both IR and sonars. These may be split off later. This represents the greatest amount (in map units) that can be deviated from correct value. The CENTIMETER parameter allows the error associated with the distance to be dependent upon the actual distance. Most IRs have more error (absolute not necessarily percentage-wise) at greater distances. The current value is internally set dependent upon measured distance and is not user configurable.

  Simulator Features/Limitations/Bugs

  1. There is a class of bugs that the simulator will not catch; particularly, problems with initialization. For instance, a particular problem was with not resyncronizing the Primitive_Driver after changing the system clock. Internally, there is a "temp" variable for optimizations, which is under the Simulator is initialized to a sane value, but under the 68332 is it not. The probably is related to the oSchedule also being used within the Simulator itself.
  2. When compiling for DOS only, no FLTK defined, be sure to undefined FLTK from the makefile [not fully modified].
  3. Currently, the simulator screen is completely redrawn on every refresh rather than only drawing what has changed. Although this was simpler to implement, it is not as efficient; thus, the less that is redrawn (grid lines, invariant robot, etc.) the faster the simulation executes.

  Restrictions

  Currently, the scene file is usable only to the current dimensions of the A* map (GRIDX, GRIDY) dimensions. If the dimensions are changed, this will require a different map. Later, will provide ability to specify the dimensions in the program and convert between different maps. The dimensions are currently defined in oomrm/include/types.h.