Proposal for a rqt_experimental_plugins and rqt_core_plugins packages

[ablasdel]

This package would house new plugins that we would wish to add to common_plugins until they stabilize (have no Major bug Issues etc).

This would give the rqt user a better idea of what plugins we are presenting as stable and fully developed.

It would also help keep the number of issues on the main repo down so it is clear to users what bugs and enhancements we are focusing on.

Less important but it might be wise to have a distinction between the really critical core plugins and the "nice to haves". rqt_core_plugins could house rqt_console, rqt_image_view, rqt_plot and all the other "it is significantly harder to use ROS without a tool like this" plugins.

rqt_common_plugins could house things like rqt_msg, rqt_srv, rqt_action and rqt_web that are useful sometimes but something you could live without.

[DorianScholz]

I think it is a good idea to divide the packages.
This helps us focus on the important plugins.
Also this will be visible to users when reporting bugs, as they have to go into the specific packages for that.

But the question is, how are "normal" users of rqt going to see experimental plugins in the GUI?
Should the plugins have the "experimental" in their menu entry, i.e. "plugin name [experimental]"?

[ablasdel]

Good idea on making it also visible in the GUI. A text tag would suffice I think. Though we would have to add a flag for this state in the plugin.xml. I would suggest a "stable=true" flag somewhere to be added only once a plugin has officially left experimental status.

I was thinking we wouldn't install them with "desktop" but making the status visible would be another option.

[dirk-thomas]

Splitting the "experimental" plugins into their own repo does not really buy us anything. On the positive side the tickets get separated but on the negative side reintegrating them later with history is more of a challenge. The most significant thing is that the user does not even notice so nothing changes from his impression that the plugin is supposed to work. Anyway splitting each plugin into its own repo could be a good thing in the long run - also to decouple their releases.

We might want to consider to group all the plugins in the plugin menu. On the one hand that would anyway be useful since the plain list gets already pretty long and confusing. On the other hand we could use one group name like "under development" / "experimental" and put some plugins there.

Would someone put together a complete list of plugins and propose a grouping of them?

[ablasdel]

+1 splitting plugins into their own repos and as long as we keep sort of "plugin release groups" concept so they can be easily installed enmass.

+1 adding some sort of groups tag to the pluglin.xml to use for hierarchy in the drop down.

I'll look into some possible groupings for the plugins we currently have.

[dirk-thomas]

rqt already supports grouping (even nested).

Just propose a list so we can iterate them - I can then deploy the necessary changes.

[ablasdel]

Here is a preliminary grouping that seems to make sense:

Group names are up for debate obviously

Introspect ROS System:
Action Introspection
Message Introspection
Service Introspection
Package Graph

View/Edit ROS State:
Bag
Console
Dynamic Reconfigure
Graph
Launch
Logger Level
Publisher
ServiceCaller
Top / Process Monitor
Topic Introspection

Visualization:
GPS
Image View
Plot
Navigation Viewer
RViz
TF Tree

Robot Command:
PR2 PBD GUI
Robot Steering
Moveit! monitor

Robot Monitoring:
Kobuki Desktop
PR2 Dashboard
PR2 motor diagnostic
Runtime Monitor
Robot Monitor

Tools:
Shell
PyConsole
Webtool integration

Experimental:
New plugins go here!

[dirk-thomas]

• Introspect ROS System:
  I would call this differently. "Topic introspection" not being in it already indicates that the grouping naming is difficult. It should contain something in the name which makes clear that these plugins deal with static information of ROS only. The list information available without running anything and introspection often refers to look into a running system. Probably call it "Static ROS information"?
• View/Edit ROS State:
  In contrast to the first group these plugins deal with a running ROS system and allow to view information as well as to manipulate it. I am not very happy with the proposed name but don't have anything better to offer right now. Any other ideas?
• Some plugin classifications are not obvious to me:
  • What does "Moveit! monitor" do? Can it really "command" or should it be under "Robot monitoring"?
  • What does the "Runtime Monitor" do? Is it the diagnostic part of the dashboards? Why is it under "Robot Monitoring"?
• Should we have a group for every specific robot? E.g. all PR2 specific plugins go into a "PR2" group.

[ablasdel]

I agree the names need serious work. Any ideas welcome.

For "introspect system". I was thinking more of things at look of the state
of the ROS install

