facontidavide

Soon there will be only 3 factors that we will care about: API (easy to use and integrate), behavior (does it do what I want it to do?) and testability (do I have sufficient guaranty that the code doesn't have errors).

The fact that the code was generated by a human or a machine is less and less important.

Cool to see that this project started 5 days ago! Unfortunately, I can not make it work on my system (Ubuntu, chrome, WebGPU enabled as described in the documentation). On the other hand, It works on my Android phone...

Funny enough, I am doing something very similar: a C++ portable (Windows, Linux MacOS) charting library, that also compile to WASM and runs in the browser...

I am still at day 2, so see you in 3 days, I guess!

I have been doing robotics for 20 years, and the "trend" to adopt a distributed architecture was already popular 15 years ago. ROS just adopted and continued that trend. I think you are missing some important points:

- a large amount of data can be transferred asynchronously. Pub/Sub is a great pattern to achieve that; the cases when you need a synchronous interface are the minority.

- a robotic software has MANY components, you need an approach that incentivize decoupling and lousily-coupled interfaces.

- this lousily-coupled architecture has been a catalyst for innovation and cooperation, because it makes it easier for people to share their code as "building blocks" of a larger system.

Is there a considerable overhead? Sure! But it is much more complicated to write thread-safe code in a huge, monolithic application.

"There are not multiple queues with work-stealing which is I think a minimum for a production level version of something like this."

100% agree. I also agree that would be a minimum requirement to call it "high-performance".

Get in touch, I will be happy to hear more about it :D

The core of PlotJuggler is completely decoupled from ROS. ROS is supported only through optional plugins.

This means that you can easily extend the number of interfaces and protocols adding new plugins, as shown in version 3.

I also used KST many years ago and it was surely a big source of inspiration, but I think that PlotJuggler offer a much more intuitive interface.

But of course I am biased, as author of PlotJuggler ;)

In the app itself there is a visual "Cheatsheet", but this particular piece of information is not there.

Give it a try, it should be quite self explaining. If you have any issue, get in touch on Github Issues.

Thanks :D

Thanks for sharing these links! The big difference is that PlotJuggler is a desktop application, not a library.