Help to select a Raspberry Pi for embedding Julia application

Hi!

I would like to buy a Raspberry Pi to do some experiments about embedded applications using Julia. Basically, I want to test thinks like latency, real-time performance, etc. Thus, I need to install Julia and a lot of packages (including some “big” ones like SatelliteToolbox).

In this case, what are good requirements for the Pi? How much RAM? What size of the memory card should I get?

4 Likes

There are some benchmarks that might be useful in this thread. The big takeaways for me are get as fast an SD card as you can, and if you decide to use a Pi 4, running a 64 bit OS is a substantial improvement.

5 Likes

Thanks! I will indeed need 64-bit support, that’s why I will get a Pi 4. I just cannot decide if I need to spend more to get 2 GiB of RAM or if 1GiB of RAM is enough.

I’m running Julia on a cluster of Pi4’s[1]. It’s slow. I’d recommend more RAM. If you can spring for 4GB, do it.

I also run 64-bit Ubuntu (20.04 as of last week) on them. It’s nice.

[1] yes, a cluster of two nodes, with Slurm and everything. 8 cores!

6 Likes

This also depends on what you consider “embedded”: the Pi 4B is the most powerful, but will also need an external fan for any practical use even after the firmware upgrades that fixed initial throttling issues.

Given the model, just pick the one with the largest RAM, and a decent SD card (plenty of benchmarks/recommendations on the net).

Overall, Julia is not the ideal application for the Raspberri Pi, unless you can keep a single process running so that everything else is compiled, or use precompilation. But of course you can make it work and it is a fun project.

2 Likes

Thanks @Tamas_Papp!

I would like to test whether Julia is suitable to deal with attitude control in a satellite. The Pi seems to be the most compact device that I can use to run Julia decently.

The workload is minimal. It is a single Julia process gathering measurements at 10 Hz and changing output signals at 1 Hz. I want to see the problems related to this approach. Things like real-time performance, latency, RAM usage, etc.

The precompilation can be done at startup in a stage I call “warmup”. After that, I will not have any problems.

I also can use PackageCompiler to create an executable, but I want to avoid that. My goal is to have the very same code I use in the simulator embedded into the satellite computer.

It is a big project, but it seems very fun :slight_smile: if anyone had experience with a similar project and want to share to me, I will appreciate!

2 Likes

I think that it can be a fun experiment, but not nearly approaching anything you would want to put on an actual satellite. A Raspberry Pi is a toy computer, can lock up for no good reason, and of course it has non-ECC RAM so in orbit I expect it would fail very quickly.

FWIW, the latest project I did with Pi was an IR camera with motion tracker to capture images of nocturnal animals (mostly birds, hedgehogs, and all the cats out to get them, except the hedgehogs which know how to take care of themselves) in our garden, on a Raspberry Pi 3B. No Julia, just motion. Even with this super-light load, the board can just lock up occasionally. Or work for months without problems.

3 Likes

Hum I see. I think I need to check another SBC maybe? Suggestions?

This kind of experiment can be used in Cubsats. In this case, I can have a computer that will monitor the one with Julia. If it locks, then it just takes the control while it reboots. The Julia app will be the payload in this case.

Actually, I really do not need computational power. Do you think I can go with the Pi Zero? The lower features will help with the power consumption.

Well everyone knows my answer… a Jetson Nano.

You can get the Dev Kit with all the USB interfaces etc.
But the actual Nano is on a board like this:

You then use it with a carrier board.
I have no idea if this is suitable for a Cubeset, and it is certainly more power hungry than a Pi.

Google search shows this:

https://www.researchgate.net/publication/337012343_Conceptual_low-cost_on-board_high_performance_computing_in_CubeSat_nanosatellites_for_pattern_recognition_in_Earth’s_remote_sensing

I know nothing about satellite control, but I would go with an application written in C. You can still use Julia for prototyping and then generating test files (duplicating the calculations the C code would do).

The Pi Zero is actually a pretty powerful unit for simple embedded control. Apparently people are thinking about Raspberry Pi and cubesats — you should find plenty of reading material on the net.

2 Likes

I dod a quick search. Four years ago smeone was working on an interface between Juia and Arduino.
Clearly you would program the Arduino from your main system then send it off on the satellite.

1 Like

This is the status quo. Almost every satellite attitude controller is programmed in C. Some using a real time operating system like RTEMS others are just a single process.

