HN user
Since I still see this on the front page, I am taking the liberty to plug my own funny experiment (still WIP).
By no mean it is as nice looking as your demo, but it is interesting to ME... C++, compiled to WASM, using WebGL. Works on Firefox too. M4 decimation.
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.
Main author here of the library: I just released the 4th major version of BehaviorTree.CPP.
https://github.com/BehaviorTree/BehaviorTree.CPP
This library is increasingly popular in robotics and automation, and I am very excited about the new features being introduced.
Video link: https://www.youtube.com/watch?v=zULU6Hhp42w
"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.
PlotJuggler author here. I am sorry, but I had no opportunity/time to test it on Mac :(
In terms of License, it is actually LGPL-3.0 License, the same as Qt itself and some of the dependencies it uses.
This means that you can develop proprietary (closed source) plugins to create your own custom interfaces to parse data, if you want/need to.
No. It is a tool to visualize one-dimensional time series.
Yes!
This is one of the key feature of PlotJuggler. They are called "layouts".
The fancy website: https://plotjuggler.io/
I guess I will take the opportunity to congratulate Marple and say (self promotion), that you have an open source alternative, that is equally able to deal with gigabytes of data and millions of points.
Hi, there is a related article here, if you want to know why I developed PlotJuggler. https://link.medium.com/1pY5Kz3PNU