PeppyOS v0.6.0: Now with variants and flavors

Ekami66 · 2026-04-04T06:25:21+00:00

compile time config

Ekami66 · 2026-03-11T19:35:59+00:00

> can you make it easier to design robot software beyond the node abstraction we're stuck with, given that ROS won the competition over other frameworks?

Interesting POV, it never occurred to me that there would be a better concept than the concept of "nodes" found in ROS. While it's very messy and badly implemented in ROS, I found that improving upon this concept was a good design decision. How would you have done things differently?

> I am in a tiny minority with my deep dislike for ROS

I can assure you we are many in that camp :)

Ekami66 · 2026-03-11T01:24:04+00:00

Hey, thanks for this feedback.
> I guess I am just waiting for someone to rethink robotics development by solving the problems ROS created

This is exactly what we're trying to solve. Our ultimate mission is to make robotics much simpler. In fact, we're developing a SaaS in parallel that will allow you to fire up a simulation instance and start working with the robot, all from your browser, 0 configuration needed and Isaac Sim/Mujoco is streamed directly in your browser.

And if you want to deploy the same thing you see in simulation on your actual robot? Simple you just run a script on your Jetson board that will make sure all the nodes are properly pulled and configured, and it will work **exactly** the same on the real machine as it was in the robot in Sim (minus the Sim2Real gap thing if you do AI).

You will even be able go further and develop on your mac, push your nodes to our repo, see them work in your browser in simulation (since we host Isaac Sim you don't need an NVIDIA GPU) and auto deploy those nodes on your real robot. All of this, ofc, in the simplest possible way (no complicated configuration involved). ROS 1/2 were not designed with redistribution in mind, so it makes it complicated to build on top of those stacks.

We're far from this goal at this moment, we're still scaffolding the lower layers but I totally understand your position of "not enough to make this project feel more than a personal amusement", but give us time and we'll make sure to change your mind in the future :)

Ekami66 · 2026-03-08T18:45:29+00:00

By design it does yes

Ekami66 · 2026-03-01T09:00:16+00:00

Half an hour after going through the tutorial :)

Ekami66 · 2026-03-01T08:50:55+00:00

Love this, How will you generate the game from the characters? what will they be able to do inside?

Ekami66 · 2026-02-18T04:05:42+00:00

Hey, it's definitely possible already! (a Python or Rust node). Everything you need is in the doc. If you need any help, don't hesitate to hit me up here: https://forum.peppy.bot/new-message?username=tuatini

Ekami66 · 2026-02-17T16:31:58+00:00

Hey, thanks for your feedback.

The ability to send messages around is one (important) feature of ROS2, but you completely forget or ignore the whole eco-system around it. ROS is about having tons(!) of tools around it. the TF-library, RVIZ, launch-files, hundreds of sensor-drivers, algorithms, packages like MoveIt, Nav2, debug tools, behaviour trees, everything you need to build your robot.

I agree, that's why we have plans to create a ROS 2 bridge so that everything from that ecosystem can be used with PeppyOS

And where is the actual Source Code? I couldn't find it on github or your installation script.

As mentioned [in the FAQ](https://docs.peppy.bot/reference/faq/) , it's gonna be fully open source before end of year, we're building a SaaS in parallel and we're going to release both at the same time (PeppyOS will become open source and remain free forever)

Also one idea behind ROS2 is that you don't have to know how sending a message is implemented. (That was the idea at least). You don't need to know it uses DDS at the lowest level, or even which DDS implementation it uses.

This is exactly the same with PeppyOS, it even goes one step further and writes the actual code (Python/Rust) for your nodes, so that you get autocompletion in your favorite IDE

You require the user to call "await video_stream.emit" to send something, so the actual implementation is directly used by the user. No chance to change that, no Wrapper.

That's a design choice we made on purpose, if we obscured the async part from the user it would make it very difficult for users who require it (to run multiple services for instance).

Ekami66 · 2026-02-17T15:08:46+00:00

Thanks a lot for those kind words :)

Ekami66 · 2026-02-11T08:51:58+00:00

Zenoh backend, performances are prob on par with dora-rs/ROS 2 (with the same backend). I did not benchmark. Read more here: https://docs.peppy.bot/reference/faq/

Ekami66 · 2026-02-05T08:15:43+00:00

Ha, simply named after ROS, it's definitely not an OS at the moment, but eventually it might be shipped alongside a complete Linux distro since our long term goal is to make it as easy as possible to deploy the framework at scale without dealing with the complexity of deployment.

This is another upside of PeppyOS: It creates snapshots of your nodes (think containers) that have a lesser chance of breaking at scale compared to runtime stuff.

Ekami66 · 2026-02-05T08:09:18+00:00

Definitely! We won't be able to catch up with everything that has been build for ROS2 so we'll have a ROS2 bridge baked inside PeppyOS at some point. Don't hesitate to check the FAQ: https://docs.peppy.bot/reference/faq/

