> SoftwareDevelopmentRoadmap

Home >> Roadmap

Software Development Roadmap (Dafydd Walters)

Although there are minor hardware issues outstanding, software is by far the area where the most work remains to be done in this project. If you exclude the microcontroller firmware in the custom hardware modules, the only host software that's been developed to completion so far, are command line utilities to test, configure and exercise the custom hardware modules. Although it's possible to write shell scripts to control the robot using these command line utilities (and indeed I did write Perl scripts to implement some behaviours to demonstrate the robot's capabilities in the Seattle Robotics Society 2003 Robothon - see Code), that was never meant to be the intended way to implement behaviours.

Below I have listed, roughly in the order in which they are to be tackled, the software development tasks that remain to be completed before the Open Automaton Project can be deemed worthy of a 1.0 version designation.

1. Driver layer

Work is already underway to develop a driver layer using the Player framework (see [WWW]http://playerstage.sourceforge.net). This is a hardware abstraction layer that allows client software modules to drive the hardware via a set of standard interfaces.

2. Integrate code for stereo vision

At the moment, I am leaning towards using Bob Mottram's GPL'd stereo vision code in the project.

There is currently no Player interface specifically for stereo vision, but for the initial implementation, at least, space occupancy data will be projected to a 2D grid and returned to clients using the laser rangefinder interface.

3. Pluggable middleware framework for behaviours and task programs

By leveraging the ROS project (see ros.sourceforge.net), a framework with well defined interfaces will be developed, to allow behaviours and task programs implemented in any language to be "plugged in" (e.g. bundled with OAP, downloaded from the internet). Task programs are essentially collections of behaviours that go together to perform some high-level task (e.g. patrol for intruders, map the environment, deliver a message).

4. Code for human interaction using LCD display, keypad and remote

This involves writing one or more lcdproc clients to provide a human robot interface using keyboard input (from the on-board keypad and RF or IR remotes) and text output on the LCD display.

5. Simulator environment

Putting together a simulator environment is potentially one of the most important software tasks, as it opens the project up to those who are currently not able to construct their own robot, or who don't have full-time access to a robot, but who would still like to contribute to the project. The simulator environment will leverage the Stage simulator (part of the Player/Stage project) and the curses lcdproc driver, so that the user will be able to operate the simulated robot via a console, and view the robot's motion in a Stage window.

6. On-board web application

An application hosted by the on-board web server will provide a user interface that allows the operator to:

7. Behaviours and task programs

Last, but not least, the behaviours and task programs themselves need to be developed. Some core behaviours will need to be developed within the scope of the project to be bundled with the OAP software release.

CategorySoftware