Hey uh - good luck. I spent a while smashing my head against this.
You should read https://basisrobotics.tech/2025/01/08/postmortem/ and consider:
- How you will get users
- How you will fund development
- What the "good parts" from ROS and other frameworks you want to take
I notice you don't have shared memory transport, nor do you support runtime composability (I think?). This might make perception heavy stacks run poorly. I'm also a little confused on what serialization format you support - is it an entirely custom one? It looks like two publishers with the same topic type will duplicate the schema, which is a bit odd. Worth also considering how you will do recording/replay.
Additionally - BSL feels great, but I found it scared off some people. IMO just do Apache 2.0 if you're going to have some other revenue stream anyhow.
I spent like...a year thinking about this stuff, happy to chat at kyle@basisrobotics.tech if you need a friendly ear.
I was sad to see you guys shut down - I think you were on to something with deterministic faster-than-realtime replay. Not surprised it was hard to find paying customers, but for what it's worth, my engineering self thought that you guys were solving the right problem. As far as I can tell, it's still not solved, and the shocking truth is that everyone is just Living That Way.
The other thing that is important is how to provide a more query-like interface to tease out the data you actually want your node to react to, yet in a way that will be deterministic. You need to guide users away from introducing non-determinism, which can be tricky because innocent things like a message buffer with a max size can lead to such situations.
I have talked with one of the key people at Xronos (https://www.xronos.com/), who are trying to attack related problems. Still, even they aren't quite as pre-occupied with _replay_, which is crucial.
I think the sad truth is that the second evolution of all this frameworking simply hasn't come together convincingly enough, and in one place, for it to gather momentum. It turned out to be hard. And now that it has taken too long, it's my bet that ROS2 and all of its imitators will get lapped by holistic deep approaches. Not the stupid stuff happening with these fake humanoid robot companies mind you, but still - something holistic and deep. Something coming out of the predictive coding research e.g., or world models, etc. Training in simulated environments with generative systems is going to lead to behavior so much more sophisticated than gluing together all of our little services. Roboticists have their own version of the bitter lesson coming soon.
I was sad, too. If there was a way I thought to continue doing it, I would. But as it is I'm actually considering getting out of robotics at this point, I've had enough of everyone "Living That Way".
Hey,
too bad you've shut down, looked like a great project.
> I notice you don't have shared memory transport, nor do you support runtime composability (I think?)
We're using Zenoh in the backend, we didn't try to reinvent the wheel on that front.
> I'm also a little confused on what serialization format you support - is it an entirely custom one?
It's cap'n proto, but abstracted away for the user so he doesn't have to think about it.
> BSL feels great, but I found it scared off some people
Agreed, but we're building a SaaS in parallel, PeppyOS will be 100% free and open source but we don't want another company to build a SaaS on top of it, that will be the only restriction of the BSL license, otherwise it's the same as Apache 2.0.
I’ve seen images that accidentally install tensorflow twice, too. It wouldn’t be so bad if large files were shared between layers but they aren’t. It’s bad enough that I’m building an alternative registry and snapshotter with file level dedupe to deal with it.
Sounds like it would be useful. Many common dev workflows started falling apart when it's not just tiny code files they need to deal with. In the python world, uv has helped massively, with pip we were seeing 30+ min build times on fairly simple images with torch
The other issue is that it's not like they can go back and run this deduplication after the fact. Image layers are stored as a single gzipped tar of the contents on the layer. You can't just pull a single file out of that. If you go and reorganize as multiple gzip streams, you'll change the digest of the layer. A new registry could do that reorganization on import (and return the digest), or provide tooling to build the layers in the right format to begin with.
I'm well aware of `COPY --link`, it doesn't solve the problem. I'm a heavy heavy user of it, combined with throwaway build stages. `COPY --link` won't help my `apt install` commands.
The use case here isn't `FROM python:3.10`, it's `FROM ubuntu; RUN apt install -y vim wget curl software-properties-common python3.10`/`RUN rosdep install`/`RUN --mount=type=cache,target=/root/.cache/uv --mount=type=bind,source=uv.lock,target=uv.lock --mount=type=bind,source=pyproject.toml,target=pyproject.toml uv sync --locked --no-install-project`. All of those dependencies get merged onto a single layer that isn't shared with anything else. You'd better hope something like tensorflow isn't one of those dependencies.
Meta: I think your example code would benefit from being a code block; in HN this is done by prefixing with 2 spaces.
eg.
FROM ubuntu
RUN apt install -y vim wget curl software-properties-common python3.10
RUN rosdep install
RUN --mount=type=cache,target=/root/.cache/uv --mount=type=bind,source=uv.lock,target=uv.lock --mount=type=bind,source=pyproject.toml,target=pyproject.toml uv sync --locked --no-install-project
reply