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'm not trying to downplay that selling point at all. My experience with ROS 2 is limited but that aspect of it was miserable.
This is such a small nit, but landing at the docs page (https://docs.peppy.bot/) and seeing this splash is annoying to me. Just show the docs.
Also it would be nice if I could switch between Rust and Python examples and have all code panes respect that choice, rather than have to switch every pane to Rust.
You're using ROS2, so you have a problem. You want to add rust to fix it? Now you have 47 problems.
Although tbh, these days I'm questioning the utility. If I'm the one writing the robot code, then I care a lot about the ergonomics of the libraries or frameworks. But if LLMs are writing it, do I really care? That's a genuine, not rhetorical question. I suppose ergonomics still matter (and maybe matter even more) if I'm the one that has to check all the LLM code....
But I almost always feel like there is just so much STUFF involved in ros, that really is just better resolved by having really robust controllers, well defined protocols, and everything else.
I wait to pass judgement until I have more information though
The website claims “30hz polling rate”, “2ms latency”. Not sure if that is a best case or just for that demo.
But there are a lot of nodes and drivers out there for ROS already. It's a chicken and egg thing because people aren't going to write drivers unless there are enough users, and it's hard to get users without drivers.
It looks like their business model is to give away the OS and make money with FoxGlove-like tools. It's not a bad idea, but adoption will be an uphill battle. And since they aren't open source yet, I certainly wouldn't start using it on a project until it us.
Always looking for testers and feedback if you want to influence the design/API.
For some, packaging/deployment would also fall under the umbrella of a solved-by-ROS problem, however I don't think the Open Robotics supplied debs are suitable for most product deployments, for a variety of reasons that I've discussed in two separate ROSCon talks.
> Will PeppyOS be open source?
> Yes! PeppyOS will be fully open source under a BSL license before the end of this year. Once the software is mature, everyone will be able to contribute and participate in its development.
Would love to hear your thoughts.
* It is a dependency hell
* It is resource-heavy on embedded systems
* It is too slow for real-time, high speed control loops
* Huge chunks of it are maintained by hobbyists and far behind the state of the art (e.g. the entire navigation stack)
* As robotics moves toward end-to-end AI systems, stuff needs to stay on GPU memory, not shuttled back and forth across processes through a networking stack.
* Decentralized messaging was the wrong call. A bunch of nodes running on a robot doesn't need a decentralized infrastructure. This isn't Bitcoin. Robots talking to each other, maybe, but not pieces of code on the same robot.
| As robotics moves toward end-to-end AI systems, stuff needs to stay on GPU memory, not shuttled back and forth across processes through a networking stack.
NVIDIA actually is addressing this with NITROS: https://nvidia-isaac-ros.github.io/concepts/nitros/index.htm...
And ROS native buffers: https://discourse.openrobotics.org/t/update-on-ros-native-bu...
PeppyOS is a robotics framework that takes you from development to production at scale, letting you focus on building intelligent robots while we handle the complexity.
Build and deploy robot software with ease. PeppyOS streamlines your entire robot stack — sensors, actuators, AI, and controllers — making robotics development accessible even if you've never worked with robots before.
15 minutes to get productive • Fully free
Node: Brain
Input
{
// This is an AI brain that can plug to any hardware controller
schema_version: 1,
manifest: {
name: "robot_brain",
tag: "0.1.0",
language: "python"
},
process: {
add_cmd: ["uv", "sync"],
start_cmd: ["uv", "run", "src/main.py"]
},
parameters: {},
interfaces: {
exposes: {},
subscribes_to: {
// The brain receives inputs from sensors
topics: [
{
id: "camera_stream",
node: "uvc_camera",
name: "video_stream",
tag: "0.1.0",
},
{
id: "lidar_sensor",
node: "rplidar",
name: "scan",
tag: "0.1.0",
},
],
// And emit actions to the controller
actions: [
{
id: "move_right_arm_action",
node: "openarm01_controller",
name: "move_right_arm",
tag: "0.1.0",
},
{
id: "move_left_arm_action",
node: "openarm01_controller",
name: "move_left_arm",
tag: "0.1.0",
}
]
},
}
}
{
// This is an AI brain that can plug to any hardware controller
schema_version: 1,
manifest: {
name: "robot_brain",
tag: "0.1.0",
language: "python"
},
process: {
add_cmd: ["uv", "sync"],
start_cmd: ["uv", "run", "src/main.py"]
},
parameters: {},
interfaces: {
exposes: {},
subscribes_to: {
// The brain receives inputs from sensors
topics: [
{
id: "camera_stream",
node: "uvc_camera",
name: "video_stream",
tag: "0.1.0",
},
{
id: "lidar_sensor",
node: "rplidar",
name: "scan",
tag: "0.1.0",
},
],
// And emit actions to the controller
actions: [
{
id: "move_right_arm_action",
node: "openarm01_controller",
name: "move_right_arm",
tag: "0.1.0",
},
{
id: "move_left_arm_action",
node: "openarm01_controller",
name: "move_left_arm",
tag: "0.1.0",
}
]
},
}
}
Output nodes
camera lidar robot brain hardware controller servo id 1 servo id 2
Your robot stack
Define your robot stack as modular nodes — cameras, lidar, AI brains, and servo controllers — connected through a simple configuration file.
Deploy robot software that scales from a single prototype to a fleet of robots. PeppyOS handles orchestration, monitoring, and updates.
Write robot nodes in Python or Rust. PeppyOS connects them seamlessly with low-latency inter-process communication.
PeppyOS is written in Rust for maximum throughput and minimal resource usage. Run more nodes on less hardware without sacrificing reliability.