Lego Mars Rover
The Challenge
For years people are wondering if there is water on Mars. Following
NASA (see the Mars
Exploration Rover Mission), we have built a Lego Mars Rover to
explore Mars, to find water, and to measure its temperature. The
challenge is to develop software for the Mars Rover to accomplish this
mission.
The Lab
To test the mission of the Lego Mars Rover, we have prepared an
environment in the ITT/SOS lab which contains :
- A table with three small lakes containing water.
- A Lego Mars Rover with
- 2 RCX computers
- 3 motors
- 3 lightsensors
- 1 touch sensor
- 1 rotation sensor: measures the rotation of one of the
driving engines
- 1 temperature sensor: the sensor can be moved vertically
using a motor to lower it into a lake
- 1 wireless RF camera
- Note: how sensors and
actuators are connnected to the 2 RCX computers is a choice of the
developer
- A PC which communicates with the wireless RF camera using an RF
transmitter/receiver connected to a USB port of the PC. The PC does the
image processing of the camera on the marsrover. The software on the PC
is already available.
- The PC communicates with the RCX bricks using the
Infrared communication tower connected to a USB port of the PC.
- The RCX bricks can communicate between each other using their own
infrared receiver/transmitter.
- The protocol used for communication over the infrared light is
already defined and implemented. It also discusses the information send
from the PC to the RCX computers, such as the position of a lake and
its color.
- The RCX bricks have an operating system called brickos on which
we can write C/C++ programs.
Approach
We use a model-based approached and iterative incremental
development. Models are expressed in the Unified Modeling Language
(UML) (e.g. using the tool StarUML). The approach is based on five
phases:
Phase 1
- Define requirements of Mars Rover:
- Listing of requirements, including non-functional ones, with
priorities (e.g. MoSCoW)
- Use Case Diagram, with short description of use cases (goal,
basic flow) and actors (interface, accuracy, ..)
- Concurrency matrix: which uses cases can be active in parallel
- Analyze requirements:
- High-level Activity Diagram
- Feasibility of requirements (are requirements realizable, do we
have right set of sensors/actuators, ..)
In parallel: experiment with sensors/actuators, infrared
communication, etc.
Phase 2
- Define a global high-level software architecture with modules,
data and global interfaces, use Component Diagram
- Distribution of sensors, actuators and software components over
RCX bricks, use Deployment Diagram
- Verify realization of use cases on proposed HW/SW combination;
use Sequence Diagrams to visualize typical scenarios
- Analyze risks: list risks, their probability and impact; how to
deal with risks
In parallel: continue experiments with building blocks, etc.
Phase 3
- Detailed architecture with precise interfaces, data structures,
tasks, ...
- Analyze task structure: concurrency/dependencies, deadlines,
periods, shared resources, priorities
- Verify with respect to uses cases, use detailed sequence diagrams
- Make development plan; which iterations, goal of each iteration,
evaluation test after iteration, final acceptance tests
Phase 4
- Perform iterations, implement functionality, test, revise
architecture, plan, etc., as far as needed
Phase 5
- Increase robustness & fault-tolerance, acceptance tests
