GUI library

Customers

• Core RViz developers
• Plugin developers
• RViz users

Current state

RViz uses the GUI library wxWidgets.

Problem Description

Why should we change the system / what is the problem?

Technical solution

Plugin Management System

Customers

• Plugin developers

Current state

RViz currently uses a custom mechanism for locating and loading plugins based directly on ros::package::getPlugins and dynlib.h, which comes with wxWidgets.

Problem Description

The non-standard way of doing plugins requires additional documentation, make the learning curve for plugin developers steeper and makes the knowledge about RViz plugins less transferable.

If RViz will stop using wx, then we will need a different plugin system anyway.

Proposed Solution

• Switch to other plugin system
• Write documentation

Alternative plugin system options and their pros/cons:

• Keep existing rviz-specific plugin system.

• gmodule is a cross-platform module-loading system. Part of glib.

  • API is in C. Not clear how well would handle C++ classes.

• ROS pluginlib

  • Based on poco project library.

  • C++ API
  • Adds ROS package path searching machinery.
  • (Dave's favorite option)

• Qt's plugin system

  • C++ API
  • Handles Qt's metadata (signals and slots and reflection)
  • Ties plugins to Qt. Using any other option would let us re-use things like Display plugins in non-Qt uses of the future-rviz graphics code.

• visualization_engine: contains a package named rve_dynlib

Plugin API

Customers

• Plugin developers
• Rviz developers

Current state

Plugins directly communicate with the RViz API and Ogre.

Problem Description

The process of how to create such a plugin is not well documented, as is the RViz API. There is no clear notion of what part of the RViz API should be accessible to Plugins. Changes to internal rviz source code can easily break plugins.

Proposed Solution

• Document how to make an RViz plugin
• Review RViz API and separate stable part that the plugins are supposed to use

New displays

Customers

• Developers/Researchers working with probabilistic models or or surface reconstruction techniques

Current state

RViz contains a set of Displays which visualize certain types of data.

Problem Description

Several users have requested a way to display more data types

• Surfels (surface elements)
• Gaussian ellipsoids, representing a 3-d multivariate normal distribution (i.e. a mean vector + covariance matrix)

Currently, the only way to do this would be to write your own plugin or something that generates Marker messages for visualization.

Problems with that:

• Writing a plugin is very hard if you're new to it.
• Writing a Marker visualization also requires some effort and is possibly slow in execution.
• We don't want everybody to "reinvent the wheel".

In summary, adding this feature to RViz would make it easier to visualize this kind of data and thus more attractive and useful to certain groups.

Technical solution

Write specialized displays that are able to directly subscribe to surfel/gaussian messages and visualize them.

TODO: What message types are to be visualized, link to related tickets

Interactive Markers: enforce joint limits

Customers

• ROS application developers

Current state

Interactive Markers can have controls that enable the user to move and rotate them in space. You can limit the degrees of freedom by only adding a subset of the possible controls.

If you want to restrict that movement to within certain intervals, you have to do that within the IM server.

Problem Description

Side effects of the current solution are:

• High message traffic between server/RViz
• The user can drag/rotate the marker as he likes, but it will flip back to within its limits. This might be a confusing or otherwise downgrade the user experience.
• One solution (the "pong" tutorial) involves two markers, one that can be dragged and one only for display.

Technical solution

Only complete this part if the above are finished and fully understood. Describe what needs to be changed to solve the issue.

OSX Build

Customers

• OSX developers and end-users

Current state

Describe the current status of the system.

Problem Description

Why should we change the system / what is the problem?

Technical solution

Only complete this part if the above are finished and fully understood. Describe what needs to be changed to solve the issue.

Invocation of Ogre

Customers

• ROS developers

Current state

RViz uses an Ogre release contained in a ROS package.

Problem Description

Downloading and compiling Ogre from source takes 20-30 minutes even on a fast machine. Having Ogre built from source as a ROS package which many things depend on means Willow Garage's build-and-test servers spend lots of time just building Ogre. If we used the standard package (libogre-dev) for Ubuntu, ROS release and test builds would be significantly faster.

Maintaining the Ogre build also takes developer time and attention which could be better spent making awesome robots.

Technical solution

• Backport the 8 source files in rviz which use APIs that have changed between Ogre 1.6.4 and 1.7.3.
• Backport ogre_tools/.../wx_ogre_render_window.cpp which needs a slight change.
• Check if the "multi-scene-manager-patch" is still necessary to prevent an assertion failure with Ogre 1.6.4. If it IS, find and fix the root cause of the assertion failure.

• Write an "rdmanifest" file to compile and install Plugin_CgProgramManager, which is not part of libogre-dev.

Programatic control over RViz

Customers

• ROS developers using rviz to build applications and application prototypes

Current state

It is not currently possible to change an rviz viewpoint except by one of these methods:

• Using the GUI with the mouse.
• Publishing a TF frame to be used as a viewpoint controller, then setting that frame as the "target" frame in rviz, then moving the frame around with TF messages. This solution behaves poorly when a user actually does use the GUI with the mouse.
• Writing an rviz plugin.

Problem Description

Developers writing an interactive graphical system using rviz with Interactive Markers would like to assist their users by writing code which automatically positions the viewpoint to focus on task objects. The only way currently is to write a plugin, which has its own problems.

Other developers have also asked how they can programmatically add and remove displays in rviz. That is a similar problem which could be solved in similar ways.

Technical solution

A simple solution to this is to add a feature to rviz where it listens for messages which control the viewpoint. Perhaps though, if writing plugins were simpler, that method would be more attractive. There is a python scripting capability in rviz which I don't know much about. Perhaps a python script could solve the problem without changing the rviz source.

Another direction to look into is inspired by the RVE code which Josh Faust worked on before he left. The idea was to separate the display and rendering code into a library. The GUI program that is rviz would then be a user of that library, but other applications could be written with the library as well, using whatever UI elements and interaction behaviors the developers needed.

GUI Frontend-less RViz

Customers

• Researchers who wish to use the overlay / fusion capabilities of rviz in other executables.
• Human-subject studies where RViz would be useful, but the amount of visual information needs to be precisely controlled.

Current state

RViz's functionality cannot easily be used as a module/component in another application.

Problem Description

The answer to this previously has been instead to write a plug-in for RViz, but this doesn't give complete control over the user experience.

Technical solution

Using a pre-defined (config file) or programatically-controlled interface (see above CR) 2D/3D views that would normally be rendered inside of RViz could be rendered as part of another application, either fullscreen or windowed with a custom (application-specific) GUI.

Change request template

Customers

• Who will be affected from this change?

Current state

Describe the current status of the system.

Problem Description

Why should we change the system / what is the problem?

Technical solution

Only complete this part if the above are finished and fully understood. Describe what needs to be changed to solve the issue.