at Eurecat we are exploring the role of advanced debugging tools and methodologies and how they can be applied to the robotics software and its peculiarities.
Do better understand what the community thinks about this topic, please take 2-3 minutes to answer this questionnaire.
Just changed the form to make email address optional. Honestly I didn’t have any hidden agenda and I am not planning to use that information in any particular way
May be it is just confirmation bias, but this is roughtly what I expected, based also on my own experience.
I am presenting a proposal for a presentation at Roscon 2017 about profiling and offline debugging, using PlotJuggler (of course) and the outstanding RR developed by Mozilla.
I gave a quick glance and someone posted a comment about visualizing roslaunch files, and I think there is some work done here: http://wiki.ros.org/rqt_launch
That was me mentioning visualizing launch files.
Those plugins are so cool, I never knew they existed, how was I in dark for so long?
I think I’d like to make something like this for ROS2, only that you could create/edit launch scripts using an tooling interface, something like LabView’s integrated front/back panels but for ROS. Where I could drag and drop nodes from menu of installed packages on the system, snap and click wires for topics, quickly probe those connections and monitor dataflow from a high level graphic, break out parameters onto the front panel for runtime tweaking, quickly traverse/edit nested launch components, import/export auto generate the scripts statically offline from the GUI. I suppose this would require some method of static introspection of a node’s attributes or some additional meta information in node’s package.
I know bits and pieces of these ideas are implemented/scattered among various existing plugins, but never felt like could quickly write a launch file from scratch without having to manually lookup everything, either the nodes expected parameter names/types from the wiki docs or github readme, what the defaults were set to in the definition files, the required topic args or whatever hard coded namespaces I’d need to remap to, etc. I feel like for most nodes that are not too dynamic in behavior with respect to the ROS graph, like camera drivers or motor controller nodes that don’t change around what interfaces they advertise after startup, it would be a lot easier to conduct ROS node orchestration when using a tool that can introspect that for you while making launch systems.