---

I was programming lead on the University of Bristol team for the UKSEDS Satellite Design Competition 2022-23. This involved writing design documentation for the software subsystem, and leading the implementation of this subsystem when we were selected as one of the five teams who would actually build their design.

Context

The satellite’s mission was to identify space debris using two cameras and some simple stereo vision. The software subsystem was responsible for:

• Capturing video from the cameras
• Processing the video to identify debris
• Responding to commands from the ground station
• Sending telemetry data to the ground station
• Controlling the proof-of-concept reaction wheel

Tech

We had two Raspberry Pi Zero clones responsible for the cameras - one of them also ran the software subsystem. We also had a Pico controlling the reaction wheel. In order for the stereo vision to work - both cameras had to be synchronised. I achieved this by running a wire between the two control boards, with the primary computer emitting a signal to the secondary computer to start recording.

The software subsystem was connected via UART to the Pico which controlled the reaction wheel and read telemetry from various sensors. The subsystem was a Rust websocket server which the ground station connected to in order to send commands and receive telemetry. The ground station just used a standard websocket client to connect to the satellite, and had a Python script which would download footage from the satellite and process it to identify the size, location, and speed of debris.

Challenges

Our work depended on the electronics team deciding on a design, and then building it. They were heavily delayed in this process which meant we were also delayed and had a massive time crunch to get the work done. This was made even worse by the fact the electronics team was only one person - who went on holiday for multiple weeks right near the end. This meant that as well as doing the software work I had to build most of the electronics system as well.

Competition Day

On competition day we arrived and immediately realised how out of our depth we were. The other teams consisted largely of postgrads, were larger, and had way more support from their university and previous teams (we had none). When it came to our time in the challenge room we were very nervous. We had to operate fully from another room - with no access to the satellite. There were strict time limits too. I started the satellite recording and the test started. Once we were told the test had finished, I downloaded the recorded footage and disaster struck - the cameras weren’t setup to automatically set their exposure. During our rushed testing I’d only worked in one room, and so had never realised. The footage was completely dark and we couldn’t do the test again. Despite this, I still had a lot of fun on the day, and it was great to see some of the amazing work done by the other teams.

What I learned

• Test in multiple environments!
• If a pre-requisite is delayed - do as much as you can without them.
• It doesn’t matter if everything fails catastrophically - at least you learned.