An Update on the State of Programming

Written on7/3/2020

Hello readers!

As we approach the date of our cold-flow, we’d like to give you an update on our programming situation.

Snake, Gopher, or Gear?

The programming team has had a bit of a dilemma over the past few months in deciding which language to utilize for the flight software. We’ve considered three pretty different languages, each with their own set of pros and cons.


The programming team is most acquainted with Python, which makes it seem like a great choice to start off with. In fact, we did use Python initially for our flight software and for demonstrations at the STEM Symposium at Nysmith School for the Gifted. Additionally, Python offers great readability and is a mature language, with packages supporting I2C to web development servers.

In the end, we decided against Python because of its loosely typed nature, which could warrant unwanted errors during a critical launch.


After a long discussion on the next language, the team landed on Golang, a compiled, statically-typed language created by Google. This language seemed like an excellent choice because of its compiled nature and abundance of packages (again, which included the oh-so-crucial I2C module).

The flight software was developed for a few months during the spring of 2019. At the end of this period, it became woefully apparent that the unconventional syntax of the language was getting in the way of our work. It was time for a reconsideration.


Rust is a relatively new language, heavily backed by the Mozilla Foundation. Rust is statically-typed, and ships with the best compiler known to humankind. We finally decided upon Rust after an even longer discussion, weighing the steep learning curve against the benefits of speed, ownership, and a great type-checking system. The current flight software, which is written in Rust, is available at

What’s Been Done

Rust allows the programmers to structure code in an intuitive manner, allowing them to utilize concepts like traits and structs. Through this system, we’ve written the underlying templates for all the different sensors. Additionally, the IMU sensor module returns actual data.

enums (enumerations) have been created to represent return types of various functions, such as the SensorStatus enum, which contains either Safe,Warn, or Crit.


Since the devices will be in close proximity for the cold-flow test, Wi-Fi will be used for communication. The “rocket” and the ground station will connect via websockets, a protocol that allows for full-duplex communication. A basic telemetry module has already been written, which queries the different sensor modules for data and logs it to the terminal. Below is an example run:

Unfortunately, the data is only logged locally; we’re still in the process of transmitting data over websockets.

Next Steps

Functions and logic for controlling the valves still needed to be structured and implemented. We are considering using a PID (proportional-integral-derivative) controller to accurately set valves to achieve a desired reading.


After communication over websockets properly works, the logic for ingesting and executing commands will need to be written. This code shouldn’t be too hard to write.


There isn’t a set procedure for starting up. Currently, the code first attempts to establish a connection with the ground station. After that, data is relayed over this connection. In an actual rocket launch, the startup procedures would obviously be much more complex, with many more checks and stages.

Houston, Where Are You?

So far, the programming team has primarily been working on the flight software. However, as we near deadlines, we really should consider the following:

  1. How the data will be received and sent by the ground station. All outgoing data must be checked to ensure that the types match the expected command’s parameters.
  2. How the data will be displayed on a GUI, and how this GUI communicates with the backend which communicates with the rocket.

Overall, the journey so far towards building the code that we have so far has been great, even the arguments and debates over what language should be used and how to implement concepts (all things that make up a great team). Stay tuned for more updates!

Project Caelus | Copyright © 2018-2020. All rights reserved.