DROS Design

Maintained by: David Austin

1.0 Introduction
2.0 Architecture
3.0 Supporting Mechanisms
4.0 Some Design Decisions

1.0 Introduction

Robotics is crying out for a development similar to the operating system which made the PC a general, flexible tool for computation. I believe that this is the major limitation holding back robotics research today. We as a community do not build robotic systems - we instead "solve" problems that can be studied in isolation. I would argue that many of these problems are not relevant or are not crucial to the widespread deployment of robots.

The design of an operating system for robotics is particularly complex. In addition to having all of the software issues associated with large and complex systems, we have real time constraints and radically different hardware systems which are hard to abstract. Therefore, the design at this stage is not complete. I apologise for that but hope that people will understand that I do not wish to lock us into decisions which may prove incorrect.

2.0 Architecture

For DROS, I've decided not to specify the architecture at this stage. Maybe, if things go well and we have a considerable code base (in a few years time), we can start looking at architectural designs. However, at this stage, I contend that nobody knows what an appropriate architecture looks like. Very few people have built a large scale robot software system and, as far as I know, none have been happy with the end result. [This accounts for a lot of the pessimism around about robot software! However, I think that for the field in general, a robotic operating system is vital.]

So what is the architecture? For the moment, I define the architecture as a collection of software modules communicating with each other. I am confident that robotics systems need to be written in a modular fashion (even if just for the practical reason that most software is written by PhD students).

3.0 Supporting Mechanisms

The major features are as follows:

Promote re-use of components. The present system requires that everyone maintain their own compiled copy of the system. This is wasteful of disk space and time. DROS will allow a much simpler use of the system, possibly without even re-compiling, through the following:
1. Installed programs will be provided in some public directory so that few people have to compile the entire system. Note that this implies that the Executer can run any program.
2. Unique message IDs will be used within a pre-defined message header. Each message ID will have a defined (and documented) structure associated with it. Once any program that uses that message is "released" the message should be frozen and never changed. This is necessary so that the installed components will not crash because of changed message formats.
3. Run-time configuration will allow re-use of installed components without re-compilation.
Simplify configuration of the system. One of the biggest problems with the ISR system is that the configuration information is scattered in a lot of small files and is not easy to use. The new system must address this and also should provide a global configuration space so that people do not have multiple copies of a configuration file floating around. The DBManager will provide a global database in which the configuration (as well as other data) can be stored.
Global name space. The DROS system will use a global name space to facilitate multi-robot experiments and also to avoid the clashes that have been occurring when multiple people run the ISR system on the same CPU (e.g. for simulation). See also the NameServer.

4.0 Some Design Decisions

Software tools As a general policy, I have decided to avoid the use of software tools where I'm not totally convinced of their usefulness. I expect many people will disagree with this but I've thought carefully about it (because it does mean extra work). My decision is a result of the following four reasons:

Since I expect most of the code to be written by PhD students, I don't want to waste their (limited) time to learn new tools.
Software tools come and go faster than you can blink. Software fads are extremely fast with new tools growing in popularity very rapidly and decaying shortly after people start to relise the limitations. There is no man-made construct more prone to the problem of (non-obvious) limitations than software.
The use of software tools limits the platforms that DROS can be used on. For example, many real-time operating systems are significantly different and are much less likely to be supported by any given software tool. The use of software tools can also limit the choice of programming languages.
Once we commit to a software tool, we're bound to it. If the tool dies (or is no longer supported), then there is a big problem. For basic tools (make, gcc) we can be confident that this will not happen.

CORBA CORBA is a good example of a recent software fad. It is an extremely complex system for communications. Now the questions are: does it offer more than it costs? and will it deliver reasonable real-time performance? To my mind, the answer to both of those questions is no.

The cost of CORBA is the amount of time spent learning it (yes, one could wrap around it and hide the details but that requires effort too and why not wrap around something simpler?). The cost of learning CORBA, especially given the complexity and abstract nature of CORBA, is to my mind way too high. Bear in mind that many of the students that we get have not done any significant software engineering!
The issue of real-time performance comes up also. The real-time constraints on robotics are fairly unique. While a lot of effort has gone into ensuring that the performance of CORBA is reasonable, there will be events where the delay blows out. I feel that CORBA is just too big and complex to deliver the kind of performance that robotics demands. (It is possible to use a different mechanism for time-critical communications, but then we have even more learning required.)

ACE ACE (Adaptive Communications Environment) is an example of a communications package that provides most of the functionality that we require. However, ACE suffers from an over-use of C++ templates, rendering it big and not portable. However, we can learn from ACE and you may notice many similarities between ACE and GeneralComms.

Fixed Messages One of the decisions that I've made is that once released to a wider audience, the format of messages must be fixed. This is crucial because, when a number of people are using DROS, we can't expect them all to re-compile everything whenever they update their software. For more information, see the messages page.

Software tools	As a general policy, I have decided to avoid the use of software tools where I'm not totally convinced of their usefulness. I expect many people will disagree with this but I've thought carefully about it (because it does mean extra work). My decision is a result of the following four reasons: Since I expect most of the code to be written by PhD students, I don't want to waste their (limited) time to learn new tools. Software tools come and go faster than you can blink. Software fads are extremely fast with new tools growing in popularity very rapidly and decaying shortly after people start to relise the limitations. There is no man-made construct more prone to the problem of (non-obvious) limitations than software. The use of software tools limits the platforms that DROS can be used on. For example, many real-time operating systems are significantly different and are much less likely to be supported by any given software tool. The use of software tools can also limit the choice of programming languages. Once we commit to a software tool, we're bound to it. If the tool dies (or is no longer supported), then there is a big problem. For basic tools (make, gcc) we can be confident that this will not happen.
CORBA	CORBA is a good example of a recent software fad. It is an extremely complex system for communications. Now the questions are: does it offer more than it costs? and will it deliver reasonable real-time performance? To my mind, the answer to both of those questions is no. The cost of CORBA is the amount of time spent learning it (yes, one could wrap around it and hide the details but that requires effort too and why not wrap around something simpler?). The cost of learning CORBA, especially given the complexity and abstract nature of CORBA, is to my mind way too high. Bear in mind that many of the students that we get have not done any significant software engineering! The issue of real-time performance comes up also. The real-time constraints on robotics are fairly unique. While a lot of effort has gone into ensuring that the performance of CORBA is reasonable, there will be events where the delay blows out. I feel that CORBA is just too big and complex to deliver the kind of performance that robotics demands. (It is possible to use a different mechanism for time-critical communications, but then we have even more learning required.)
ACE	ACE (Adaptive Communications Environment) is an example of a communications package that provides most of the functionality that we require. However, ACE suffers from an over-use of C++ templates, rendering it big and not portable. However, we can learn from ACE and you may notice many similarities between ACE and GeneralComms.
Fixed Messages	One of the decisions that I've made is that once released to a wider audience, the format of messages must be fixed. This is crucial because, when a number of people are using DROS, we can't expect them all to re-compile everything whenever they update their software. For more information, see the messages page.