Notice: The information and software provided on this site is no longer maintained or developed by Omron, or Omron Adept MobileRobots. It is provided as an archive only. This site may be discontinued at any time and without warning.

Variants or forks of some Open Source projects might now be maintained by individual developers and customers for their own use; they may have published them in popular online source code repositories or other web sites. These versions are not endorsed or supported by Omron, but by their individual users and developers. Contact the maintainers or developers of those forks only for support and questions. All copyrights and other license terms continue to apply.

Getting Started with MOGS

From MobileRobots Research and Academic Customer Support

Jump to: navigation, search



To navigate an outdoor space with MOGS, a map is required. This is the same kind of map as used by the other localization methods (ARNL and SONARNL), with the addition of registration to the GPS coordinate system (WGS84 datum) by including the latitude and longitude coordinates of the map's origin (0,0 point). While the other localization methods use the map data and sensor data to localize, MOGS only uses the map to navigate: to plan paths between goals, avoiding any mapped obstacle data, logical forbidden areas, etc. In MOGS, positioning is calculated from the GPS and robot gyro/IMU and odometry sensors, without any reference to the map. Therefore, the map origin latitude-longitude relationship is essential, as is correct orientation of the map with respect to the geocoordinates.

To make a map, you can convert data obtained from some other map, GIS or your own survey. Or, you can operate the robot in the environment to capture positions of obstacles with the laser. The first method can be more accurate if you have accurate existing data. The second method is available for use in a flat terrain if you have no other data source, though the results are less predictable and may contain error in detected obstacles.

