This seems to suffer a bit from the same problem that affects a lot of "new" robotics frameworks: the beginnings are simple, and it's easy at that stage to think that everything else is over-complicated.

The comparison with ROS 2 is a bit questionable. Comparing a single-process-only (Copper) approach using shared memory with a multi-process system (ROS 2) using default DDS settings really isn't comparing the same thing. There are ways to make the ROS 2 system much faster if you're willing to be limited to similar constraints (single process with components, or local-system shared-memory transport) but most people don't because those constraints are very limiting in practical applications.

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.

It’s great to see more innovation in the robotics framework space, it’s sorely needed.

Deterministic log replay is a killer feature to have baked in from the start - many autonomous vehicle & robotics companies have invested years of effort to achieve that nirvana, while the most popular robotics framework today (ROS) makes it borderline impossible.

> Unlike a game engine we use a data oriented approach to minimize latency and maximize throughput.

Don't you mean "like"? I thought game engines were all about data oriented approach.

I know nothing about robotics.

Is deterministic log replay really a differentiating factor? My naive assumption would be that this is table stakes for pretty much any software.