This website is my personal playground. Here you can read posts that I have written, find out more about me and my experience, my portfolio of projects on Github, and contact me.
Literally a month ago we investigated Rust. In that time I've completed most of Rustlings and made my way through probably 50% of The Book. However, in that time work has finally purchased Matlab. Now I'm all aboard the Crab-carriage, and I am a true believer that Rust is amazing and useful. On the other hand, I bloody love Matlab. Unironically.
I believe that every language has its place. Matlab's place is in my heart (and as an excellent general-use tool for mathematics, statistics, signal processing, control systems engineering, etc.). Rust's place is in my head (and as a very performant, robust and stable work horse). So I'd like to adjust the project plan to incorporate the various languages and leverage them each in turn. They might be smushed in a bit, but I'd like to use this project to learn.
Therefore, the plan is to first develop some sub-project to exercise the workflow. This workflow should include the requisite project structure, each of the languages I'd like to use (Python, Rust and Matlab [autocoded to C]), any auxilliary part of the workflow (CI/CD, Docker, Git, etc.), and be very well documented. This will give me an opportunity to work out all of the complexities of using ROS2 on Windows, with a Rust node and a Python node and some C thats been autocoded from Matlab. It will teach me the various mechanisms for leveraging each language, and how to build and run tests.
For this project, I'm going to make it as simple as I can, because I'd like this to be relatively quick, and to exercise the structure, format, and process, rather than my coding chops. So the project is going to be to simulate a space rover (mathematically), generate dummy data in the language, node and container that will eventually handle that part of the system, and have it all take place on ROS2 nodes within the ecosystem that I plan to use. I'll skip a bunch of the integration effort and the build process and the like.
There are several benefits that spring to mind for this project: First, I'll learn the required skills, in a way that is very direct and adjacent to my use-case. Second, I'll have a project configured that does a significant minority of what my final system ought to do with a layout and workflow that I'm familiar with. Third, I'll exercise all of the development frameworks that I'd like to adhere to, such as CI/CD, Docker, and Git. To that end, I've made a public repository on Github for the space_rover, there I'll practice my good development practice. Hereafter, my intent is to develop minor models of the final functionality in the various programming languages within the monorepo.
So that's it! Apologies for the delay, and the short post: I'm rammed at the moment.
Rust is growing in popularity. I know this because I'm being asked by people who don't code for a living: "Do you use Rust?" I'll happily ignore my fellow normies, and my esteemed colleagues that are also quite excited by Rust. But, I should give Rust it's day in court, and do a little research.
Rust has a lot of "programmer" features. What I mean by that is there's lots of features that 99% of people, and 97% of programmers don't care about. But, the select few that do are the serious programmers that the world runs on. We shouldn't ignore this tiny number of people; they're always watching...
However, that does mean that a lot of Rust's benefits are somewhat difficult for a normal human - such as myself - to grasp. Most of the time, I read posts like "Why Java is the worst language on the planet" which starts with a 3 page description of why Java is too verbose because it takes 6 lines of code to write "Hello, World!". Or, "Why Golang isn't all it's cracked up to be", followed by barely coherent ramblings about classes, inheritance and polymorphism. If you read these posts and find yourself nodding in agreement and not to sleep, the post hereafter is likely not to your taste.
Now, for the bits that do sound cool. Rust's primary draws, it's Unique Selling Points (USPs), so to speak.
TOS is a set of rules which underpin the safe usage of memory using the stack (fast), and the heap (slow). High overhead languages (which I'll ruthlessly combine for this comparison) such as Java, Python and Go have automatic garbage collection, which periodically checks the memory for resources that are no longer necessary, and returns them to the operating system. This introduces latency and higher general memory usage. Low overhead languages like C/C++ leave you to handle your own garbage, and - as you can expect - this leads to a huge range of "C-bugs" that are unique to languages like this. Null point dereferences, use-after-free errors, data races and buffer overflows, which lead to cluster headaches. Then there's rust. It enforces that:
The benefit of this is that the garbage collection is highly efficient. Instead of relying on the programmer to return the memory, or having a garbage collector with a massive overhead, Rust tracks the scope of the variables, and returns the memory once the variable that owns it goes out of scope. A further benefit is that concurrency is safe. Meaning you can leverage multithreaded code and build robust, scalable applications.
This one is a bit simpler to understand. C++ is really fast. C++ is really fast because it is a compiled language with direct memory access and low-level control over system resources. So is Rust! See? Simple!
This sounds like a bad thing, and honestly it can be quite annoying. But, combining TOS with Rust's strong, static type system means that the vast majority of errors are caught by the compiler, rather than your poor user at runtime. In fact, some Byte Bards have suggested that learning Rust is easiest if you ignore TOS and just write the code how you want to write it, and then fix the errors that the compiler raises one-by-one. This is particularly exciting for me, as I am an idiot, who shouldn't be given additional power.
However, this has led to Rust being a front-runner in perhaps the most irritating tech-bro trend; "Vibe-coding". Vibe-coding is essentially the process of begging the latest LLM to do your homework, and typing "No no, not like that" until the code does what you want. Fortunately in Rust's case you don't even have to run the code to see that your LLM has hallucinated a function or ten.
Now, we're all aboard the Rust-train, the Crab-carriage or whatever. If I remember anything from reading lots of self-help books in my teens, it's that learning starts with metalearning. So, here's how I plan to learn Rust in three headings:
"The Rust Programming Language" is the book for learning Rust. Written by Steve Klabnik, Carol Nichols, and Chris Krycho, with contributions from the Rust community, The Book is the widely acclaimed reference for learning Rust, and contains everything a budding Rustacean needs to join the crab-bucket. The particular version I've linked is a fork of The Book by Brown University, which adds interactive elements like quizzes into the browser to cement the lessons throughout.
A worthy follow-up to The Book. Rust by Example is the famous "working mans" Rust dictionary, containing simple and succinct descriptions of the various nuances within Rust, and how they related to other languages. Some argue that it presents opinions as facts, but it holds a special place in the Rust lexicon, and will supplement my learning via The Book.
First off, super cute, right? Rustlings is a repository of kata, from the Japanese "form" or "pattern". These are micro-problems that a Rust developer should practice repeatedly to master the Rust language. They are the programmers wax-on, wax-off. The best thing about Rustlings is that it was written as a companion to The Book, and follows its format neatly. This means that throughout The Book you can pick up new kata, and naturally grow your Rust lexicon.
I've spent the last 8 years or so in academia or employment. In both settings, my primary effort has been exerted on the development of novel ideas that nudge the window of possibility. My graduate degree was almost entirely in Matlab, and wholly theoretical. The system I intended to deploy my software still doesn't exist. So I spent my time in the world of simulation, and developed high fidelity models of the system and the environment in order to convince myself, my peers and experts in the field, that what I later derived would work. Thereafter, my professional career began at a large firm working on problems far closer to reality. But, as is the case with most large firms, the problems were disconnected from the products. In fact, I don't know what products my code is on - if any. Finally, my current role is much more hands-on, and my code runs on products that I've held. My work pulses within the computer, and I see its effect daily. However, as the product has matured, and my subsystem stabilized. My daily work has strayed from the direct, and slipped into the documentation required to deliver.
I need a project.
When we land on a distant planet. The brainboxes on Earth already know a heck of a lot about the challenges. They map the landing area in intimate detail, tracking several features such as the roughness of the terrain, rock size, type and density. They plan the routes they'll take, they have primary, secondary, tertiary and qu... quertiary? landing zones. To do this they send orbiters that orbit the target planet and thoroughly study the surface. They look at the macro-features of the planet, such as mountains, lakes, valleys, etc. and then specify areas to land. They do this through careful evaluation of two properties. First, they look for flat, open space. Somewhere absent any big boulders, and flat relative to the gravitational pull of the planet. Next, they look at what is scientifically interesting. Perhaps there's evidence of a river, or a strange rock formation, or an old system whose data could be useful.
Once that's done, we're ready to land. A rocket makes its way, lands and drops off the rover. In this example, the autonomous rover explores the surface, inspecting for craters, rocks and hills which could cause issues, and uses the high quality maps generated by the orbiter to select locations that it wants to investigate. It analyzes the various sites and plans a trajectory between them, then executes that trajectory. Throughout, it checks its tyres, fuel, power, etc. to make sure it can safely complete the mission. It might also report back periodically to make sure the data it has collated is not lost if the rover fails to return. This is what we intend to create.
Unfortunately, my budget is a little south of NASA's (even post-Trump), and so I'll have to settle for something more down to Earth. Therefore, my concept is that my cul-de-sac is a new planet. I'd like to map it using a drone, and then send a rover round to collect science. Bonus points for if I can deploy the rover, but I have little-to-no immediate ideas of how I can achieve that. I'd also be really chuffed if I can incorporate the navigational information provided by the high quality map via some data fusion. As a far off desire, having both systems operating simultaneously and having the rover and drone communicating updates would be a very interesting challenge.
In terms of hardware, I'm lucky enough that I have collected most of what I'll need prior to starting. I have a DJI Mavic Mini that I can use for the project, and two Raspberry Pi Zero W's that I can use, as well as all the cables I'll ever need, and a generic powerbank, that should hopefully give the rover enough range (TBD!). I'll definitely need some more kit for a rover, such as wheels, motors, a chassis and maybe a bigger computer (depending on what I get up to), so I'll get some of that stuff ordered.
My intent is to use this project as a bit of a learning exercise for me, and one thing I've had my eye on learning is rust! So I'll write a good chunk of it in that (probably the rover's brain. I use Python a lot at work but rarely get to use it for the AI/ML libraries that my colleagues are always chatting about, such as PyTorch and OpenCV. So I'll use a bit of that for the map generation I think. I've had this drone for a while and I've flown it around a bit, but I've not looked into the DJI SDK, and automating control of the DJI outside of the app. So lets give that a go as well. Finally, I'm always looking to throw a bit of maths in the mix, and so I'll try to use some numerical optimization to solve the travelling salesman problem that arises when we have multiple points of scientific interest, and various complexities in getting there.
Obviously this is a bit of a loose plan, so I'll need to sure that up a bit. But I like the skeleton of it. My first step is going to be getting the drone flying via Python and mapping the neighbourhood. This will be a good soiree into the DJI SDK and provide some useful data for simulating/testing the rover, de-risking the later stages of the project.