Cleaning up the rqt_common & rqt_robot plugin repos

[Aaron Blasdel]

Hello again,

I have been thinking about some of the bloat that exists in these repos.

A number of the original "proof of concept" plugins never made it to really being full fledged useful plugins namely (obviously debatable): 

rqt_web

rqt_rviz

rqt_robot_steering

Some are so buggy I wonder if anyone uses them:

rqt_launch

Some of these probably shouldn't be installed in the default install since they only serve to clutter up rqt, make it harder to learn and look less "professional".

I propose separating the rqt plugin packages into a number of more compact repos.

If I miss anything or it anything looks wrong please say so. thanks!

Initial proposal:

rqt_metapackages(Allows change/re-release the metapackages without re-releasing the plugins) (also this will make it easier to include other packages into the metapackages)

- rqt_common_plugins

- rqt_robot_plugins

rqt_common_core (This could probably be subdivided)

- rqt_top

- rqt_graph

- rqt_dep

- rqt_console

- rqt_logger_level

- rqt_plot

- rqt_image_view

- rqt_bag

- rqt_bag_plugins

- rqt_topic

- rqt_publisher

- rqt_service_caller

- rqt_action

- rqt_srv

- rqt_msg

rqt_dashboards

- rqt_robot_dashboard

- rqt_robot_monitor

- rqt_runtime_monitor

rqt_robot_viewers

- rqt_pose_view

- rqt_nav_view

- rqt_tf_tree

rqt_dev_tools

- rqt_shell

- rqt_py_console

rqt_experimental (unstable, slow and/or possibly dangerous plugins)

- rqt_launch

- rqt_rviz

- rqt_web

- rqt_robot_steering

- rqt_moveit

I would probably say we should not include the "rqt_experimental & rqt_dev_tools" in the default installs.

Please tell me why i'm wrong and/or give your thoughts on how we should split these guys up for .

Aaron Blasdel

[Isaac I.Y. Saito]

IMO robot_steering has gotten its purpose and is not unusable at all;
I know a group of 2d nav users who use it for simple checking. Yes
it's a simple but still great tool that works off-the-shelf with any
diff drive ROS robot as I experienced at multiple users locations.

# Btw thanks for sharing mr_teleoperator. That is a great tool
although it needs tweaks to work out of the box.

Isaac

> --
> --
> To unsubscribe from this group, send email to
> ros-sig-rqt...@googlegroups.com
> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
> rqt: http://ros.org/wiki/rqt

[Aaron Blasdel]

robot_steering in its current form is dangerous due to latching and for that reason I hope they are "checking" on simulations and not real robots.

mr_teleoperator is clearly superior gui-wise. It needs a few tweaks to be truly general and maybe a touch of code cleanup.

Please explain a situation that you had mr_teleoperator installed, post tweaks for generality, that you would use robot_steering instead...

[Isaac I.Y. Saito]

Speaking of robot_steering specifically,
you can set the constant velocity and keep robots. I've found it
advantageous when we have multiple tasks to do while operating mobile
bases (you can do the same with rostopic commandline but who wants to
do that regularly). Also you can set the topic name on the fly (easy
enough for novice ROS users).

I'm happy as long as DEB of robot_steering is kept built somewhere, so
is a package that depends on it[1].

> robot_steering in its current form is dangerous due to latching

I'm just curious what this means (sorry for my English). Is there no
way to improve the GUI?

> Please explain a situation that you had mr_teleoperator installed, post tweaks for generality,

For this I will rather post on its issue tracker.

[1] http://wiki.ros.org/urdf_tutorial

--Isaac

--
!Happy opensource robotics!

Isaac I.Y. Saito (齋藤功)
Co-founder, Software Engineer (代表理事)
TORK (Tokyo Opensource Robotics Kyokai Association, (社) 東京オープンソースロボティクス協会)
http://opensource-robotics.tokyo.jp / 113-0034 東京都文京区湯島3-20-12 ツナシマ第2ビル4F
+81-50-3748-1069

[Dirk Thomas]

On Fri, Jul 10, 2015 at 8:56 AM, Isaac I.Y. Saito <iiys...@opensource-robotics.tokyo.jp> wrote:

Speaking of robot_steering specifically,
you can set the constant velocity and keep robots. I've found it
advantageous when we have multiple tasks to do while operating mobile
bases (you can do the same with rostopic commandline but who wants to
do that regularly). Also you can set the topic name on the fly (easy
enough for novice ROS users).

I agree that the plugin provides some value. 

 

> robot_steering in its current form is dangerous due to latching

Can you please describe why it is dangerous?

The plugins publishers are definitely not `latched`: https://github.com/ros-visualization/rqt_robot_plugins/blob/621d00877f5095c3832cd73c1937f5480de026e6/rqt_robot_steering/src/rqt_robot_steering/robot_steering.py#L144-L146

- Dirk

[Aaron Blasdel]

@dirk have you used it recently? If you click on the slider it will keep publishing a twist until you tell it to stop. That is rather dangerous behavior for a UI that is connected to cmd_vel on a real robot. Usually things that publish there have a deadman or stop publishing when you let up on a trigger. Granted the publishers themselves are not latching but they are republished which gives a similar behavior to latching.

@issac the way i'm suggesting improving the gui is by replacing it with one similar to what mr_teleoperator uses. That way it will turn itself back off automatically in a more safe fashion. As for the urdf_tutorials dep all that means is we would need any rqt plugin that lets you publish to cmd_vel not specifically robot_steering

[Dirk Thomas]

On Mon, Jul 13, 2015 at 5:40 PM, Aaron Blasdel <abla...@gmail.com> wrote:

@dirk have you used it recently? If you click on the slider it will keep publishing a twist until you tell it to stop. That is rather dangerous behavior for a UI that is connected to cmd_vel on a real robot. Usually things that publish there have a deadman or stop publishing when you let up on a trigger. Granted the publishers themselves are not latching but they are republished which gives a similar behavior to latching.

It should be easy to update the plugin to only publish for a certain amount of time or e.g. while Ctrl is being pressed.

While using the plugin I would have found such a "safety mechanism" annoying but it would also easily possible to toogle the behavior to let the user choose.

- Dirk

[Aaron Blasdel]

Holding the deadman can be annoying too but safety of humans/robots should take precedence.

I still think that the mr_tools ui is superior but baring getting that in I guess having a "quick fall off to zero" on mouse up would be acceptable. That way the mouse functions as a kind of dead man.