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.

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.

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.

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.

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.

My experience is that there's a major difference between "R&D project" mentality to mass production and big install bases. The embedded stuff really starts to leaking into everything during the latter once you start evaluating how much it'd cost to rewrite the high level stuff to fit cheaper hardware, or resolve the intermittent issues that big customer is complaining about.

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.

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.

Xenomai or rt extensions to linux, basically the rtlinux legacy, where the os is a low priority thread while your latency critical code runs bare metal or scheduled out of band

This is currently part of my $dayjob.