It's great to hear you want to contribute some useful new tools. There is some work that I have on the shelf that should help dovetail with this: 1) New scripting API for roslaunch. The work I'm doing on the rosh is helping evolve the roslaunch API. I hope to have this landed in unstable soon. Once the scripting interface is solid, it should be trivial to add a network API on top (XMLRPC). 2) Interfaces. The plan is to convert the Node API clearsilver specs on the wiki into actual YAML node specifications. The idea here is multifold: i) Machine-readable spec of what topics, services, parameters, etc.. a node provides/uses. This is useful for validation, documentation, GUIs, etc... ii) Machine-readable spec that can be used to bootstrap a node initialization iii) Standardization of common APIs (e.g. camera interface) For example, imagine (in pseudocode): n = Node('camera.interface') p = n.pubs['camera/image_raw'] image = load_from_disk('foo.jpg') r = Rate(10) while ok(): p.publish(image) r.sleep() I focused more on rosh this cycle so interfaces are still all concept, no design or implementation. I hope to work on them after I finish up my Diamondback work. I think that the main challenge in deploying this sort of solution is going to be converting existing code to provide these specifications. It will take a lot of time. While it is possible to try and automatically determine this information, there are many cases where it will fail badly, which isn't good for a "user friendly" GUI. - Ken On Thu, Oct 14, 2010 at 5:54 AM, William Woodall wrote: > I am currently beginning development on a "rostoolbox" initially for my own > use, but with some loftier end goals.  Currently my goal will be to > implement existing functionality from command line arguments that ros > provides, including roslaunch, rosrun, and rosparam, into a GUI.  I hope to > have an interactive view similar to rxgraph's output which could allow for > dragging to rename topics, interactively adjusting static and dynamic > parameters, and adding/removing nodes.  Then finally when your done crafting > your setup you can save out as a launch file.  Like I said, initially I want > this to just be able to list, create, compile, and install dep's of stacks > and packages from a GUI, but the sky is really the limit after that as to > how interactive the system could be.  I would also like to see this > eventually ported to the roswin32, because for my peers that use Windows > having a tool like this will almost be required for them to start using ROS > on Windows.  If you want to do some joint development maybe we could discuss > this more. > Thanks, > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > William Woodall > Graduate Software Engineering > Auburn University > w@auburn.edu > wjwwood@gmail.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > On Thu, Oct 14, 2010 at 2:49 AM, Morten Kjærgaard > wrote: >> >> Hi >> >> I am planning on creating a graphical tool to give mode dynamic control of >> what nodes are started and the names of the topics they subscribe to. >> This will probably require some changes in the core of my ROS system, but >> it seems to be possible. >> >> The motive is to improve the deployment- and parameter management when >> creating a new robot system based on existing ROS packages. And make it >> possible to relate this to a robot model. Instead of only having to rely on >> static hardcoded launch files. >> >> I would like to hear from anyone who has experience with a similar >> approach or are otherwise interested in a management tool like this. >> >> Best regards, >> --------------------------- >> Morten Kjaergaard >> Industrial PhD Student >> >> Prevas A/S >> Frederikskaj 6 >> DK-2450 Koebenhavn SV >> >> morten.kjargaard@prevas.dk >> www.prevas.dk >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >