Industrial robot arm motor control loop? 1000Hz, single-threaded, dedicated CPU core or even an FPGA.
Robot vision system? 30Hz, tolerance for occasional dropped frames, and some lower priority tasks like saving audit images which are nice to have but not critical. A small monolith with several threads would be a fine choice.
Assigning robot-sorted widgets to customer orders? 1-5Hz, go ahead and use the web coding practices where 200ms is considered a fast response time.
All of these are serious robotics - but they could reasonably be coded in very different ways.
Sure it does. I've seen teams of >100 engineers working on largely monolithic robotic codebases across several teams/companies (volumes in the 10s of thousands).
Beyond that, robotics isn't all that special. There are other domains which have soft-realtime requirements and huge scale. AAA video games are a multi-$100-billion industry, which largely ship single-process systems with extreme performance on par with state-of-the-art perception and motion planning use-cases.
It'll be interesting to see how/when wasm shows up in vr & robotics.
Being able to have some shared memory you pass around between safely sandboxed worklets still has any of the same coordination problems. But it at least has much much much less multiprocess jank.
It let's you safely run lots of different code in a single processs, without paying the context switching cost.
Quests's jank problem is probably in part that multiprocess architecture has to spawn new processes & change priorities of what's running & handle expensive context switches between processes elegantly, which is hard. Not only is non-monolithic code sometimes harder to reason about, it has all kinds of performance boundaries that are very painful to cut through.
Read through Pipewire changelogs & how they've worked so hard to make best use of kernel primitives with less and less overhead, look how hard they've worked to get near Jack levels of efficiency. Great example of the slow march of multi-process optimization.
Sandboxes let you collocate different processes inside the same process. You still have many of the same architectural challenges, but the ability to spawn new code & run it has much much lower overhead. It creates the possibility to make way more multi-process like architectures than we can explore now.
In robotics you generally don't want untrusted code anyways. It's much easier to a bad actor to do dangerous behaviour in the real world than breaking out of some sandbox. Kind of an analogue-hole situation.
And at that point why bother with an OS? What benefits are and OS providing then anyways? Just deploy with a unikernel.
I don't think that affects broadscale usefulness of Sandboxes at all. That regurgitates the idea that Sandboxes are security measures. That's a naively small use case.
Elsewhere in the threads here is a discussion of Nodelets, which are often used to load & run trusted code on ROS inside of host processes. This is like a jank special homebrew version of a sandbox, with - as other commenters point out - brings a lot of pain. With wasm you can quickly spin up many cheap fast sub-runtimes and connect them ad-nauseum, with the zero-copy benefits & more. http://wiki.ros.org/nodelet
That's really the key. Sandboxes are really about having many (typically different) runtimes in process. Often these will be processes working with processes. As I highlighted already extensively, the benefit is performance & overhead, versus native processes & native ipc. Sandboxes are just a known term for a runtime within the process, for a subprocess.
