rtss logoRTSS 2005

The 26th IEEE Real-Time Systems Symposium
December 5-8, 2005
Miami, Florida,  USA
Sponsored by the IEEE Computer Society Technical Committee on Real-Time Systems


The maRTian Task


The competition was be part of the ERTSI workshop

There will be a cash price for the winner!

Deadline for submission has been extended another week to 17th of October. As a result, notification of acceptance is delayed to 24th of October.

There is a date mismatch between the main RTSS website and this. To fix this, we push the official deadline for submission back to the 10th of October (no longer valid). However, a short note (email) indicating your participation would be appreciated on 5th (no longer valid) of October.

Thanks to input from Julien (Lyon, France) I have fixed another bug in the simulator, which again caused the robot to appear crashed, when it was not. If you encounter bugs, please let me know!

If you want to stay abreast with any developments regarding the competition, drop me a line at smp[at]nicta.com.au and I will let you know.

I have fixed a bug in the simulator, which caused the robot to appear crashed, when it was not. Link disabled, as it is no longer the current version.

There is an FAQ section at the bottom of the page. Check this if you encounter any problems.

The code is ready for download. Unpack on a Linux box and read the README file contained in the martian subdirectory. If you need further assistance or want to report a bug, drop me a line at: smp [at] nicta.com.au.

Please note. This is a draft version of the simulator. The competition version will have besides other things enhanced graphics. However, the functionality should be the same.


  • What is needed to build the simulator software? The simulator needs the following to be available on the build box: flex, bison, gcc, gtk and libreadline.
  • I have trouble connecting to the simulator. Can you give a hint on how to solve this? If you have trouble connecting to the simulator try
    lsof | grep 22222
    This should show you which process owns port 2222, which is used by the simulator.
  • What are the time requirements of the system?The robot moves .2 meter per second and can sense holes in the ground 0.075 meters away. The communication round trip is 50 ms. Hence the worst case response time should not exceed 375 ms
  • The sonar sensors are unreliable as specified. What are the associated probabilities? False negative is 1 in 1000 (sensor suggests no hole, when there is one). False positive is 1 in 50 (sensor suggests hole, where there is none). These probabilities are per sensor.
  • How can I get the robot going again after it bumped into something?Read LpiGetBumper and the crash state should be resolved.


This special session at the RTSS 2005 conference revolves around a design and coding contest to control a robot on the martian surface in the search for water. The groups are asked to submit code and design for review and a number of groups will be invited to directly compete against each other during the conference. This can be used to showcase research or simply how able members of a research group are.

This session is particularly targeted to set real-time work of the community into an interdisciplinary context. In particular for PhD students we would like to enable faculties to make the work conducted within this session as part of the course work program of these students. In general it is suggested that this project is solved in a small group.


After recent new discoveries on Mars (see BBC Website) your country has launched a mission to Mars to confirm whether this is really water, which may be used to support a manned mission and whether there was or are live forms to be found on Mars. However, your country is not alone and several others have also launched a mission. An enormous solar flare has destroyed the main mission computer of the research vehicle to be landed on Mars. As a result the image processing to control the vehicle is not operational. Engineers were able to reuse the connections of a low level and simple processing unit to the RF unit, to provide a very limited interface to the actuators and sensors of the vehicle. All the processing to move the vehicle about has to be done on the orbiting carrier spacecraft. The orbiting spacecraft is able to identify the vehicle position and orientation and the target location. However, the vehicle itself is almost "blind". It is circular and equipped with 12 bumpers, which identify the relative location of obstacles the vehicle has bumped into.

Furthermore it has six ultrasonic sensors, which locate holes in the surface around the robot. The reach of the ultrasonic sensors is very limited and at full speed of the vehicle, there are only 375 ms available to react (including the communication delay), before risking to loose the vehicle. The vehicle is propelled by two wheels. It understands simple commands, forward, backward, turn, and querying its sensors. Additional the spacecraft provides the location module to feed the location of the robot back to the control computer. The other nations involved suffered a similar fate to yours and they are providing some cooperation. You can query their control computer regarding location and sensor values of their vehicles.

The image below indicates a sample of the simulator used.

Mars Scenario


Program the control computer in the spacecraft to steer the vehicle on the Martian surface and guide it safely to the target location to conduct its tests for water. You have a single connection to send your commands and queries to and this will forward the commands to the vehicle, read sensor data from the vehicle and query the other control computers.

This connection is TCP/IP based. It is important to be the first to confirm the water source and possibly life forms, hence efficient speed without loosing the robot is the key.

The competition will run on PC style hardware. Each team will have one separate PC available during one race (not for the whole competition, just for one race). The simulator will run on a separate PC on its own providing the interface for all participants via the network. We will provide a RT-Linux. However, if you want to run your own RTOS, please let us know and we will work to accommodate this.

A simulator version will be available at the end of August. It runs on Linux and provides the TCP/IP interface. Check this page to find more information regarding download and setup of the simulator.

Requirements and Dates

The groups need to provide their solution and a design and testing document of up to 10 pages to the committee for evaluation by 17th (was 5th) of October. Notification of acceptance is planned for 24th (was l5th) of October. Optimisations of the solution between notification and the conference is possible. However, the submitted solution has to be operational and will be held if the optimised version should fail. On the conference the winner will be determined in one or more rounds, in which the teams pitch their versions against each other in direct competition on the planet.

In case you have any questions, feel free to contact via email at smp {AT} nicta.com.au.

Course Support

At some Universities it might be able to get accreditation for this contest to be counted towards the course component of the degree. If you are interested in this, talk to your course coordinator and ask him to liaise with me at

National ICT Australia Ltd./
School of Computer Science and Engineering
University of New South Wales
Level 6, L5 Building
NSW 2052 Kensington
or via email at smp {AT} nicta.com.au or smp {AT} cse.unsw.edu.au
or via telephone: +61-2-8306-0560


Iain Bate, University of York, UK
John Rehger, University of Utah, USA
Stefan M. Petters, National ICT Australia Ltd, Australia
Thomas Nolte, Mälardalen University, Sweden


The software provided is based on code written by various people at the Institute of Real-Time Computer Systems, at the Technischen Universität München, Munich, Germany. Many thanks to Professor Georg Färber, for providing access to the code and Jan Leupold for his support. It contains:

  • A full functional simluator. The graphics used by this will be enhanced for the competition. The simulator is running on Linux and requires standard development tools and gtk installed.
  • A manual control unit, which allows to control a robot. This may be used to understand the requirements more clearly and simulate robots of other teams
  • A control library. This may be used to develop code running on standard linux and as example for the TCP-IP based communication to the simulator.