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.
If this pics up support for like a open-library of assorted components and people shared them it has a lot of potential especially if the sim env and replays continues to be improved. I love the idea and looks gerat!
> 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.
Nice release - deterministic replay isn't easy - I still need to go back and pull our implementation forward to match the new features in the core framework. I'm not sure if you've seen Basis, but we're somewhat "competing" in the same space. You're all in on Rust, we're C++ with bindings to other languages (eventually). I don't see this as a bad thing - more tools in the space is a win, eventually the industry will settle on something better than ROS.
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.
Do I understand that at each tick, every task outputs a single message, and can depend on the outputs of other tasks? I.e., nodes and topics are merged into tasks, executed in topological order?
Such a great two sentence intro to the project:
“ Copper is a user-friendly runtime engine for creating fast and reliable robots. Copper is to robots what a game engine is to games.”
Other projects should take notice.
[dead]
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.