Some concepts that you'll need to get familiar with:
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.
Ah, I remember Casey Muratori speaking having desktop OS where everything is memory mapped.
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?
My journey is a little bit opposite to the author’s: I studied robotics and started learning programming by myself to create software for robots. There are two observations I have that can be useful to people making the software->robotics journey.
* 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.
I'd go one further and say that basically agile in hardware is fundamentally impossible in any way people commonly use agile.
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.
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:
Some trig and geometry is definitely useful—but it's quite limited to be honest. For most things you can use existing algebra libraries and for most things someone else has figured it out before!
Nice article. As someone who's also gotten into robotics from the software side, I'd also suggest learning a bit about the hardware side. If you're doing anything with custom boards and board bring-up, you'll need to be able to read a schematic and data sheet at a basic level. Being able to use an oscilloscope and logic analyzer is also _very_ useful. None of this stuff is terribly hard, but it's nice to know what to expect.
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.
I often feel the same urge to work on soft/hard stuff. Not sure why I don't actually do it. Although the current stuff I work on is very cool on its own and not Candy Crush. But it's really a scourge on this world that the top tier pay in the industry is to shove ads in front of people.
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.
If you have a team nearby, go work with a FIRST Robotics Competition team as a mentor/volunteer. Great community, you'll learn a lot, and make great connections if you want to get into this area as a career.
The article itself was a bit too holier-than-thou for me but I want more robotics content here on HN so let's hijack this thread and share robotics passion!!
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
Really wish the author would have commented on salary. I personally think the reason more people don't end up on the hardware/robotics side is that the questionable-value fintech/adtech/socialtech pure software side of the world pays so much better and most developers follow the money.
Robotics is very niche and the market is dominated by early stage startups (since most of them go out of business a few years in), so salaries are average unless you are working specific jobs for FAANG. Job hoping usually means moving elsewhere, since working close to the hardware makes it much easier, which in turn means having a good picture of what is a competitive salary sometimes is not obvious.
Definitely agree here. I have been making this transition and currently work on life science lab automation robotics. It definitely takes intentionality because if you're good at software it's easy to get steered towards lucrative but higher level places in the stack.
What is questionable-value? People pay for questionable things, that brings value to them, though that value is questionable? Do not get it. Though i understand the personal resentment.
I've occasionally thought it would be fun (not necessarily productive!) to do something like the experiments folks have done with Genetic Algorithms, having simulated robots learn to walk, etc. in a simulated physics environment. The interesting bit would be to do it with real legs, sensors, servos, etc., to try to build up a "naive physics" library that can deal with balance, etc., by learning from physical experience rather than starting with equations of motion.
That may be the most number of times I've typed "etc." in a paragraph.
I remember articles about a competition DARPA had to this effect, using an off-the-shelf simulator (maybe Bullet?). At first, the simulated robots learned to hack the sim. Some did a vibration thing that messed with the friction model, sort of like a vibrating cell phone moving across a table. Others learned to hack collision detection/response, doing a sort of jump / pole-vault thing that would explosively hurl them forward. I assume they later tweaked the sim and the rewards until they actually got the walking behaviors they wanted.
My university had a program that did this, I took it as a sophomore years ago while I was studying "evolutionary robotics", although typically we would simulate the robot in 3D virtual environment to test the reward mechanism for learning to walk.
System Identification is a fairly common strategy for developing a controller. Essentially, you learn the dynamics model from recorded data, and then use that as a simulator to iteratively improve the controller. The devil is in the details though, as you can run into issues with simulation fidelity (due to missing data), which can produce something that doesn't translate to real life performance.
I'm just getting into robotics with a background in software and I ended up choosing the Isaac Sim platform/ecosystem (https://docs.omniverse.nvidia.com/isaacsim/latest/index.html) and Jetbot (https://jetbot.org/master/) since they seem suited for neural networks and reinforcement learning. So far getting up and running with the simulation side hasn't been too bad and there is a model for the Jetbot in Isaac Sim since it's also by Nvidia. I haven't started on the hardware side so can't speak on that. The downside for some might be it's proprietary and Jetbot itself is a bit out of date and nearing end of life support.
You'll be better served with a more capable platform. You can either 3d print it, or you can pick up something like the WaveRover from Waveshare. It's a solid metal frame with geared motors and differential drive. For ~$100 you won't get much better.
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.
This is completely unrelated to the article the OP posted other than it's also related to robotics. But it's the coolest robot project I found recently. And since readers of this thread are likely to be interested in robotics (I am!), it might of interest to some:
What would be a good starting platform for a programmable drone?
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?
As someone who works in making physical things, I disagree with the premise that the world of bits and bytes does not have impact. We will always need to manage resources including humans at a large scale and web apps are the best way to do that.
The best way to get into it without investing money in all that hardware is to play with a simulator. My preference is CoppeliaSim - due to it's user friendliness.
As long as software folks don’t bring their shenanigans (agile/scum (ahmm scrum) approach, daily stand up, ticket based management, ship products within 2 weeks, among others) into the robotics/engineering world, you are welcome. I have seen many cases of software “project or engineering managers” ruin a whole department because they were trying to force such stupid approaches, it’s always ironic seeing some are trying to force agile for example even though the whole idea of agile is being..agile.
This might be a good time to get into robotics. For a long time, industrial robots were really dumb. Then there was a round of false enthusiasm for "intelligent robots" (Rethink Robotics went down that rathole.) Now, at last, compute power, vision, and AI are cheap enough that you can get something done.
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.
> Also, if you’re not already, you should get into writing Rust. The powerful type system and safety is incredible. The build tooling and ecosystem is much better than C++ et al. Rust for embedded is not there yet, but improving all the time.
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.
[+] [-] AnarchismIsCool|2 years ago|reply
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.
[+] [-] iamcreasy|2 years ago|reply
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?
[+] [-] msadowski|2 years ago|reply
* 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.
[+] [-] fake-name|2 years ago|reply
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.
[+] [-] bemusedthrow75|2 years ago|reply
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
https://www.makershed.com/products/make-calculus-print
https://www.makershed.com/products/make-geometry
[+] [-] bouk|2 years ago|reply
[+] [-] dartos|2 years ago|reply
[+] [-] eschneider|2 years ago|reply
[+] [-] Animats|2 years ago|reply
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.
[+] [-] shafyy|2 years ago|reply
[+] [-] AYBABTME|2 years ago|reply
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.
[+] [-] bemusedthrow75|2 years ago|reply
This cannot be said enough, IMO. The web software world's endless quest for the shallow and lucrative is exhausting.
[+] [-] NordSteve|2 years ago|reply
[+] [-] bouk|2 years ago|reply
[+] [-] kaycebasques|2 years ago|reply
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
[+] [-] mdorazio|2 years ago|reply
[+] [-] DoctorDabadedoo|2 years ago|reply
source: I work in robotics. AMA.
[+] [-] edge17|2 years ago|reply
[+] [-] okr|2 years ago|reply
[+] [-] bouk|2 years ago|reply
[+] [-] chris_st|2 years ago|reply
That may be the most number of times I've typed "etc." in a paragraph.
[+] [-] mdorazio|2 years ago|reply
[+] [-] FooBarBizBazz|2 years ago|reply
[+] [-] imtringued|2 years ago|reply
[+] [-] Avicebron|2 years ago|reply
[+] [-] coderenegade|2 years ago|reply
[+] [-] flutas|2 years ago|reply
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.
[+] [-] ih|2 years ago|reply
[+] [-] m00x|2 years ago|reply
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.
[+] [-] manuel_w|2 years ago|reply
https://www.allesblinkt.com/projects/round-about-four-dimens...
Hope this is not considered too off-topic here.
[+] [-] kaycebasques|2 years ago|reply
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
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] andrew_eu|2 years ago|reply
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?
[+] [-] kaycebasques|2 years ago|reply
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
[+] [-] jacquesm|2 years ago|reply
[+] [-] lijaf|2 years ago|reply
[+] [-] xrd|2 years ago|reply
[+] [-] tonmoy|2 years ago|reply
[+] [-] choonway|2 years ago|reply
https://www.coppeliarobotics.com/
But take your pick there are many to choose from.
https://www.sciencedirect.com/science/article/abs/pii/S15691...
[+] [-] blah-yeah|2 years ago|reply
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:
https://makezine.com/tag/battlebots/
[+] [-] ashconnor|2 years ago|reply
https://en.wikipedia.org/wiki/Robot_Wars_(TV_series)
[+] [-] tamimio|2 years ago|reply
[+] [-] tester756|2 years ago|reply
A lot of SEs leave industries like semiconductors for web dev jobs that pay waay better
[+] [-] Animats|2 years ago|reply
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.
[+] [-] moffkalast|2 years ago|reply
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.
[+] [-] hcks|2 years ago|reply