Real time operating systems. Less fancy than they sound but the devil is in the details. Robots need things to happen at a certain speed and at the right time so we have a type of scheduler (that can be patched into the linux kernel) that sacrifices absolute throughput to try and guarantee tasks start inside a particular window. Funny enough, if you've done game development and recognize that everything needs to happen inside 1/60th of a second or better, you know some of the hard parts here.
Memory mapped addresses. C is scary but ultimately fairly simple. Once you get the hang of doing silly things with pointers and arrays, the next step is dealing with microcontrollers. You probably wonder how they do anything without an operating system though, and the answer is memory mapped IO. They have a fully flat memory space, starting with 0x0 and going up from there. That space usually contains basically everything from your stack, heap, flash storage, and all the peripherals like GPIO, I2C, SPI, serial, and so on. You can literally do things like int* x = 0x12345678; *x = 0x1; to turn on an LED because the device is listening for changes to that address to set the output state.
There's a ton of other stuff, but these are the gateways to understanding the space you're dealing with at a basic level.
I remember reading a book that explains the low level Arduino schematic paired with C code that does exactly what you are describing. Is there any such book for modern microcontrollers?
I'm only half kidding, the programming manuals are pretty good these days. Honestly there's more in common with the arduino and a modern uC than there is different. If you want to use the knowledge in anger you need to learn linker scripts, makefiles, gcc, gdb and jtag so you can deploy and debug code on boards that don't have self-flashing bootloaders and FTDI baked in. There's also some tribal knowledge about how ISRs work like keeping ISRs as short as possible (no print statements) but I don't know what books cover that.
* Agile for software-hardware is hard if not impossible. For software it can be reasonable, but it’s really hard to iterate on both hardware and software at the same time. It’s easier if the hardware designed is locked or the process involves waterfall on the hardware side. * I often found that people that come from pure software to robotics don’t have control experience and something that can be easily solved with a PID controller end up being a custom code that ends up being way more complicated than needed.
If you have any custom hardware, you are basically stuck with a turn time of at minimum a day or two for any changes (often more, weeks + for new PCBs is common if you're not throwing huge amounts of money at people).
In this context, any process that depends on rapid small iterations is basically impossible, because each iteration just takes too much time.
Pieces of code interact more heavily than a linux machine. Testing requires more hand-holding/baby-sitting. Cross-platform architectures don't scale down well. There are many types of comms busses with no/few standard embeddings.
Some teams know how to make it a lot easier. Some CTOs know this, but most find out the hard way. Embedded practices lag webdev by 5-10 or more years bc they were good enough for a long time or for small projects. Expectations are rising, but there is less leverage than adtech so salaries are ok but not explosive.
Then once you know how it works and have done most of your optimizations, you can trim down the BOM and get rid of hardware that proved useless. You'd probably want another round of tuning at this point, but at least you know basically how it works, and have tried out many different combinations of hardware in your software iterations.
But quite a lot of CS people -- well at least I hope it is not just me -- end up on the web development trajectory despite or because of having less than good enough understanding of e.g. trigonometry, geometry and calculus... all of which start to matter a lot when you are starting to make things; especially things that move and consume electricity.
I am a good programmer but a weak mathematician. I have a 3D printer now, and I'm starting to learn FreeCAD and microcontroller stuff actively rather than just reading about it, and run up against my maths weakness all the time.
I have recently discovered the three books Joan Horvath and Rich Cameron wrote:
https://www.makershed.com/products/make-trigonometry-print
The other part that’ll catch you pretty hard if you don’t have strong trig and linear algebra going for you is that debugging is going to be really hard. I admittedly have been deep in positioning-and-attitude control for 5 years now, but the ability to look at a transformation matrix or quaternion and mentally grok exactly what it means odd going to be incredibly useful when you’re trying to figure out why your system isn’t doing what you think it should be.
My calculus is strongest; I can deal with that basically. My geometry is so poor that I am surprised I passed my maths A level.
These books excite me because they give back that, er, constructivist thing that has always appealed to me -- Piaget, Papert, Minsky.
I enjoyed your article, thank you for writing it.
But the pay/perks situation is dependent on putting up with a lot of corporate BS; if you're a solo developer, or the only developer in a small team, web stuff is hard, the task shrinks over time as things commoditise and you become more dependent on hosted offerings, and pays relatively poorly. I am tired and seeking a direction change before it is too late.
Literally the only topic on which I agree with Elon Musk is that more developers need to be persuaded to do something more interesting than getting dragged into web dev BS. And I wish I'd paid a lot, lot more attention in maths lessons away on topics that didn't have to do with logic.
(It is, nevertheless, amusing that it is web dev BS where Musk is getting his posterior handed to him)
The number of people who both know C++ (not C) and how to use an oscilloscope is surprisingly small.
Electronics at robotic speeds isn't that hard. Most signals are audio bandwidth or lower. You rarely need all the elaborate design techniques needed when you get into the MHz-Ghz range.
Statements like these make my eyes roll.
The difficult part in embedded, and what makes the difference between a n00b spending 2 months finding a hardware/firmware issue and a graybeard finding it in under 2 days, is not how to use an oscilloscope or how to write "clean" c++, it's knowing where exactly to put the oscilloscope probes and what exactly to look for on the oscilloscope screen, and how to make the bug/edge case reproducible.
You don't have unlimited scope probes, trace memory and time to probe every single signal on the board and stare at blank signals not knowing what to look for, for weeks, while th clock is ticking.
Tinkering with STM32s and Raspberry Pis at home for fun, doesn't prepare you for the issues you'll encounter in debugging production devices (especially battery powered or RF) you'll need to ship on time and on budget.
Knowing how to use a scope and how to write c++ is only 10% of a successful product. The other 90% is blood, sweat and tears hunched over for hours/days over boards and breakpoints to find out your race condition comes from a cheap crystal oscillator operating out of spec and not from your software.
Especially that at small companies and start-ups you don't have the budgets and HW lab equipment that the likes of Apple or Qualcomm can afford to brute force your way to the solution, so you need to be very shrewd and clever with your debugging to make the most out of your limited resources.
I recommend using Arduino and/or Wokwi (https://wokwi.com/) to get started.
So I do physical things in my personal projects and then come to realize that the potential return on investment (time spent vs. expected money) would be peanuts in comparison to pure software. I would love to know of hardware related work that has decent margins. Or at least enough margins to justify paying a good salary to enough engineers to sustain them.
This cannot be said enough, IMO. The web software world's endless quest for the shallow and lucrative is exhausting.
My own shitty first foray into robotics is an RPi that I can talk to [2].
If you didn't see "the coolest robot I've ever built" you gotta watch that... so inspiring [3]
Latent Space has a robotics demo day coming up, pretty curious to see what comes out of that [4]
Some stream-of-conscious thoughts about why I'm drawn to robotics:
* The maker / hacker / homebrew communities that are basically just using robots to express art. Maker Faire, Burning Man, etc.
* The satisfaction of writing code and seeing something physical happen. Last week I was trying to figure out how to get a shitty third party Amazon robot hat [5] to actually do something useful so I was iterating through the GPIOs and I somehow made it actually smoke. I'm weirdly proud of messing up so badly that my hardware actually smoked!
* The joy of demystifying hardware and learning all the layers of abstraction just within hardware
[2] https://www.biodigitaljazz.net/blog/STTTGTS.html
[3] https://news.ycombinator.com/item?id=38162881
[4] https://lu.ma/latent-space-final-frontiers
[5] A Xmas present from my sweet wife, really touching that she's encouraging me to actually pursue my interest in robotics
source: I work in robotics. AMA.
That may be the most number of times I've typed "etc." in a paragraph.
Using simulation to train a DIY spot on something novel and see how good I could get the performance in the real world.
Of course that's a dream of mine one day and not an active project.
You just need to pop in 3x18650 batteries in the chassis and connect a Jetson nano to the UART pins. It has an ESP32 inside, so you can also program that, but it comes programmed out of the box.
You can control it with this python library https://github.com/msanterre/wave_rover_serial
Isaac SIM is a terrific simulator, you won't get much better.
https://www.allesblinkt.com/projects/round-about-four-dimens...
Hope this is not considered too off-topic here.
That cube is amazing. Thanks for sharing. The aesthetic is so polished. Some true 21st century art right there.
This made the rounds a few months ago but worth posting here again. So inspiring. https://www.youtube.com/watch?v=bO-DWWFolPw
The article suggests playing around with a Raspberry Pi Pico, but this is a bit bare bones. Are there any kits, or entry level programmable drones on the market with a reasonable toolchain to program sequences?
https://www.bitcraze.io/products/crazyflie-2-1/
https://www.bitcraze.io/documentation/repository/
It was mentioned in this IEEE Spectrum article: https://spectrum.ieee.org/drone-quadrotor-2667196800
I have looked at the Ryze Tello [0] before, and it seems like a decent entry-level device, but I'm not sure whether it's actually a huge pain to develop for. I'd like something to be extendable _like_ a Pico, for instance if I want to install additional sensors, but all of these platforms are quite foreign to me.
https://www.coppeliarobotics.com/
But take your pick there are many to choose from.
https://www.sciencedirect.com/science/article/abs/pii/S15691...
I think it was an issue from 2022 or 2023 (not enough energy currently to track down the issue in their catalog)
Here's an article on their site about the topic:
A lot of SEs leave industries like semiconductors for web dev jobs that pay waay better
The components are much better. Batteries are better. Motors are better. Radio communications work. Cameras are cheap. Short-range LIDAR is affordable. Navigation systems work. Robotics work used to require using a lot of time building custom solutions for those problems. Now you can just order components.
Here's an idea I'd like to see revisited. Back in the 1980s, someone built a pair of small forklifts that operated as a team. These were little things, about half a meter cubed, with maybe 50cm of lift. Individually, they couldn't do much. But a pair working together could pick up and move a couch, with one robot lifting each end. In the 1980s, the researchers had trouble coordinating two mobile robots. Communications alone were a big problem. Not today.
There are many material handling tasks where one small robot isn't enough, and a big machine the size of a forklift is too bulky. But teams of small robots might work.
I still have a small robot arm on my desk, but it's not connected to anything.
Meh, maybe in a decade. ROS has no official support for it either. Robotics is still very much a C++ town and will probably remain as such for a long while as long as people remain stubbornly set in their ways. If you apply as a Rust only dev to a robotics company nobody will take you seriously.
Yes it can and we can.
Software has been a critical component of much progress we have made over the last few decades.
I understand the difficulty with the abstract many people have. Some may think Hilbert spaces are not real. For many they are as real as any space around them. Some live in them !
