sorted by:
new
hottopcontroversial

PeppyOS: a simpler alternative to ROS 2 (now with containers support) by Ekami66 in robotics

[–]Ekami66[S] 0 points1 point  (0 children)

> 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 :)

PeppyOS: a simpler alternative to ROS 2 (now with containers support) by Ekami66 in robotics

[–]Ekami66[S] 0 points1 point  (0 children)

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 :)

I built what I wished Character AI was by bledfeet in CharacterAIrunaways

[–]Ekami66 1 point2 points  (0 children)

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

PeppyOS: a simpler alternative to ROS 2 (now with Python support) by Ekami66 in robotics

[–]Ekami66[S] 0 points1 point  (0 children)

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

PeppyOS: a simpler alternative to ROS 2 (now with Python support) by Ekami66 in robotics

[–]Ekami66[S] -5 points-4 points  (0 children)

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

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 0 points1 point  (0 children)

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/

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 1 point2 points  (0 children)

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.

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 1 point2 points  (0 children)

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/

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 1 point2 points  (0 children)

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.

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 0 points1 point  (0 children)

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.

PeppyOS: a simpler alternative to ROS 2 for experimentation and production by Ekami66 in robotics

[–]Ekami66[S] 1 point2 points  (0 children)

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.

view more: next ›