Let me give a little more information about the experiment.
In this first phase, I would like to see the viability to use Julia to control the satellite attitude (orientation). It is a dynamic language, very different to what we are used to (C/C++). However, it will bring a lot of improvements when developing the attitude control subsystem (ACS) because it will make the gap between the algorithm design and the embedded code smaller. Thus, the proposal is to build a mockup suspended by a thread and control it in one axis using a small reaction wheel. This will provide a very representative example of what will happen in space in terms of controller algorithm. Hence, I will be able to see if this system has the real-time performance required.
If this test is successful, I will apply for funding to build a small Cubesat that the only mission is to test the controller. In this case, there will be a lot of problems, as you said, about temperatures. The space is very extreme. While in Earthās eclipse, the temperature can go very low. However, while under direct sunlight, it can get very hot. There is an entire field called Thermal Engineering that takes care of those things. They will design a system to ensure that the temperature stays under operational limits. Notice that the lifespan of such missions is very small, usually less than 1 year. Thus, I really do not need to concern about radiation.
I believe you should be able to use a Pi 4 as a development platform (or perhaps even one of those new AWS ARM machines) and build a system image that works on Pi zero, with perhaps appropriate architecture flags. I donāt think these workflows are well tested though.
Does the stock armv7 Julia binary work on Pi zero?
Thanks for the tips! I think only an old version of Julia works out-of-the-box on the Pi Zero. However, I read that some people could successfully build Julia 1.4.1 for it.
Will it be too difficult to provide a āliteā version of Julia with a reduce number of packages from stdlib for such applications? Or will it be as difficult as the main distribution to be built against those ARM devices?
I would try with other options, e.g. (undocumented) --compile=min, it can be much faster, on my desktop (useful for scripts), and takes less memory after startup, and for each module added, if youāre swapping you should get much more dramatic speed difference:
I checked with ps aux:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
pharald+ 2956 0.9 0.1 746512 174300 pts/60 Sl+ 16:28 0:01 /home/pharaldsson_sym/julia-1.6.0-DEV-8f512f3f6d/bin/julia -O0 --compile=min --startup-file=no
after doing only: `using Revise`:
pharald+ 2956 0.8 0.1 778136 228476 pts/60 Sl+ 16:28 0:02 /home/pharaldsson_sym/julia-1.6.0-DEV-8f512f3f6d/bin/julia -O0 --compile=min --startup-file=no
then same for other startup options to compare:
pharald+ 3077 3.4 0.1 749620 185212 pts/60 Sl+ 16:33 0:01 /home/pharaldsson_sym/julia-1.6.0-DEV-8f512f3f6d/bin/julia --startup-file=no
pharald+ 3077 8.8 0.2 900608 330040 pts/60 Sl+ 16:33 0:07 /home/pharaldsson_sym/julia-1.6.0-DEV-8f512f3f6d/bin/julia --startup-file=no
There are no such plans, and providing anything non-standard significantly increases the burden of support. It should be easy to pair down the system image and packagecompile what you need. If anything, we need to make it easier to do that.
Julia can work for hard-realtime, and avoid the GC completely (not too difficult, but you want to make sure you do not mess up and do allocations by accident, that is easier than e.g. in Java): https://juliacomputing.com/case-studies/mit-robotics.html
It also depends on the hardware, and OS, as you say. ARM Cortex-R can run Linux (unlike ARM Cortex-M microcontrollers), and it and Julia can support, and I believe a real-time variant of Linux (or other).
In case someone misunderstood, you can only interface Arduino, i.e. send data to it, you canāt send send a Julia program to it. No original or even later ARM-based versions (unless I missed some recent more powerful with non-microcontroller ARM).
Nice! I think I will buy the Pi Zero and see if I can cross compile julia and itās sysimage. If not, if I can build it on the Pi Zero, then it is fine. There isnāt any problem to let it run for couple of days building julia. It will also be a very nostalgic moment remembering my days using Gentoo
Did you try to build Julia on the Pi Zero or only used the default pkg?
Well, I definitely should make a way to use Julia in Pi Zero. The Pi 4 requires 3.4W, against 0.7W of Pi Zero. For CubeSats, it is common to see the entire power budget be between 3 to 8W. Thus, Pi 4 is definitely a no-go.
Yes! It was very good! However, my Raspberry Pi stopped working and now I am desperately searching for a Pi Zero 2 here in Brazil at a reasonable price to continue the project
Iām also hunting for one with no luck in Romania. As alternative I found the Orange Pi zero 2 or the 3 lts. They have Arm V8 processors, so Julia should run on them.
And we are back in the business! BaremetalPi.jl 0.1.2 is working perfectly with the Raspberry Pi Zero 2W (Manjaro Linux) and the official AArch64 Julia build.
I can also confirm that Julia 1.7.2 works on the Pi Zero 2W with 512MB of RAM.
Precompiling: Interpolations, DataFrames, HTTP, JSON, Statistics, Random, Base64 takes ages (hours), but after that the sailing is surprisingly smooth, at least for the task that Iām throwing at it: basic Dataframes filtering, csv read-write, applying moving averages, min, max, HTTP requests.
I recommend using the Raspbian lite, itās much more responsive compared to the GUI version. Running Julia and tinkering in another terminal with git/editing text files is great! The GUI version is pretty much unusble on the Pi Zero 2W if you want to do anything with a web browser.
Julia is currently using 60% of the available memory. I increased the swap size to 2GB, just in case.
