DROS State of the Nation Maintained by: David Austin

• 1.0 Introduction
• 2.0 Comparison with Other Systems
• 3.0 GeneralComms
• 4.0 MSDE - Modular Software Development Environment
• 5.0 MobileRobotServer
• 6.0 LaserServer
• 7.0 SuperLocaliser
• 8.0 LaserPoseTrackerPoly
• 9.0 TopologicalPathPlanner
• 10.0 DWAPlanner
• 11.0 Monolith
• 12.0 DROSInterface

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.
   • There does not appear to be any good method for dealing with multiple robots.
   • The use of C structures for message passing is not portable. Entries within the structure are converted to network byte order, but no provision is made for the fact that compilers pad structures differently (there is no C/C++ standard requirement for structure layout in memory).
   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.

• I'm not happy with the many different types of events and event handlers. This has led to a lot of copy-and-paste code in the implementation. I think that defining an event class which contains the event-related data would be a significant improvement. Then GeneralComms could take over more of the overhead of dealing with messages in my defined format.

• The Packer is not very pretty. I wanted to avoid an extra compilation step (when someone defines a language which does message packing/unpacking in an integrated way, we'll be getting somewhere!). At the moment, I tend to think "if it's not broke, don't fix it". Perhaps an improvement would be to define more rigorous structure for the format strings.

• One thing that I want is for the message format strings to be independent of the classes that are sending and receiving the messages. It is common to define (in some way) a class that is transmitted and received (i.e. used at both ends). Then someone in the project decides to change that class and breaks lots of things. I think that it is better to explicitly define message formats as strings of bytes and define packing and unpacking methods at both ends.

• The NameServer needs quite a bit of work. Particularly, the peer-to-peer, decentralised stuff has not been used in a while. This is probably the most important thing to fix in the GeneralComms system.

• The NameServer needs quite a bit of work. Particularly, the peer-to-peer, decentralised stuff has not been used in a while. This is probably the most important thing to fix in the GeneralComms system.

• The Executer is probably in good shape, but I haven't tested it in a while. The configuration/database issues need to be worked out.

• The StateManager needs quite a bit of work.

• The DBManager needs to be re-worked. Tests with MySQL and PostgresSQL showed pathetic write speeds for maintaining sorted tables (e.g. logs). Therefore, I've gone away from using a "real" database and want to use files. A simple XML format seems a possibility. DBManager needs to be re-written with this in mind.

• ProgInterface is working well. For the future, I'd like to see command line editing and add listing of which component sent which response.

• CommScope has barely been started.

• TimerServer is the version from RSS and needs to be ported.

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