I no longer contribute to Porto Space Team. Looking back at our work on INVICTUS, I want to document what the Software and Computer Engineering department contributed, how we approached the engineering, and what I would carry into another student team.
This account covers our 2022–2023 development work: requirements, trade-off studies, telemetry prototypes, simulation and technical teaching. Much of its value lies in the decisions and questions we made explicit, alongside the code and reports we produced.
My role, and the team's work
Within E-42, I was the project manager: I coordinated the department, mentored members, reviewed progress and brought the individual situation reports together into the INVICTUS Computing SitRep. Our onboarding guide separated that role from Pedro Afonso's responsibility for mission goals as product owner, and João Gil's responsibility for leading implementation as project master.
The department's remit was the data-handling subsystem. That included collecting readings, processing and storing telemetry, communicating with the ground, and reasoning about timing and failures across hardware and software. It also meant working with other departments whose hardware choices determined what our software could reasonably promise.
My direct contributions included establishing the department website and reporting structure, preparing orientation material, maintaining the team's organisation and responsibilities, and assembling the technical report. I also prepared and delivered the Dependability in Critical Real-Time Systems session on 4 May 2023. The engineering studies and prototype code below were team contributions, with their authors credited throughout.
Turn a mission goal into questions we can answer
“Build the rocket's software” leaves too much unspecified. Our report broke the problem down into concrete responsibilities: record the apogee, preserve attitude and altitude data, log system events, transmit useful information during operation, and support finding the vehicle after landing.
Luís Jesus's first report examined the 2022 competition's Eggtimer requirements. His subsequent logging study explored an ESP32-based arrangement, persistent storage and a parallel radio link. It recorded dependencies that were still unresolved: sensor interfaces, antenna selection, the choice between LoRa and XBee, and whether a cellular link belonged in the design at all.
That is a useful form of progress. A dependency written down has an owner and can become a decision. An assumption hidden in an implementation tends to surface later as an integration problem.
For a future team, I would keep a small decision record next to each interface: what is known, what is assumed, who can resolve the uncertainty, and which test would close it. Our reports already contained the beginnings of that discipline. Making it consistent would make coordination easier.
Logging and live telemetry have different jobs
The August logging study asked a practical question: how should we balance frequent sensor readings against the cost and timing of writing to storage? It considered buffered microSD writes, explicit flushing and a tentative acquisition rate that still needed benchmarking.
The distinction between a reading in memory and a reading safely stored matters. So does the distinction between a local log and a live display. A radio link can give the ground team timely information, while persistent onboard data can preserve a fuller record for later analysis. Each path needs its own assumptions about loss, timing and recovery.
The study did not present a measured logging benchmark. It proposed the experiments needed to choose one. I would preserve that distinction in any engineering report: a target rate is a requirement to investigate; a measured result belongs beside the conditions under which it was obtained.
Read Luís Jesus's logging study.
Reuse a ground station, then examine every interface
João Gil compared existing tracking systems, including Rocket Tracker, White Vest and an XBee-based vehicle tracker. The comparison considered how they received, stored and displayed data, and how their concurrency and communication choices differed.
Afonso Baldo then studied John Jones's White Vest telemetry project and worked on adapting its ground software to Eggtimer data. The preserved repository contains an Arduino-side parser, packet assembly and serial output, together with changes to the Go dashboard's telemetry decoding and data structures. It also contains the inherited web interface and post-processing tools.
This was adaptation of an existing project. White Vest supplied substantial infrastructure; Afonso's work addressed the different telemetry source and the path into the dashboard. Keeping that distinction visible explains both the team's contribution and the benefit of building on free software.
Looking back at the prototype, the most useful next step would be a set of recorded input/output examples across that boundary: incoming fields, assembled packets, decoded values and expected display behaviour. Those examples should include incomplete messages, invalid values and restarts, as well as a clean stream. They would make changes to either side easier to assess.
Several derived metrics in the source were still placeholders. The code snapshot documents implementation work; it does not establish a completed flight test. Its value for another team is as an integration study with visible assumptions and remaining work.
Read the ground-station study and browse the accompanying materials.
Simulation is a milestone with a defined scope
The Pixhawk/PX4 work explored whether an existing flight stack could support our needs. João Gil documented the stack, the relationship between flight software and a ground-control application, and the setup of a software-in-the-loop environment using PX4, jMAVSim and QGroundControl.
The December report is particularly useful because it records the actual setup experience: WSL2 with Ubuntu 20.04, an installation problem encountered on one machine, replication on a second computer, and the communication setup needed to connect QGroundControl. It also records the initial command-level experiment and the work still required to move towards a rocket-specific scenario.
Screenshot from João Gil's December 2022 report. The scene is a simulated multirotor used for setting up the toolchain. Open the image to inspect the original resolution.
The lesson I take from this is to name the boundary of a successful experiment. Establishing that the simulator, flight software and ground station communicate is a useful result. A suitable vehicle model, representative sensors and failure scenarios are further questions, each needing evidence of its own.
Reproducible environment notes are part of the result too. A setup that another member can repeat is much easier to build on than one that only works on its author's machine.
Read the PX4 simulation report.
Use architecture to expose gaps
Afonso's February 2023 report mapped SAVOIR functions onto a proposed Pixhawk-based system. It considered processing, telemetry, time, storage and fault-management functions, then identified where the proposed arrangement did not provide the independence or redundancy being discussed.
One revealing example was essential telemetry: how could the system remain observable if the main software or processor stopped working? The report identified a limitation in accessing the proposed sensor data independently of that processor. That question turns a general aspiration for reliability into an architectural dependency that can be examined.
The compiled SitRep also discussed timing guarantees, interface and memory budgets, failure analysis and the cost of redundancy. Some sections remained open. Those open sections are useful evidence of the design's maturity: the report was a working engineering document, with decisions still to be justified and tests still to be performed.
A reference architecture gave us a vocabulary and a way to organise questions. The next step was to justify the particular functions our mission needed and show how the implementation satisfied them. Mentioning a standard or listing redundant components would not, on its own, demonstrate that.
Read the SAVOIR/Pixhawk study.
Make knowledge survive a change of team
A student project has to manage continuity as deliberately as code. The E-42 records include an onboarding guide, named responsibilities, periodic Markdown reports, version history and a longer LaTeX report that brought the work together. Members changed over time; these records provided a place to understand the work without relying entirely on the people who first did it.
My teaching contribution connected that practical work with dependable computing: model-driven development, real-time requirements, execution management, reliability and safeguards. My Dependable Computing article brings that material together.
For another team, I would make a short handover part of each completed task: the result, how to reproduce it, the unresolved questions and the next useful experiment. That would turn the reporting habit into a more consistent path from research to implementation.
What this work leaves behind
| Area | Documented contribution | Boundary or follow-up |
|---|---|---|
| Requirements and architecture | Mission decomposition, logging proposal, interface questions and a compiled Computing SitRep | Several budgets, design details and validation tasks remained open |
| Ground telemetry | Comparative studies and an Eggtimer adaptation of the White Vest ground software | Prototype code; the collection contains no flight-validation record |
| Simulation | A documented PX4/jMAVSim/QGroundControl setup and initial software experiments | A rocket-specific model and representative tests remained further work |
| Dependability | SAVOIR mapping, fault and redundancy discussions, and teaching material | Design reasoning and training, without a claim of certification |
| Team continuity | Orientation, named responsibilities, periodic reports and a shared technical record | A foundation for clearer handovers and repeatable experiments |
What I carry forward is the connection between technical leadership and the quality of the questions a team can answer. Requirements, interfaces, experiments and documentation have to meet. Helping that happen was a substantial part of my contribution to E-42.
Credits and materials
The reports reproduced here credit Luís Jesus for the competition, logging and parachute studies; João Gil, identified as Monkin in the repository, for tracking-system comparisons and the Pixhawk/PX4 work; and Afonso Baldo for the White Vest/Eggtimer and SAVOIR studies and the telemetry adaptation. The original report bylines are retained on the report pages. Pedro Afonso provided mission direction as product owner. Other members contributed to the department during this period; the named report and code authors here identify the work discussed in this article.
The ground software builds on John Jones's White Vest project, with its original licence retained. Figures from other projects keep their source references in the reports.
Read the situation reports for the original studies and figures. The ground-dashboard prototype was suspended; its code builds on White Vest and retains the upstream licence. The reports describe the tools and development state of their period.