For view edit I was thinking things that look at actively moving ROS parts.
(Which is why topic introspect lived here.

I guessed on move it monitor. If I was wrong it can be moved.

Runtime monitor is a basic diagnostic aggregator viewer. Robot monitor is
similar but give quite a few more features for looking at previous states
and pulling out error/warn states.

I like the idea of robot specific groups and then a " robot monitoring" for
the basic "all robots can use these" things

On Monday, August 26, 2013, Dirk Thomas wrote:

Introspect ROS System:
I would call this differently. "Topic introspection" not being in it
already indicates that the grouping naming is difficult. It should contain
something in the name which makes clear that these plugins deal with static
information of ROS only. The list information available without running
anything and introspection often refers to look into a running system.
Probably call it "Static ROS information"?

View/Edit ROS State:
In contrast to the first group these plugins deal with a running ROS
system and allow to view information as well as to manipulate it. I am not
very happy with the proposed name but don't have anything better to offer
right now. Any other ideas?

Some plugin classifications are not obvious to me:
- What does "Moveit! monitor" do? Can it really "command" or should
it be under "Robot monitoring"?
- What does the "Runtime Monitor" do? Is it the diagnostic part of
the dashboards? Why is it under "Robot Monitoring"?
-

Should we have a group for every specific robot? E.g. all PR2 specific
plugins go into a "PR2" group.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/167#issuecomment-23291506
.

[wjwwood]

This is how I would organize them with some plugin name changes for consistency. Obviously these are just my opinion, not sure how we can iterate on this:

• Actions
  • Action Caller # This doesn't exist yet
  • Action Type Browser # formerly Action Type Introspection
• Services
  • Service Caller # formerly ServiceCaller
  • Service Type Browser # formerly Service Introspection
• Topics
  • Message Type Browser # formerly Message Introspection
  • Topic Monitor # formerly Topic Introspection
  • Topic Publisher # formerly Publisher
• Logging
  • Console
  • Logger Level
  • Bag
• Introspection
  • Package Graph
  • Top / Process Monitor
  • Node Graph
  • Dynamic Reconfigure
  • Launch
• Visualization
  • GPS
  • Image View
  • Plot
  • Navigation Viewer
  • RViz
  • TF Tree
• Robot Tools
  • Robot Steering
  • Robot Monitor # Consider renaming to 'Diagnostics Viewer'?
  • Runtime Monitor (Deprecated in favor of Robot Monitor?)
• PR2
  • PR2 PBD GUI
  • PR2 Dashboard
  • PR2 Motor Diagnostic
• Kobuki
  • Kobuki Desktop
• Moveit!
  • Moveit! Monitor
• Miscellaneous Tools
  • Shell
  • PyConsole
  • Web
• Experimental
  • New plugins...

[ablasdel]

+1 on William's list/name change iteration.
With some minor issues:
1 Isn't Moveit! a robot tool? it seems pretty general and I would slot it into "robot tools" but you have worked with it more than me.
2 I was told that Runtime Monitor fills a slightly different niche honestly.

[dirk-thomas]

Regarding the list from @wjwwood:

• I would not expect "Launch" to be under "Introspection", I don't see any group where launch really fits in
• "Robot monitor" aka. "Diagnostics Viewer" sounds a lot like it belongs to "Introspection"
• "Moveit! Monitor" should not be its own group, it does not really buy us anything

Minor rename:

• I would rename "Topic Publisher" to "Message Publisher" since that matches ROS terminology better

[dirk-thomas]

Slightly refined grouping (as sent to the mailing list):

Actions

• Action Caller # this doesn't exist yet
• Action Type Browser # formerly Action Type Introspection

Services

• Service Caller # formerly ServiceCaller
• Service Type Browser # formerly Service Introspection

Topics

• Message Publisher # formerly Publisher
• Message Type Browser # formerly Message Introspection
• Topic Monitor # formerly Topic Introspection

Logging

• Bag
• Console
• Logger Level

(How should this group be named?)

• Dynamic Reconfigure
• Launch

Introspection

• Node Graph
• Package Graph
• Process Monitor

Visualization

• GPS
• Image View
• Navigation Viewer
• Plot
• RViz
• TF Tree

Robot

• Kobuki:
  • Kobuki Desktop
• PR2:
  • PR2 Dashboard
  • PR2 Motor Diagnostic
  • PR2 PBD GUI

Robot Tools

• Moveit! Monitor
• Robot Monitor # consider renaming to 'Diagnostics Viewer'?
• Robot Steering
• Runtime Monitor

Miscellaneous Tools

• PyConsole
• Shell
• Web
• New plugins (experimental) # marked as experimental until they are stable

Updated based on feedback:

• each robot group (Kobuki, PR2 etc.) is now nested under a generic group called Robot
• marking experimental plugins with (experimental) but keeping them in the group they belong to

[DorianScholz]

+1 for the hierarchy
But instead of putting all new/experimental plugins in one group, shouldn't they directly go into the appropriate group and have an "(experimental)" suffix?
This would allow them to be found more easily after they have matured and still tell the user not to expect a stable plugin yet.

[dirk-thomas]

@DorianScholz good point - I updated the above list.