Contents
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.
Based on poco project library.
- C++ API
- Adds ROS package path searching machinery.
- (Dave's favorite option)
- 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.
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.