4 ms·

Tangent this got me thinking about: Why are the robotics and embedded communities generally separate, with little overlap in people and tech? For example, this

Tangent this got me thinking about: Why are the robotics and embedded communities generally separate, with little overlap in people and tech? For example, this project seems unrelated to the rust embedded tooling. And the components categories are also unfamiliar, e.g. the IMUs and ADCs in the readme, using a SBC vice a MCU etc. Another angle: `ROS` and `RTOS` share letters, but not much else! I gather that robotics is a fusion of embedded and mechanical engineering; I refer to the former.

gbin 2y ago
It almost feels like we would need an "in between" category. If I paint a broad brush: - embedded is all about latency, low bandwidth - computers are all about bandwidth with often terrible latencies. A modern robot needs both low latency and high bandwidth.
- the__alchemist 2y ago
  I suppose this lends itself to a hybrid scenario. I suspect most mature robotics projects would have both types of computation. Likely bare metal or RTOS as the default, with delegation to GPOS computer for high bandwidth, and high computation tasks such as CV. I also imagine distributed computing (for example: over CAN or another bus) would be a useful pattern.
ModernMech 2y ago
Typically with robots you need more power than what embedded provides. We build on top of commodity x86 systems a lot of the time. Other times we use SOCs like the Nvidia Jetson line, which also doesn't require a lot of embedded skills; you get a full operating system and a userspace so it's more like programming on a typical unix-based system. You find more embedded in the automation side of things. Wearables, IOT, always connected devices -- things that are too small and low powered to afford an OS.
- AlotOfReading 2y ago
  There's a lot of embedded skills in pretty much any hardware platform. Maybe this is selection bias from being an embedded-focused person in robotics, but there's plenty of jobs out there that need a toolchain wrangler who can deal with cost optimization.
  - ModernMech 2y ago
    I'm not saying skills you pick up doing embedded work aren't useful in robotics contexts. I'm saying roboticists often have the luxury of an OS, and they take advantage of it, so the worries you have doing embedded work without an OS are mitigated. I would say tho there are different "kinds" of roboticists. Just as you have backend and frontend devs in the web world, you might consider people who work on hardware or software to be the robotics equivalent. Hardware people are going to be low level and working with embedded devices and may even program them. But higher up in the robotics stack most of that embedded know-how (toolchain wrangling as you put it) is much less important. The full stack robotics engineer has hardware and software knowledge/experience, but you don't usually see roles that ask for both, so people tend to specialize into one or the other.
    - a_t48 2y ago
      OTOH the OS can very much get in the way. If you're using ROS for instance, it's easy to fall into apt package dependency hell - upgrading CUDA means upgrading the OS, which means upgrading ROS, which means upgrading all deps including OpenCV, etc, etc, etc.
      - exe34 2y ago
        that's the part I hate about ros and a whole lot of other libraries that shouldn't have been so tightly coupled - you should be able to run most of ros in one env and then for the performance critical or hardware facing stuff, run them each in their own env and have lightweight communication between them. I think if something annoys me enough I'll end up using nanomsg or mqtt as a bridge, but it's a pain.

gbin 2y ago

It almost feels like we would need an "in between" category. If I paint a broad brush: - embedded is all about latency, low bandwidth - computers are all about bandwidth with often terrible latencies. A modern robot needs both low latency and high bandwidth.

the__alchemist 2y ago
I suppose this lends itself to a hybrid scenario. I suspect most mature robotics projects would have both types of computation. Likely bare metal or RTOS as the default, with delegation to GPOS computer for high bandwidth, and high computation tasks such as CV. I also imagine distributed computing (for example: over CAN or another bus) would be a useful pattern.

ModernMech 2y ago

Typically with robots you need more power than what embedded provides. We build on top of commodity x86 systems a lot of the time. Other times we use SOCs like the Nvidia Jetson line, which also doesn't require a lot of embedded skills; you get a full operating system and a userspace so it's more like programming on a typical unix-based system. You find more embedded in the automation side of things. Wearables, IOT, always connected devices -- things that are too small and low powered to afford an OS.

AlotOfReading 2y ago
There's a lot of embedded skills in pretty much any hardware platform. Maybe this is selection bias from being an embedded-focused person in robotics, but there's plenty of jobs out there that need a toolchain wrangler who can deal with cost optimization.
- ModernMech 2y ago
  I'm not saying skills you pick up doing embedded work aren't useful in robotics contexts. I'm saying roboticists often have the luxury of an OS, and they take advantage of it, so the worries you have doing embedded work without an OS are mitigated. I would say tho there are different "kinds" of roboticists. Just as you have backend and frontend devs in the web world, you might consider people who work on hardware or software to be the robotics equivalent. Hardware people are going to be low level and working with embedded devices and may even program them. But higher up in the robotics stack most of that embedded know-how (toolchain wrangling as you put it) is much less important. The full stack robotics engineer has hardware and software knowledge/experience, but you don't usually see roles that ask for both, so people tend to specialize into one or the other.
  - a_t48 2y ago
    OTOH the OS can very much get in the way. If you're using ROS for instance, it's easy to fall into apt package dependency hell - upgrading CUDA means upgrading the OS, which means upgrading ROS, which means upgrading all deps including OpenCV, etc, etc, etc.
    - exe34 2y ago
      that's the part I hate about ros and a whole lot of other libraries that shouldn't have been so tightly coupled - you should be able to run most of ros in one env and then for the performance critical or hardware facing stuff, run them each in their own env and have lightweight communication between them. I think if something annoys me enough I'll end up using nanomsg or mqtt as a bridge, but it's a pain.