
Docker containers in space - adunk
https://www.balena.io/blog/beyond-the-cloud-docker-containers-in-space/
======
bsder
For anyone who reads this, _NEVER_ use an I2C bus on anything which needs
reliability. Ever.

Use CAN, preferably, or SPI, if nothing better. Even old school RS-232 is
probably superior.

I2C simply isn't reliable in harsh environments without extensions (I believe
that there is an ESA paper on this somewhere).

CAN, in particular, was built for harsh environments (automobiles).

~~~
patrickyeon
A blanket ban like this isn't particularly useful advice. I2C is perfectly
useable in less-than-perfect environments, and LEO isn't really as harsh as
people make it out to be. It's really only going to be a problem if you assume
that everything operates perfectly all the time, and if you're making those
assumptions you're going to have a bad time working on remote systems anyway.

Make sure your drivers can handle NAKs and errors on the line. Make sure you
can reset subsystems (probably by power-cycling) completely and your system
can keep running. Be ready to deal with stale sensor data or having to do a
few retries at times. With these and some good testing you'll be fine with
I2C, and really there's immense value in having those attitudes in your system
design anyway.

I was a design EE at Planet Labs for 4 years, have sent something like 200
satellites to space, each with literally dozens of I2C devices on them, and
supported them in orbit.

~~~
bsder
> Make sure your drivers can handle NAKs and errors on the line. Make sure you
> can reset subsystems (probably by power-cycling) completely and your system
> can keep running. Be ready to deal with stale sensor data or having to do a
> few retries at times.

By the time you've implemented that, you've negated any advantages of I2C. So,
why not go directly to SPI?

~~~
patrickyeon
Because a whole bunch of chips you want to use are on I2C. And/or you want to
work with a large number of devices, and a chip select per is a lot of GPIO to
burn on this. Also you're going to want to handle errors and bad devices on
SPI, so it's not like that's new work anyway.

------
Rebelgecko
It's interesting that it doesn't sound like they're using any sort of watchdog
to detect for things locking up, and they're using SD cards for their "read
only" filesystem. I suppose it's less of an issue for sounding rockets

~~~
petrosagg
balena founder here. balenaOS does use the hardware watchdog available on the
raspberry pi to detect CPU lock ups and automatically reset the board. On top
of that we're also running software watchdogs that check the health of key
system components and restart them if they become unhealthy.

It's true that SD cards are known for getting corrupt. balenaOS separates the
partitions of the device and keeps the userspace in a readonly one while
keeping mutable OS state in a separate partition. We are very conscious of
writing as infrequently as possible to the SD card for this reason. The
partition that accepts the most writes is the one holding the user container,
which will get written to during an update, and also in case the user
container stores any data on the device.

I'm aware that SD cards will internally swap blocks and don't really care
about partition boundaries but assuming you're using an SD card with a well
designed firmware it shouldn't lose a block during wear leveling.

That said, the SD card problem is one reasons we designed balenaFin :)

~~~
sgtnoodle
I've personally seen many dozens of SD cards fail such that they don't even
know their own sector count anymore. My suspicion is that in-progress wear
leveling operations aren't rebust to sudden power loss (ejecting card without
unmounting it). Most likely firmware specific...

~~~
petrosagg
Yes, and this problem is exacerbated by the raspberrypi's microUSB power
input. We've seen countless number of cases where a Pi exhibiting SD card
corruption was also experiencing undervoltage. If you're using raspberrypis in
production it's paramount to have a good microUSB cable and power supply

------
lukejduncan
Planet Labs runs Ubuntu on their Satellites. I wonder if there were any docker
containers running on those or similar cubesats.

------
jt2190
Related: In 17 days the door closes on StackBlitz’s payload of a RaspberryPi
server hosting 1000 web apps [1], so if you’ve got something you want in
orbit, act now.

> the plan is to broadcast a public wifi hotspot that passerby aliens can tap
> into while their teleporter beam slowly slurps up unsuspecting humans

[1] [https://deployto.space/](https://deployto.space/)

------
covermydonkey
I wonder what timezone the containers think they're in?

~~~
LiamPa
Good question as time is slower in space..

~~~
DannyB2
Time is slower (relative to us) due to spacecraft being in motion (relative to
us).

But then time is faster (relative to us) because it is higher up in the
gravity well.

[https://www.telegraph.co.uk/news/science/science-
news/802098...](https://www.telegraph.co.uk/news/science/science-
news/8020988/Einsteins-theory-of-relativity-works-on-a-human-scale-the-higher-
you-are-the-faster-you-age.html)

So which one wins out?

~~~
teraflop
Interestingly, it depends on your altitude. For objects in a low, fast orbit
such as the ISS, time runs slower; in higher, slower orbits, such as GPS and
geostationary communications satellites, time runs faster. In between these
points, the effects cancel out at an altitude of roughly 3000km.

[https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time...](https://en.wikipedia.org/wiki/Time_dilation#/media/File:Time_Dilation_vs_Orbital_Height.png)

However, both effects can be ignored for almost all purposes. The effect of
time dilation is less than 1 part per billion, which is basically undetectable
without an atomic clock.

~~~
jononor
Yes, especially because clock drift on the crystals is several orders of
magnitude higher. Often 10 parts per million, or more.

------
alpb
Related: NASA has previously done some work with Kubernetes and Docker
containers.
[https://www.nas.nasa.gov/SC17/demos/demo29.html](https://www.nas.nasa.gov/SC17/demos/demo29.html)
It has happened on the ground, however.

------
nategri
Both comforted and alarmed to see all that perfboard in something that crossed
the Karman line.

------
heelix
Crazy how fast that sounding rocket was at launch. I don't think I'd ever seen
one before... and man, did that move with purpose.

