Skype meeting on Sep 28, 2011

Attendees:

• Dirk Thomas
• Dorian Scholz
• Dave Hershberger
• David Gossow

Agenda Items

1. Description of the idea behind the proposed SIG
2. Clarify differences and combination possibilities with RVIZ
3. Short introduction and main interest of every member
   • Who will contribute in which fashion?
4. Next steps
   • Agree on coordinator
   • Define goals and a rough timetable for milestones
   • Subgroups for specific parts
   • Next meeting

The concept (see also [1] and [2])

• Decision of GUI toolkit
  • Qt (LGPL)
    • Feature-rich
    • Widely spread
    • Big community
• Advantages of an integrated GUI
  • Ability to dock widgets (instead of free floating windows of separate tools)
  • Provide tool-spanning features like save/restore of window positions and states
    • Provide infrastructure for plugins to easily store/restore intrinsic state
  • Enable perspectives (as in Eclipse, which (re-)store the currently instantiated plugins and there state)
• Plugin architecture

  • The core of ROS GUI is designed as a framework and implemented in Python

  • Plugins provide the real functionalities for the users
    • Suited for developers as well as end-users, depending on the used plugins

  • Plugins are discover by PluginProviders using the exported plugins in the ROS package infrastructure

    • PluginProviders can be hierarchically nested

  • All discovered plugins are added to a menu (so that the user can instantiate the plugin at runtime)
  • Each plugin can provide arbitrary UI elements (toolbar, dock widget, ..) when being instantiated
• Cross-language
  • Different requirements for different plugins
  • Efficient prototyping (in Python) vs. efficienty runtime / more feature rich (e.g. image transport) ROS client library (in C++)
  • Possibility to implement plugins in either Python or C++
  • Usage of bindings should be hidden from the plugin developer (as it is very nasty)

    • Support both PyQt (GPL, mature) and PySide (LGPL, premature)

• Dependencies (slide 10 and 11 in [1])

  • The core framework of ROS GUI depends only on rospkg (not ROS)

    • This enables plugins and PluginProviders implemented in Python without using any ROS client library

    • A plugin could e.g. visualize the weather forecast

  • The RosPyPluginProvider integrated the rospy client library

    • This enables plugins to use funtionality from the rospy client library
    • E.g. a plugin providing the funtionality of rxplot

  • The CppPluginProvider uses a binding generator (either SIP or shiboken) to bridge from Python to C++

    • This enables plugins and PluginProviders implemented in C++ (still without any dependency to ROS)

    • Uses the pluginlib to discover and load plugins

  • The RosCppPluginProvider integrated the roscpp client library

    • It acts as a nodelet manager
    • This enables c++-plugins to use funtionality from the roscpp client library
• Some first examples (see [2])
  • Simple ROS publisher
    • Publish arbitrary messages with values determined by an equation
  • ROS topic introspection
    • Provides similar functionality as the command line tool rostopic
  • ROS plot
    • Provides similar functionality as the tool rxplot

Discussion

• Disadvantages due to single-process integrated GUI
  • One hanging plugin might block the entire application
  • A segfault in one plugin will crash the entire application
    • Workaround: start multiple instances of ROS GUI - each only running one plugin
  • Ideas:
    • Is it possible to execute each plugin in a separate process?
    • Would it be possible to create an integrated GUI from multiple separate binaries?

      • Hint for research: QX11EmbedContainer, reparenting

• Make it more ros-ish?
  • Make starting plugins behave more like starting nodes
    • Being able to start individual plugins using command line options
    • Being able to start specific perspectives using command line options
• Enable exporting (and importing) a perspective for passing it to other developers?
• For different users it might be useful to restrict the set of available plugins
• To show the available and loaded plugins, the main menu bar is used
  • This should be configurable to be optional and replaceable by i.e. a toolbar
  • Design it the way that this can be exchanged in a flexible way (may be also using plugins?)
• Besides the docking of dock widgets it would be useful to be able to group widgets using tabs
  • One-widget-per-tab is supported by Qt out-of-the-box
  • The difference between using multiple perspectives is that the tabbed widget are still there (even when not being in foreground)
  • But multiple widgets per tab might also be useful (see [3])
    • Is this possible using dock widgets? [3] shows only fixed widgets in the tabs

Relation to rviz

• Currently some features of rviz overlap with ROS GUI (save/restore, usage of plugins)
• rviz could be integrated as one plugin in ROS GUI
  • It would use the functionality of ROS GUI to save/restore window geometry and state
  • It could store its intrinsic configuration in the ROS GUI settings storage (similar to QSettings)
  • This would make rviz integrate well into the set of other ROS GUI-based plugins
  • Still a standalone version of rviz can be maintained (or e.g. rviz can be called as the only plugin in ROS GUI)

Relation to rind

• Currently we only see the relation that rind might be able to start ROS GUI
  • May be enable the user to setup custom configurations (e.g. one for each perspective) in rind to start a specific configuration of ROS GUI

Main focus and contribution of the members

• Dirk Thomas develops the infrastructure of ROS GUI
• Dorian Scholz works on specific plugins which can be reused in different projects
• Dave Hershberger and David Gossow are tracking the development to investigate the possibility to integrate rviz as one plugin for this framework (after rviz has been migrated to Qt)

Next steps

• Dirk will act as the coordinator for this SIG
• The next milestones are:
  • Setup a repository for the current prototype where future development will take place
  • Investigate possibility and estimate effort needed to run plugins in separate processes
  • Investigate tabbed user interface, where each tab can hold arbitrary dock widgets (similar to GUI developed in Koblenz plus dock widgets)
  • Polish the prototype to work will under different setups (e.g. different bindings)
• Schedule next meeting in about one month
  • When development of prototype is more advanced
  • To discuss upcoming conceptional items

Attachments

[1] Slides illustrating the concept of the plugin hierarchy: sig-rosgui.pdf

[2] Some example plugins: rosgui_example_implementation.pdf

[3] GUI Example from Uni Koblenz: This shows a robot GUI realized with Qt mentioned during the conference call, which uses tabs to switch between separate screen configurations. The concept proved very useful in practice, especially when screen space is limited. RX-GUI_main.png RX-GUI_map.png