from Hacker News

Show HN: Copper – Open-source robotics in Rust with deterministic log replay

by gbin on 12/3/24, 12:58 AM with 36 comments

  • by cpgxiii on 12/3/24, 4:02 AM

    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.

  • by the__alchemist on 12/3/24, 2:41 AM

    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.

  • by amacneil on 12/3/24, 2:36 AM

    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.

  • by cchance on 12/3/24, 3:01 AM

    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!

  • by leonheld on 12/3/24, 1:32 PM

    > 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.

  • by a_t48 on 12/3/24, 2:28 AM

    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.

  • by ericyd on 12/3/24, 2:23 PM

    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.

  • by rgovostes on 12/3/24, 4:47 AM

    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?

  • by pryelluw on 12/3/24, 2:33 AM

    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.