💾 Archived View for freeside.wntrmute.net › log › 2022 › 20220214.gmi captured on 2022-04-29 at 11:01:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
now listening: Components - Tom Matta Big Band (via MNDP)
For a long time, I've had an idea for a project: to simulate a mission to Proxima Centauri on a computer in real time. There's a couple reasons I want to do this: I think it's an interesting exercise in keeping a computer running for a long time (just over 1900 days, if my math is right), and because I'm a space nerd. It just seems like a cool idea. I sketched out the idea in Mathematica, then wrote some Go code.
What exactly is this? I wrote some code that is a *very* *basic* simulation of a flight to the star Proxima Centauri. In the real world, I plan to run a single process for nearly five and a quarter years. If it fails or stops, the mission is lost, simulating the requirement for a stable control system for the ship. This means that if I move, I can't just turn the system off. I've set a "launch" date for my 35th birthday, which is when the system is finalized and the simulation can't be touched. That means I'll be just over 40 years old when it finishes, which is a little sobering.
The long-term constraint implies the need for some sort of battery backup. I also need a durable display, so that biased me towards an eInk display. I have a bunch of embedded hardware lying around, so I figured a spare Raspberry Pi (3 Model B Rev 1.2) in my Bucket O' Crap (actually a toolbox), a PaPiRus eInk display, and an 18650-based UPS would work. I have another eInk screen that I could use too, but the PaPiRus has an onboard RTC; later I found out that the UPS I have does too, but the PaPiRus one works pretty well as the system RTC. I have a UPS from MakerHawk that uses two 18650s and has an I2C interface. I still need to figure out a case, but this setup works pretty well for now.
PaPiRus eInk display (discontinued)
The one big constraint is that I can't take down the software, because the progress would be lost (otherwise it wouldn't really be that interesting). When I started writing this, I had the display and backend in one binary, but I've decided to split them out. That feels more like it follows the spirit of the thing.
The core simulator is written in Go, using a lot of math/big. I learned a lot about computing using large numbers while writing this. As part of the project, I wrote a flight simulator that just applies updates with no delay - it still takes just under 2 hours to run on this machine.
On the Raspberry Pi, the flight control system (the actual software that will be running long-term) uses about 1.5 MB of memory, usually taking up about 10% of the CPU according htop(1). I was pleasantly surprised at how performant the Go math packages were for what I was trying to do.
I've been hacking together the interface on the device because there was a lot of undocumented stuff that I had to work out. I think I'm pretty close.
I'll probably keep a project page here on it, and probably build out an API to keep track of the progress of the system publicly.