After generating the map, open the generated map with Mapper3, add goals, and additional forbidden areas and lines to the map to help it avoid any pitfalls or other unsensable obstacles or problem areas. Also mark out a maximum boundary for the map. (Even so, don't forget to monitor the robot during operation.) Also available is a "BadGPSSector" object to manually delineate areas where GPS reception is poor. (In this area MOGS will favor the robot odometry over GPS position.)

Once you have created a map and loaded it into a MOGS, you must then initialize MOGS by determining the robot's global heading, and optionally setting any offset error in the map georeference. See "Initial Robot Positioning" below.

Creating a map from external data

The ArMap robot map format uses a local, flat coordinate system, defined using millimeter distances from an arbitrary origin point. You can write your own script or plugin to a GIS tool to generate an ArMap-format map (see the ARIA API reference documentation for ArMap for a description of the file format), or you can simply export or generate a file containing WGS84 latitude and longitude points in a simple text format and use the simple convertCoordsToArMap program provided with MOGS to convert to ArMap robot map, or as XML and use convertLatLonXMLToArMap, perhaps with some modifications. (The resulting ArMap will include a registration point to georeference the map to the original global coordinates.)

convertCoordsToArMap and convertLatLonXMLToArMap can be found in the examples/ directory of Arnl. Source code is provided and the program may be modified as needed or used as a reference to develop your own scripts or plugins. These programs simply read the input file and store object coordinates expressed in latitude, longitude points, then convert these from the WGS84 geographic datum to millimeter positions relative to the map origin.

The positions of sensable obstacles (as line segments), logical forbidden areas, and goal points are read from a simple text format. You can obtain these positions from some other map source or by your own survey.

The syntax of the convertCoordsToArMap input file is as follows:

Each line of the input specifies an object to put in the ArMap. Tokens on the line are separated by any number of whitespace (space or tabs) or comma or semicolon characters. The first token on each line specifies the ArMap object type: Line for an obstacle line, ForbiddenLine for a forbidden line, Goal for a goal. The object type is then followed by latitude, longitude, altitude coordinates in the WGS84 datum. If the type is a Line or ForbiddenLine, then it must have two sets of latitude, longitude, altitude coordinates specifying the end points of the line. If the type is Goal, a name for the goal ends the line. Any line that begins with # is ignored.


# Example input GPS coords.
Line 42.807471 -71.578535 60 42.807543 -71.577974 61.5
Line 42.807543 -71.577974 61.5 42.807079 -71.578157 61.89
Line 42.807079 -71.578157 61.89 42.807327 -71.579307 61
Line 42.807327 -71.579307 61 42.807471 -71.578535 60
Goal 42.807096,-71.579066 60 Start
Goal 42.807157,-71.579579 60 Gate2
Goal 42.807838,-71.578881 62 Hilltop
ForbiddenLine 42.808066,-71.579162,60 42.807777,-71.57773,60
ForbiddenLine 42.807777,-71.57773,60 42.806311,-71.578301,60
ForbiddenLine 42.806311,-71.578301,60 42.807002,-71.579594,60
ForbiddenLine 42.807002,-71.579594,60 42.808066,-71.579162,60

Run this program on the command line like this:

convertCoordsToArMap -input <inputfile> -output <outputfile> -latOffset <latOffset> -lonOffset <lonOffset> 

The -latOffset and -lonOffset parameters are optional and default to 0. If -input is not given, input is read from standard input. If -output is not given, then is used, or if -input was not given.

For example:

convertCoordsToMap -input mycoords.txt -output

Creating a map using the laser to scan obstacles

Alternatively, you can use the robot to automatically capture range data from the laser and associate them with GPS coordinates simultaneously acquired by the GPS receiver, which can be processed to produce a map showing approximate locations of fixed landmarks, to which you can add goal points and other logical features using Mapper3.

This method is only useful when in flat environments with fixed landmarks easily seen by the laser rangefinder, where you have accurate and uniform GPS coverage (using OmniStar or other real time correction is recommended). See below for tips that may improve obstacle accuracy a bit.

If you can obtain more accurate geographic data from a map, GIS, survey or satellite image, it is recommended that you use that data as input to convertCoordsToArMap instead (see above).

In this method, you manually drive the robot around an environment using the joystick, while MOGS captures and records laser scan data (obstacles) as well as GPS positions. Once captured, you use a program called convertOutdoorMapServer to convert the laser scan (.2d) file into an ARIA .map file and adjust filtering and other settings. (This procedure is similar to creating a map for ARNL using Mapper3.)

You will need:

  • An area to map
  • The robot
  • A laptop or other computer in the area
  • A wireless network that covers as much of the area as possible, but
  • primarily your starting or "home base" area
  • A magnetic compass, or knowlege about the exact compass directions from your starting location (to determine the proper orientation for the map)

Set up a "home base" area where you can see most of your working area. If you can get electrical power from a building or vehicle, do so, just in case your laptop's battery starts dying right in the middle of your work! If you're using a Pioneer AT, you may also need to recharge or swap batteries. If you're using a Seekur, it's batteries will probably last all day, but it never hurts to be prepared.

1. Start robot facing East. In the map, a "0" orientation will correspond with east. Mark this position on the ground with a line for East if you can.

2. Start mogsServer

3. Wait a few minutes for the IMU or gyro to initialize and stabalize, and for the GPS to get a good fix. If you have OmniStar enabled, wait for a converged OmniStar fix (indicated on a Trimble AgGPS by a steady green LED)-- this may take up to 10 minutes or more. Also, note that the Seekur's IMU takes about 5 minutes to "warm up" from a "cold" start -- don't move the robot at all during this time. If you do, you must restart the robot.

4. Connect to mogsServer with MobileEyes. Enable the data values display by enabling both View->Details and View->Custom Details. Check Num. Satelites, DOP and GPS Fix Type in the MobileEyes data table. For best performance, you should have more than 5 or 6 satelites, have a DGPS or Omnistar (if you have subscribed to Omnistar) fix, and a DOP of less than about 1.5. You may want to teleoperate the robot around your work area to make sure that GPS data is consistent throughout; buildings may block or reflect the signal and result in offset or highly variable positions. Leaving the robot stationary in a location with clear view of the sky for several minutes will allow it to acquire more satellites, and converge its position estimate more accurately, and possibly switch from GPS to DGPS or to achieve a converged Omnistar fix (if you are using Omnistar).

5. Start mapping with Tools->Mapping->Start Scan in MobileEyes.

6. Drive robot with joystick around your work area. Use the 'goal' button (or secondary button if using a generic USB joystick) to mark a goal. On Seekur, you can engage the joystick's disable button after driving for safety.

7. Stop Scan in MobileEyes, save scan file.

8. Run convertOutdoorScanStatic or convertOutdoorScanServerStatic to convert the .2d laser scan into a .map file. Run it from the example directory if on Linux or bin directory if on Windows, and supply your .2d scan file (it must be in the same directory) as an argument, e.g.: convertOutdoorScanStatic test.2d. convertOutdoorScanServerStatic is a server that you can connect to with MobileEyes to view the output map, and modify parameters and recreate the map. To modify parameters, choose Tools->Robot Configuration in MobileEyes while connected to convertOutdoorScanServer. To run convertOutdoorScanServer while mogsServer is still running, run it on a different port, e.g.: convertOutdoorScanServerStatic -sp 7273 test.2d Then connect to it with MobileEyes by appending :7273 to the robot host name entered in its startup dialog (e.g. localhost:7273 or or myrobot:7273). You can also connect one MobileEyes to both servers by listing them seperated by commas as the server name: myrobot, myrobot:7273. The parameters will be saved in convertOutdoorScan.p in the params directory.

9. When satisfied with the map, change mogsServer's map to the new map by connecting with MobileEyes and changing the file name for Map in the Files section of Tools->Robot Configuration. Or, modify arnl.p before starting mogsServer.

10. You can copy the resulting map to your laptop and use Mapper3 to erase noise, add forbidden lines and areas, and place goals.

Tips for getting a good map

  • Since the laser is a planar 2D sensor, the angle at which the laser plane intersects an obstacle such as a wall affects the distance recorded. Similarly, a change in robot tilt may cause the laser sensor to miss a smaller obstacle sometimes such as a rock or low wall. This may cause multiple "ghost" obstacles to show up in the final map, or for an obstacle to be placed at the wrong position. To mitigate this problem, when scanning, drive the robot along a wall at a constant distance, and a constant pitch or tilt to the wall if possible. You can also make several passes along this same line to "reinforce" this line. convertOutdoorScan uses the number of times some scan points are collocated as a theshold to determine whether to place an obstacle point at that location, and filters out obstacle points that aren't seen by other scans. You can adjust this filtering behavior using MinCount and Ratio in its settings. By driving along a wall carefully, even though incorrect obstacle points from scans taken elsewhere in the work area at different pitches and tilts may result "behind" a wall, the outward surface should be approximately correct. However, note that GPS reception can be severely affected by buildings, so don't drive too close to the wall that GPS reception is impacted.
  • Inspect the map carefully when done to make sure there are no stray obstacle points that you do not wish to leave in the map. These could prevent the robot from travelling through a narrow area or doorway, or cause it to always plan around them unnecessarily. If you enable the Obstacle Points diagnostic drawings in MobileEyes when connected to mogsServer you will see active obstacle points highlighted in green as ARNL attempts to plan and navigate the robot.
  • If you find any other good tips or techniques for outdoor mapping, please share them on the aria-users mailing list.

Add Map Boundary, Goals, Forbidden Areas, and other Objects

You can use Mapper3 or Mapper3Basic to add objects to the map such as goal points, forbidden areas and lines (the robot will not cross or enter these), or lines which represent buildings, walls, and other fixed objects that the robot should plan around.

In addition, it is important to also add a continuous boundary around the outside of your map. This can be done with forbidden lines. This boundary determines the total region in which MOGS can plan robot paths. If an outside boundary is missing, then it will assume that the only valid operating area is inside the existing objects and features of the map and will not be able to plan paths to all goal points, or it will plan a path outside your desired operating area. See images below for example.

Map with NO boundary line - robot will not be able to plan appropriate paths to some goals

Map WITH boundary line (orange forbidden line) - robot WILL be able to plan to all goals, and will stay within the boundary line.

Initial Robot Positioning and MOGS Initialization

Initial Heading Determination, MOGS Initialization

The GPS provides a position for the robot, but we also need to determine the heading (orientation) of the robot. This is done by driving the robot in a straight line for a short distance while MOGS uses the changing GPS positions to map the robot's heading to the GPS coordinate system.

Note: This must be done every time MOGS is started. Performing this procedure will initialize the MOGS positioning algorithm. MOGS will not be working yet to position the robot until you perform this procedure.

1. Position the robot outdoors where it can get a good GPS fix, on a flat, hard surface (such as asphalt), and is safe to drive at least 5 meters/yards. For best results, leave the robot stationary at this point for several minutes to increase GPS accuracy.

2. Run mogsServer on the robot.

3. Run MobileEyes (on a laptop, for example) and connect to the robot. When using a Seekur or Seekur Jr., make sure the laptop has joined the "Seekur" or "Seekur Jr" wireless network. On this wireless network, the first onboard computer will be

4. After connecting, make sure the map is loaded. You can set it in the Files section of the robot configuration, accessed via the Tools->Robot Configuration menu item.

5. Open Tools->Custom Commands in MobileEyes.

6. Select the "DriveForHeadingBegin" command. Click "Send" to send the command.

7. Use the forward drive button in MobileEyes to drive the robot for approximately 3-4 meters or yards. Stop the robot.

5. In the Custom Commands pulldown menu, select "DriveForHeadingEnd", and click the "Send" button to send the command.

This will set off the heading computation and the change will be reflected in the robot pose immediately. MOGS positioning will now be initialized. You can verify this in MobileEyes by observing the colored dots placed for GPS and robot odometry positions, and the lines showing estimated variance of the position, and by reading the log message output of mogsServer, and in recent versions of MOGS, by the MOGS status shown in MobileEyes's details table.

Setting an offset (Optional)

There may be some systematic or consistent difference between the GPS coordinates of a position saved in the map and the real position of that place. To account for this, you can place the robot at a known position and select the map position to set the offset in MOGS.

This can correct for this one aspect of error, but should only be used if you feel that this error in the GPS system is impacting your application. Otherwise, it is unneccesary and adds some complication and is not needed to use MOGS.

  1. Place the robot at a marked position where it has a good GPS fix, for which you previously added a reference goal to the map when creating it. (If using OmniStar, wait for convergence)
  2. Run mogsServer or other MOGS server software.
  3. Run MobileEyes and connect to mogsServer. Load the map in Robot Configuration if neccesary.
  4. Use the Localize To Point command to set the position of the robot in the map:
    1. If the Localize To Point button is not present in the MobileEyes toolbar, right-click on the toolbar and enable it.
    2. Click Localize To Point
    3. Click the desired reference position in the map corresponding to the current position of the robot, and holding the mouse button down, drag in the direction the robot is facing. MOGS will record this position, but if there is a difference between the map coordinates and the GPS coordinates, it will place the robot icon at the "wrong" position in the map.
  5. Use the ApplyOriginOffset command to correct for the difference:
    1. If the menu of Custom Commands is not yet preent in the MobileEyes toolbar, right click on the toolbar and enable it.
    2. Select "ApplyOriginOffset" in the Custom Commands menu
    3. Click "Send" to send the command.

MOGS will save the map file with the offset applied in the map. This procedure must be done for each map.

Personal tools