What I want to do is an academic research. There was a lot of investment to generate code from MATLAB so that the distance between the engineer and the implementation is smaller. I want to test if I can do this with Julia. If it works, then it will be just amazing!!

Thanks! I will take a look. The other possibility is try to create an executable from Julia to be used in the embedded system. However, I think this is far away to be possible. Last time I checked, all executables created by Julia depend on all the libs.

1 Like

I would second @Tamas_Papp here. If I were doing something like this, I’d probably do this in C (or Rust). Garbage collection and latency, even at low sample rates, and the fact that post-deployment debugging would be problematic, would steer me to something low-level on a RTOS.

2 Likes

Yes, I totally agree, but this is an academic research project. We may find a very good usage of Julia or not. For my application, since I can block garbage collection, it does not seem a big deal. It is more or less like this: during the 1s of sampling time, the process will actually do something only during the final 100 ms. The other 900 ms will be in idle, when GC can be activated.

However, we will have a huge gain if we can use the very same controller code that is being used in the simulator. This will decrease a lot the requirements for testing and validation of the controller itself (of course, after all the Julia-based embedded implementation is validated).

1 Like

I have been experimenting with Julia on the RPi 4B. You don’t have to use a fan, however, there are passive heatsinking “cases” which do a very good job. The heatsink will get very warm!

The advantage of the RPi 4B is that it will use the ARM64 binary just fine. So I can use the latest and greatest version, which is currently 1.4.1 by simply downloading the binary into the RPi 4B. You can install Ubuntu Server, and then add a desktop if you wish.

https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview

I prefer Xubuntu.

Now I also wanted a much lower power option. Raspberry Pi Zero worked for my simple project, however, the latest binary will not work due to having an incompatible 32 bit ARM. I installed the Raspian repository version, which is 1.0.3. Fortunately with my simple project this worked perfectly!

My project is a SPI interface driver. I wrote a simple shared library in C, and I use the ccall function to drive the RPi SPI interface from Julia. Yes, I could do the whole thing in C, but then I would not have a scripting language and a REPL.

Raspberry Pi + Julia maybe not a serious embedded platform, but it is a lot of fun!

Regards,
Greg

3 Likes

Thanks very much!!

I was looking at the specs. and it seems that the Pi 4B will be overkill (the test device must be battery-powered, and it is very hungry). So, the Pi Zero W should be enough.

With respect to the Julia 1.0, isn’t possible to compile (or cross-compile) Julia 1.4.1 into it? I saw some people on internet doing this. Did you try, is it possible?

In you project, did you test things like latency? I think I will have to compile a kernel with PREEMPT-RT to reduce the latency. Hope it works well with Julia :slight_smile:

Latency is not an issue with my project. I can work with kilobit per second data transfers. The RPi SPI bus can go much higher than that and it would work, but I don’t need the speed or minimal latency.

I was going to explore cross-compiling Julia to a compatible binary, but then I discovered the Raspian Julia worked perfectly and that was the end of that. I have a Pi Zero W on order so I my project (which involves antennas) can be located outdoors in the backyard.

2 Likes

There’s a video from 2019 Julia Convention (JuliaCon 2019 | A New Breed of Vehicle Simulation | Tucker McClure - YouTube) in which the presenter walks through designing flight control for a UAV, starting with control algorithms in Julia, then ported to C (I think through Cxx.jl but you can also put them in a .dll/.so and use ccall), then ported to C on the microcontroller via network interface.

The porting from Julia to C is still manual, but once you have the plumbing connected you can run the same test suite on Julia and C versions and subject both to simulations using the DiffEq packages.

2 Likes

Yes, this is a contingency plan. Replace the callback in DiffEq with a C function that is the controller. Thus, I can run the same env and check if everything is right. However, I really, really want to try embedding a Julia application to see what I can achieve :slight_smile:

Notice that an UAV requires a control step way smaller than what I need in my application.

1 Like

I certainly don’t mean to discourage you from that goal. It sounds like fun. I have tried to run Julia and DiffEq stuff on a RaspberryPi and gave up because the compilation steps needed more RAM than I had (mine might have 1GB), so I would echo others in saying you’ll want as much RAM as you can get. On the other hand, if you don’t need large packages, it will certainly work. I was able to wiggle GPIO pins at 5 MHz using ccall to the libpigpio library.

1 Like