Not an RTOS as is commonly understood but RTIC is nice. I think originally developed for robotics.

https://rtic.rs

I think people who are serious about it run QNX or VxWorks. Most robotics projects aren't serious and run Ubuntu unfortunately.

I don't think you're familiar with modern robotics.

The central control plane is Ubuntu, but the boards for actuators and sensors are all microcontrollers on some kind of RTOS or FPGAs.

Not being familiar with the field, what counts as modern robotics?

Performing a quick survey of available recent papers in the field, came back with these summary works:

Robotics and Industry 4.0, https://www.researchgate.net/profile/Sudeep-Tanwar/publicati...

Elements of Robotics (book), https://library.oapen.org/bitstream/handle/20.500.12657/2782...

Modern Robotics (limited pages), https://www.google.com/books/edition/Modern_Robotics/5NzFDgA...

Looks like:

  - Industrial for heavy lifting and dangerous tasks beyond human standards (welding, heat, radiation)
  - Autonomous vehicles for manufacturing, mining, agriculture, logistics, transport
  - Quad- and octa- rotors as well as swarms of such (similar tasks as autonomous vehicles)
  - Health care with repetitive chemical mixing where human error can make a dangerous batch
  - Food packaging for sanitation and highly repetitive tasks prone to error, stress, and accidents.
  - Mining for areas where human interaction is dangerous or prohibitive (depth)
  - Military for attacks, surveillance, EM warfare, and long term loitering / denial.
  - Supermarkets and malls for restocking, cleaning, and shopping assistance.
  - Warehouses and factories for moving and selecting parts
  - Toys and educational consumer purchases
  - Home cleaning and maintenance (most of what "robot" brings back on shopping, other than toys)
  - Automated cooking for condition specific foods (rice, difficult indian meals)

I'm not sure what you're asking here. This just looks like a chatgpt dump.

Can confirm. $DAYJOB makes robots subject to hard worst-case latency constraints. The product runs on QNX.

"x86" and "RTOS" don't really work together, given SMM, complex caches, and so on. If you have any sort of high-performance task, you'll likely want to have an separate embedded MCU (or a dozen of them) to control it.

And embedded stuff has a ton of OS'es, such as FreeRTOS, Zephyr, ThreadX... And there are plenty of proprietary solutions, like Nvidia DriveOS.

The embedded OSes are quite limited compared to regular ones like Linux - the task scheduler is present, but everything else (like processes, filesystem, dynamic file loading, binary tools, etc...) is either missing or optional.

I am aware that FreeRTOS and Zephyr are popular but in your opinion, do these form a comprehensive ecosystem and foundation for engineers build robots? I am not aware of any major robotics projects using these MCU OSes as a paradigm (as opposed to an auxiliary component connected to a main OS). I had a robotics colleague at a high profile lab saying that Windows is the de facto standard.

I mostly work with mobile robotics, and using Windows sounds like an absolute craziness to me. The main PC runs some sort of Linux, often with disk in read-only mode.

I've heard this is not the case in all industries, and that many industrial projects (as in factory automation) use Windows, however crazy it may sound. But I don't have a first-hand knowledge of this.

All software I've worked with was built from scratch. We've used plenty of libraries, but this was all generic stuff, all the "comprehensive ecosystem and foundation" was our own. But compared to the actual business logic, that foundation is pretty simple - you need math libraries, some sort of RPC, logging, process management, replay/sim. This does not include device drivers - there is a very good chance you'll need to write them scratch anyway. And none of this is even close in complexity to things like path optimizer.

Thanks for your detailed response. Your observations match my own as well. I do think that the foundation is more complex than your quick comment suggests though (kudos to your team and its foundational work for making it seem trivial. that's exactly what a good framework should do.)