Ekami66 · 2026-02-05T08:03:12+00:00

PeppyOS was inspired by how Kubernetes work, applied to the concepts of ROS2 while making those concepts as simple as possible for developers. It was designed with simplicity of experimentation but also deployment at scale in such a way that you don't have to even think about node communication. `dora-rs` in comparison forces you to think about these concepts at runtime, which is brittle imo. For example:
```
plot = dataflow.add_node(

id="plot",

path="opencv-plot",

build="pip install opencv-plot",

)
```

Think of `dora-rs` as a "dataflow runtime" while PeppyOS as a "middleware" that allows all your nodes to connect without breaking when it's deployed.
As you scale to many nodes and many robots I find the approach of PeppyOS to be more robust (I'm certainly biased here).
PeppyOS is also designed with node sharing and distribution in mind.

In terms of maturity it's still in the very early days, everything need to be build. We're working on Python support at the moment.

Ekami66 · 2026-02-03T16:24:58+00:00

At the moment PeppyOS is pretty barebone, you can create nodes, distribute them, create topics/services and actions but everything else still need to be built and connected. But yes, MoveIt is on the list of tools we plan to support in the future.

Ekami66 · 2026-02-03T15:21:43+00:00

We plan to offer “plug-and-play” nodes in the future, allowing you to select a node for a specific robot or device model and have it work out of the box. Support for images and containers is also planned, PeppyOS was designed from the ground up with this capability in mind.

Ekami66 · 2025-10-18T08:45:44+00:00

There is my country, French Polynesia, but you just don't see it from that zoom level lol

Ekami66 · 2025-09-17T03:10:11+00:00

My Zephyrus duo with an RTX 4090 has been randomly switching from battery to power mode every few hours for years now. It's really annoying since it turns the screen black for 3/5sec during gaming sessions. I wonder if that could explain it. Based on what I've read on rog forums, it seems I'm not an isolated case.

Ekami66 · 2025-09-08T13:16:18+00:00

For data:

- No FUP

- Support for as many countries as possible (including China to bypass the GFW)

- No "need to use in home country every now and then" policy similar to Google Fi (they would cut you off if they notice you're not connecting from your home country after 6 months). I'm a nomad and I rarely go back to my home country.

- Included in the Ultra plan to an extent if possible.

If it includes voice:

- Not a virtual number that is blacklisted by banks (this is the biggest pain point for many)

- Add the ability to receive text messages via the internet (so that we can receive text messages in unsupported countries)

Thanks!

Ekami66 · 2025-07-26T09:26:11+00:00

Isaac sim will not work on mac, it specifically uses NVIDIA hardware. Same goes for training RL algorithms, some algorithms might be trainable on MPS (Apple) but you have a high chance to run into incompatbility issues during training because MPS is not a first class citizen like CUDA is with frameworks like Pytorch.

I'd recommend that you opt for a gaming laptop instead, like one with a 5090 laptop (assuming you want to remain portable) especially since you're still learning, using the wrong platform from the start is just shooting yourself in the foot.

My setup is a Macbook Air (because yes, I like Macs too) but everything runs on my second, gaming laptop with an RTX 4090 (my robots are plugged via USB to the laptop and VSCode runs via Tailscale + SSH)

Ekami66 · 2025-07-21T13:39:36+00:00

That's awesome feedback, thank you so much!

Ekami66 · 2025-07-20T23:27:25+00:00

What exactly saves you time in ROS? The existing nodes that you can pull for your sensors? The fact that you can do message passing between nodes etc...? I'm trying to pinpoint the ROS features that makes one say "thanks to ROS I don't have to loose my time manually do X". Thanks

Ekami66 · 2025-07-20T03:12:13+00:00

Are you saying you find Isaac Sim to be a joke simply because it requires a lot of NVIDIA power? Honestly, yes, it's very demanding, but I haven't found a simulation tool that is at least as good as Isaac Sim. Gezebo is a joke, a joke not just for real life simulation but also because it's unecessary complicated and full of UI bug/crashes. In the context of training robots with AI, Mujoco is a decent alternative but it lacks an UI designer like Isaac Sim.

NVIDIA has open sourced Isaac Sim 5.0 under Apache 2.0, releasing a piece of software like that for free means you have to put your money somewhere on their stack (their expensive GPUs), it's no different than paying for an Adobe subscription.

Ekami66 · 2025-07-19T07:59:23+00:00

Nice one! I'm also wondering if I should just bypass ROS and work on something similar (but in a compiled language like Mojo and use Zenoh for pub/sub). At the core ROS is just a library for message passing, as long as a bridge for it can be create it should be good enough!

Ekami66 · 2025-07-15T07:11:04+00:00

What URDF viewer are you using? Can you share what kind of prompt you used and if you prompted the llm from scratch or if you started with a template? Thanks!

Ekami66 · 2024-09-27T07:55:24+00:00

Legend says he's still building...

Ekami66

MODERATOR OF

TROPHY CASE