Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting into robotics as a software engineer

bou.ke

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Getting into robotics as a software engineer

#91

Post by richrichie »

AnarchismIsCool wrote: post #55
richrichie wrote: post #21

“ An app is not going to house people, feed them or put them on Mars. We can’t solve climate change with smarter software” 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…

Ad-tech isn't feeding the poor or curing cancer, it's just giving everyone depression.

[dead]

Re: Getting into robotics as a software engineer

#92

Post by GianFabien »

calamari4065 wrote: post #74
JoeCortopassi wrote: post #72

Earlier quoted context omitted.

To expand on this, if software was like hardware: - when your function calls don't have enough white space between them, they'll some times mix up their return value (crosstalk) - the more deeply your if/else statements are nested, the more random their results end up being (voltage/IR drop) - when the user makes a selection, your bound function is called somewhere between once and a dozen times. Each time with a dif…

If you want your program to execute as fast as possible, you have to worry about the speed of light! A trace a few millimeters longer than its partner can have nanoseconds of delay which can easily corrupt your data! And don't forget that you have to balance the physical shape and arrangement of components and traces with frequency and surrounding components otherwise you've created a transmitter spewing out noise at…

Not so fast, some alpha particles from a distant galaxy strike your memory chips and some bits flip. If the CPU gets too hot or too cold it starts misinterpreting opcodes, branches, etc.

The reality is that computers are comprised of several PCBs running with thousands of multi-GHz signals. So all of the foregoing engineering design principles had to be observed to make our systems as reliable as they are.

Re: Getting into robotics as a software engineer

#93

Post by GianFabien »

shafyy wrote: post #6
eschneider wrote: post #2

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…

What can you recommend to start experimenting at home with robotics? Raspberry Pi?

No, no - I have a half a dozen RPi's of varying revisions. Since they run Linux and the SDcards are less than robust, anytime you accidentially trip the power (which to me happens several times during hardware debugging sessions) you risk scrambling the rootfs and thus need to reflash a new SDcard. Some SDcards get damaged.

I recommend using Arduino and/or Wokwi (https://wokwi.com/) to get started.

Re: Getting into robotics as a software engineer

#94

Post by brailsafe »

fake-name wrote: post #11
msadowski wrote: post #7

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.…

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 basic…

I'd go one step further and say that Agile might as well be tossed away entirely since it's common enough for companies to treat it like waterfall anyway, making the practice of many small iterations or iteration at all unwelcome. If your software team embraces iteration and incremental improvement, any presence of agile is probably redundant; if they aren't, or the nature of the work doesn't facilitate it, then Agile gets in the way regardless of the domain.

Re: Getting into robotics as a software engineer

#95

Post by iamcreasy »

AnarchismIsCool wrote: post #56

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 de…

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?

Re: Getting into robotics as a software engineer

#96

Post by c_o_n_v_e_x »

calamari4065 wrote: post #66
nostrademons wrote: post #62

Earlier quoted context omitted.

I wonder (as someone who's basically always been in the pure software land) if the way to get around this is to overbuild your hardware prototype . Throw on more sensors, actuators, and motors than you actually need, and parameterize the physical properties of the hardware (like mass, power, and center of gravity). Then do your iterations in software. You can always ignore a signal coming from a sensor, but it takes…

It's unfortunately not that simple. For most parts you can get breakout boards or dev kits that implement the chip and all its support circuitry. You can drop those into a simple PCB or just a breadboard and get going pretty quick. This is appallingly expensive for more than a handful of prototypes, but it does work. IME, this is how software people approach electronics. The real trouble comes during the next step. Y…

I came here to say what you just did. Hardware modularity is incredibly useful in the face of unstable product requirements. Focusing on integration, optimizing form factor can come once the requirements are locked in (if such a condition ever exists lol).

Re: Getting into robotics as a software engineer

#97

Post by AnarchismIsCool »

iamcreasy wrote: post #95
AnarchismIsCool wrote: post #56

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 de…

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?

https://www.st.com/resource/en/programming_manual/pm0214-stm...

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.

Re: Getting into robotics as a software engineer

#98

Post by FirmwareBurner »

gregwebs wrote: post #85
fake-name wrote: post #11

Earlier quoted context omitted.

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 basic…

When hardware design can be software emulated then iteration can be more agile. There's a story how NVIDIA was the first one to do this for GPUs- this was done out of desperation because they were out of money and had to ship quickly. They didn't have time and money to do any revisions so they just shipped what they had done in software emulation even though some of the features were defective. https://www.acquired.f…

Absolutely all chip designs get software emulated/simulated for rigorous testing before being sent to the fab for production.

It seems like the publication turned what is industry standard into a sensationalistic article.

The only thing Nvidia did different was rolling directly to tapeout with their simulated design without any intermediate prototypes which was indeed a risky move but not unheard of for cash strapped semi startups.

Re: Getting into robotics as a software engineer

#99

Post by FirmwareBurner »

Animats wrote: post #81
eschneider wrote: post #2

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…

Yes. 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.

>The number of people who both know C++ (not C) and how to use an oscilloscope is surprisingly small.

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.

Re: Getting into robotics as a software engineer

#100

Post by blah-yeah »

Make magazine has a great magazine on getting into robotics via the Battle Bots type of robots.

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/

Post reply on HN