Otherwise if you’re still with me… Come start the conversation about launch, declarative node interfaces, health monitoring, and more - the tooling that will help us reason holistically about ROS applications and their structure.
I’m working on the official processes to put up a charter and get onto shared calendars, but for now we can, as Kat said, “just do things” - let’s get started!
The first meeting is scheduled for 2025-11-11T17:00:00Z
I based that on the feedback from the initial wave of google form submissions. There was a preference for “PST morning” and a pretty even preference split between Monday, Tuesday, Thursday. The time and frequency of meetings will be open for discussion.
Whether you can make the first meeting or not, add any notes you like to the agenda doc or send a message to the mailing list. If you can’t make the first meeting, that’s okay - my intention is to keep meeting regularly so “there’s always next time”.
I’d be thrilled if you would participate in the working group to discuss graph monitoring, it’s clearly a need in the community without a complete or default solution.
The following is long, maybe content for a separate thread or a live discussion:
ros2graph_explorer looks like it’s providing a combination of the monitoring / “state estimation”, and visualization functions (plus a custom ROS 2 web client communication protocol?? )
We’ve got a package ros-tooling/graph-monitor doing graph monitoring, I think we should figure out what feature disjoints exist, if any, with ros2graph_explorer and contribute those into rosgraph_monitor to get consolidated into one solid package for the community to land on! To me, the right architecture is to keep the monitoring as a standalone component, whose output snapshots we can feed to visualizers. “Make components that do one thing well, then compose” is my general philosophy.
At Polymath we’ve contributed a really rough prototype of a graph visualizer as a Foxglove extension, which we made a LinkedIn post about and you can find it in the foxglove extensions repository. This thing needs a lot of work! We’d be happy to collaborate on extending or replacing any of it with something better we just know that the builtin graph viewer isn’t good enough, so an extension is the way forward to be able to get the feature set we need. If it were a standalone web-based viz component that you could keep using in a standalone webserver, or plug it in to Foxglove with a thin compatibility layer, then all the better.
We focused on declarative interfaces, discussing generate_parameter_library and nodl, brainstorming paths forward for a unified design.
Some documentation contributions have already come directly out of this as well, in launch and graph-monitor - shout out to shrujanus (shrujan) · GitHub and lsy3 · GitHub for jumping in! (sorry, don’t know if you’re on Discourse to tag)
The working group is now official under the ROS 2 PMC, joining the Client Libraries WG as the second group to go through the charter process. Which doesn’t change anything right now, but it’s nice to be recognized
The next meeting will be on 2025-11-25T18:00:00Z - we had to shift an hour to accommodate the ROS 2 PMC meeting (probably) moving into our time slot.
)
we just know that the builtin graph viewer isn’t good enough, so an extension is the way forward to be able to get the feature set we need. If it were a standalone web-based viz component that you could keep using in a standalone webserver, or plug it in to Foxglove with a thin compatibility layer, then all the better.