4 ms·

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 anythi

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.

Animats 3y ago
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.
- FirmwareBurner 3y ago
  >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.
shafyy 3y ago
What can you recommend to start experimenting at home with robotics? Raspberry Pi?
- GianFabien 3y ago
  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/ https://wokwi.com/) to get started.
- Galanwe 3y ago
  I guess that depends on your software background. If C/C++ is not a problem, I would recommend Arduino. I found it simpler to just upload your program as the sole brain of your MCU, rather than working with a Raspberry Pi with Linux and all the abstractions, devices, etc that goes with it.
  - jacquesm 3y ago
    Raspberry Pi will work with the Arduino environment as well.
  - sokoloff 3y ago
    I’d recommend starting with this as well. The setup() and loop() model gets you started quickly and can take you through a lot of small projects before you want timers or other advanced features. Plenty of tutorials and libraries (often “working but not high-quality”) are available as well. Even if c/c++ scares you a little, I’d still start there (I came from a long c/c++ background, but I’ve seen my kids be able to do it with not nearly as much help as I expected to give them). Dirt cheap and readily available as well. Clones are fine; you don’t need the name brand Arduino boards.
- deleted 3y ago
  [deleted]
- 3y ago

Animats 3y ago

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.

FirmwareBurner 3y ago
>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.

shafyy 3y ago

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

GianFabien 3y ago
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/ https://wokwi.com/) to get started.
Galanwe 3y ago
I guess that depends on your software background. If C/C++ is not a problem, I would recommend Arduino. I found it simpler to just upload your program as the sole brain of your MCU, rather than working with a Raspberry Pi with Linux and all the abstractions, devices, etc that goes with it.
- jacquesm 3y ago
  Raspberry Pi will work with the Arduino environment as well.
- sokoloff 3y ago
  I’d recommend starting with this as well. The setup() and loop() model gets you started quickly and can take you through a lot of small projects before you want timers or other advanced features. Plenty of tutorials and libraries (often “working but not high-quality”) are available as well. Even if c/c++ scares you a little, I’d still start there (I came from a long c/c++ background, but I’ve seen my kids be able to do it with not nearly as much help as I expected to give them). Dirt cheap and readily available as well. Clones are fine; you don’t need the name brand Arduino boards.
deleted 3y ago
[deleted]
3y ago