Modular Software Development Environment (MSDE)

Maintained by: David Austin

1.0 Introduction to Modular Software Development Environment (MSDE)
The Modular Software Development Environment (MSDE) aims to provide a robust framework for development of modular software. The requirements for robotics are a little different to many other computer science applications:

  1. Robustness to computers going up and down (as robots are power cycled) and communications failures (as robots go out of range).
  2. Long term operation: the robot may (one day) be doing experiments that last days or weeks. I'm not sure how well other environments support this.
  3. Real-time performance: the communications overhead should be minimised to help the performance of the robot when attempting real-time control tasks.
  4. The system should be easy to learn. Many robotics researchers have a strong background in computer science but some don't and any environment should be easy to learn.

2.0 Overview
MSDE provides processes to support the development of modular software systems. The components are show in blue and green in the figure below:

Parts below the dashed line should always be running (the user should not have to worry about them) and the user should start all the processes above the line by setting an appropriate configuration and running StateManager. StateManager should then run everything else.

3.0 MSDE Components
The MSDE consists of five major parts:

  1. NameServer

    The NameServer maintains the global name space and allows processes to find other processes by name. This means that there is only one fixed port in the system - the NameServer port (12345). The NameServer should always be running on each of the robots and a stationary, reliable machine (cass).

  2. Executer

    The Executer provides a service whereby users can execute programs on remote hosts (which are running the Executer). The Executer should always be running on each of the computers on the robots.

  3. StateManager

    The StateManager is the part of the system that the user starts. The idea is that the user runs the StateManager with an argument specifying the configuration to use. The StateManager then starts all of the system, as specified in that configuration (using the Executers).

  4. Programmer's Interface

  5. DBManager

    The DBManager provides a distributed database system which is accessible on all robots. The database should be used for all configuration information.

Copyright 2001 David Austin