I want to draw your attention to a nice tool that we developed and are using in all our ROS activities. rosmon is a roslaunch-compliant launch tool for ROS, especially designed for developer friendliness and interactive monitoring of long-running ROS processes, e.g. for competitions or demonstrations.
Just a short teaser:
Start/stop/restart single nodes using a modern console UI, ROS service calls, or an rqt plugin.
Attach to a running node process with gdb with two keystrokes. In case your node dies without gdb attached, rosmon automatically collects a core dump and launches gdb against the core dump on request.
stdout/stderr are separately captured per process and annotated, ensuring overview (no more ‘who is printing this message?’).
For details please check out the ROS wiki page - there are many small details which make the life of a ROS developer a little bit easier.
rosmon has been open-source for quite some time (developed for the DARPA Robotics Challenge 2015), but we now provide binary packages through the ROS build farm for ROS Lunar, Kinetic, and Melodic - which is a nice time for an official announcement
We are looking forward to thoughts, feedback, bug reports, or pull requests!
Cool idea! I was excited to try this out but after a few minutes had already found multiple discrepancies between rosmon and roslaunch behavior in Kinetic (to the point where I couldn’t get any of my systems launched).
I would like to have much of the functionality you provide but ultimately question the ability to maintain/support this moving forward with the decision to re-implement roslaunch's XML parsing.
Yes, re-implementing the roslaunch XML parser was a difficult design decision. In the end, I hope to arrive in a situation like HTML - one spec, multiple implementations. This has disadvantages (code duplication), but also advantages with regards to specialization and for finding problems in the spec itself.
In any case, thanks for testing and reporting your findings on GitHub. Did you have problems other than pass_all_args in <include> tags?
One other so far, but I haven’t figured out where exactly the issue is coming from and thus didn’t want to post the issue on GitHub yet. But since you asked …
Thanks and hopefully the above doesn’t come off negative; I want to use this
The tab-complete performance/functionality alone on the arguments is sweet.
Aside: any reason you didn’t use a “ros” prefix for the terminal command (i.e. mon vs something like rosmon)? Just curious.
Well, the general plan is to support more sub-commands (like “mon stop ”, “mon status”, …) - that’s why the “launch” is there. As for “mon” vs. “rosmon”, “mon” is simply shorter. Since the shorthand is only available once you source the ROS environment, I hope that there are no collisions with other tools.
If so, you can still fall back to “rosrun rosmon rosmon …”.
Looks very nice, particularly the bit where rosmon has a ROS interface itself.
On the wiki page it says that it does not support the machine tag. Is there an alternative way to launch nodes on remote hosts, or how do you handle that?
There is currently no way to launch nodes remotely, as rosmon was designed in a scenario without permanent network connection. PRs welcome
We usually ssh into our robots, and run rosmon inside tmux. The ROS interface can then be used over the network to monitor and control the rosmon instance remotely.
Hello, I just wanted to ask if you thought of the crazy idea of using Python embedded in your application to parse launch files (so to use the same implementation, and, potentially, accepting all the format). Maybe you are already doing this (or partially) for the eval stuff.
And if you thought about it, I’d like to know your opinion on it, I’m curious (never tried).
Yes, we are already using an embedded python interpreter for $(eval …).
There are two problems with using the roslaunch API to parse launch files: a) the API is not stable and b) rosmon defines some extensions, which would be hard to extract using the roslaunch parser.
I am currently working on more complete verification tests to check compliance with the roslaunch XML spec (see spec_tests branch).
Update: we have been using this in our lab now since the announcement (thanks to some super-fast PR’s on a couple initial issues) and have to say we are fans. Cool stuff!
We eagerly look forward to any further developments.
Thanks for the awesome feedback, BrettHemes. Happy to hear that rosmon is useful for you guys!
Just a quick status update: A binary release with many fixes to problems reported by the community is ongoing. I’m fighting with some strange compiler issues on the buildfarm (some g++/ccache interaction), but we should make it in time for the next package syncs for kinetic, lunar, and melodic.
