DROS State of the Nation

Maintained by: David Austin

1.0 Introduction
This document describes the status of various parts of DROS and my plans for the future.

2.0 Comparison with Other Systems
There are a number of other software systems available for robotics. Here I compare them against DROS:

  1. Player/stage: Player/stage has recently become popular. It has good support for a number of robot platforms (this is an area that needs work in DROS). However, a number of limiting assumptions in the communications will cause scalability problems. In particular, the framework is very specific to robotics and to a particular structure of the robot system. Player/stage appears to be popular for getting started quickly, but I believe that the design is fundamentally flawed and will need an extensive re-write at some point.
  2. Carmen: Based on the very old IPC communications package by Reid Simmons. IPC is not sufficiently flexible for general robotics applications. Appears to be dead.
  3. Saphira (from ActivMedia and SRI International): The Saphira architecture is very specialised to robotics and very centralised/monolithic. Saphira is behaviour-based (which is complete crap in my view). Note: I haven't used or seen Saphira since it was sold to ActivMedia.

3.0 GeneralComms
The GeneralComms system needs quite a bit of refactoring in my view. One reason that I haven't rushed into it is because it is currently working fairly well. I'd like to see more hardware supported and more robotics programs before spending more time on the framework.

4.0 MSDE - Modular Software Development Environment
5.0 MobileRobotServer
The MobileRobotServer is currently called XR4000Server (because it only supports the XR4000). I'd like to have support for differentially steered mobile bases soon. E.g. the Pioneer.

6.0 LaserServer
The LaserServer is currently called SICKLaserServer. I'm pretty happy with it. It does optimisation of the information transmitted. The only change that I'd consider in the future is using a more compact scan transmission (i.e. shorts for each range). This is particularly for the SICK where we can do it without data loss.

7.0 SuperLocaliser
The SuperLocaliser is in charge of collecting logs of robot position (from odometry) and world position estimates (from localisers). It is in pretty good shape. I'd like to split it up a bit. Split off the logging functions from the pose fusion functions and the determining pose certainty functions.

8.0 LaserPoseTrackerPoly
LaserPoseTrackerPoly is the first localiser. It tracks the pose of the robot using a single Gaussian hypothesis. I need to back port some code from the research version of this. I'm not sure why I'm getting fairly poor performance from this on the XR4000. Works fine in simulation though.

9.0 TopologicalPathPlanner
TopologicalPathPlanner (currently called PathPlanner) is in good shape. I'd like to add stuff to choose an alternate path if the robot is blocked. Also, it'd be nice to have a more detailed representation of which path is best (e.g. measure times taken and completion rates).

10.0 DWAPlanner
DWAPlanner is based on the published Dynamic Window Approach. As with many approaches to obstacle avoidance, it is a fusion of three factors. This tends to lead to local minmima and the robot getting stuck. For now, the DWAPlanner is acceptable, but I think that this is an area for future improvement.

11.0 Monolith
The first version of Monolith has recently been completed. More command-line arguments and configuration options will need to be added as we continue to use it.

12.0 DROSInterface
This is currently being worked on to improve the scalability, particularly of the menus. We have run out of space on the menu bar. Otherwise, DROSInterface seems ok.

Copyright 2004 David Austin