In this article our intern Nikola Ivanov writes about the software that turns a Raspberry Pi, a laser and a camera into an instrument an operator can run from the habitat, or, in the fiction of the mission, from another planet.

The hardware side of Caillou was settled fairly early: a Raspberry Pi 4, a camera module, a visible guide laser, three status LEDs and a fan, all inside a 3D-printed enclosure. The software side was much less clear to me. What should the instrument decide by itself, and what has to stay in human hands?

One command at a time

My first sketches described the mission as a script. Power up, wait until the rover arrives, aim the laser, take a picture, simulate the acquisition, transmit the results. Written down like that it looked like a tidy state machine, and on paper it worked fine.

In practice it would have been a trap. Field work is not linear. An operator repeats a measurement because the first one looked odd, aborts halfway through, takes a second image of the same rock, or moves on to a new sample while the previous data is still sitting on the device. Software that insists on one fixed order ends up fighting the people using it.

So I turned the design around. The instrument holds no mission sequence at all. It offers a handful of independent commands instead, each one handled by its own background worker, and each one valid at any moment:

• Take measurement: switches the guide laser on for a configured duration, switches it off again, and picks one spectrum from the library of reference files stored on the device.
• Toggle laser: manual control, for aiming at the target and for checking the optical path.
• Take picture: captures a context image of the sample through the camera module.
• New field run: opens a new run with its own storage, so that data from different sites never gets mixed together.
• Shutdown and status: powers the Raspberry Pi down cleanly, or reports what the instrument is currently doing.

The sequence has not disappeared. It just lives where it belongs, in the mission plan and in the head of a trained operator. The instrument stays a bit stupid on purpose, and that is exactly why it is so hard to get it stuck.

A web service on a rock

Commands reach the instrument over Wi Fi and end up in a small Python web service (Flask, served by Waitress) that runs as a systemd service and starts together with the Pi. From the moment the instrument is taken out of its support and gets power, the interface is simply there. Nobody has to launch anything by hand, which matters quite a lot if the person operating it is wearing gloves.

Everything the instrument knows about itself goes into a state file on disk instead of living in memory. If the Pi loses power in the middle of a run, which is not exactly unlikely out in the field, it wakes up still knowing which field run was open, how many measurements it has already produced, and which reference files it has already used. I did not get this right on the first attempt, and finding out the hard way was probably the most useful hour of the whole project.

Building in the distance to Mars

On a real Mars mission nobody gets an immediate answer. Signals travel for minutes, and the AMADEE missions exist so that teams can practise working under that constraint. So the software hesitates on purpose, in both directions. An incoming command waits before it is carried out, and results wait before they are made available. The length of the delay is one value in the configuration: a few seconds while I test in the lab, minutes when the mission is supposed to feel like Mars.

Results are not pushed anywhere either. The science team fetches them. The images and spectra of a run are packed into a downloadable archive together with a log of the whole field run, and every dataset carries a run identifier and a timestamp, so an image and a spectrum can always be matched back to the same target.

What this experience taught me

Most of my time on this project went into questions rather than into code. Which decisions were mine to make, which ones belonged to the people who designed the instrument, and which ones only become visible once somebody is standing in the field holding the thing. The architecture that survived was not the cleverest one I drew. It was the one that assumed the least about how humans would use it. Writing software for an analog mission taught me that the hard part of a system is rarely the code. It is agreeing on what the system is supposed to do in the first place.

Author: Nikola Ivanov