A list of minor issues

[v4hn]

Robert encouraged me to post my list of minor issues on github to encourage contributions. I don't see why I should keep it to myself. :smile:

These are all minor issues I found using the basic MoveIt&Resources packages. No guarantees on a few of those as I use a somewhat wild mix of dependency versions that might induce them. If you can't reproduce anything, just ignore it.

If you want to discuss any of them please create a separate issue. Otherwise feel free to write patches to your heart's content and contribute fixes! :flying_saucer:

1. Planning an RViz trajectory with the PTP planner through an obstacle does not visibly indicate a failure (though plan validation fails) in the gui

2. collision markers (red spheres published on a separate topic) do not vanish until new collisions happen It might make sense to publish an empty message to the topic on successful planning? #2944

3. roslaunch moveit_resources_panda_moveit_config demo.launch, add a MotionPlanningDisplay, save the config, quit, relaunch. The Motion Planning panel is disabled, though the display is enabled. toggling the display makes the panel appear

   • EDIT (rhaschke): This is a rather strange bug. I cannot reproduce it when creating a config from scratch! Something in the saved QMainWindow state is screwed. I suggest modifying the config in moveit_resources.

4. in demo mode the fake joint publisher can end up publishing no current robot states to rviz anymore during and after executing a trajectory - disabling+enabling the display shows the new robot state though! I have no idea how to reproduce this.

5. dragging around the goal state in the 3d view when the "Planning" tab is active in the panel sometimes triggers very brief resizes of the tab.

   • ~~By the looks of it the source for this seems to be in the "Options" box, but it's hard to see what might cause it.~~
   • This is actually caused by as small (progress?) bar that sometimes appears at the bottom of the panel (if IK solving takes a tiny moment too long?). I propose to simply get rid of that bar.

6. pilz planner needs PTP as default (in RViz) There is currently no default there and users are required to selecte one because planning fails without specifying one! Instead let's just default to PTP here

7. RViz configs in MSA templates and the resources still use XYOrbit view This is totally unusable and Orbit view with the center at the center of the used workspace of the robot should be preferred.

8. If you scroll through a planned trajectory with the slider (autoplay paused), and afterwards move the marker for the goal state again, the robot state showing the trajectory waypoint will still be there and is relatively hard to get rid of. Moving the slider to the end/and or resuming play in the trajectory panel should probably disable the state to cleanup the screen when the user moved on. EDIT (rhaschke): The "planned path" robot is always visible (any selected waypoint, but typically the last one) as long as the corresponding checkbox is ticked. Do you want the visualization to automagically hide? Why? When exactly? What does it mean that "the user moved on"?

9. typing left/right after clicking on any of the sliders in the Joints tab does not move the slider (they are actually progress bars, so that would have to be implemented manually) - this should also work after clicking the joint name on the left

10. dragging a slider in the joints tab drops the unit (it will only display the number) until dragging ends

11. in the joints tab "Nullspace exploration:" is visible even when there is no slider below. #2944

12. The default planning group in the RViz panel is "hand". It should be "arm". EDIT (rhaschke): Can we specify a default planning group at all? I think, currently it's just the first one in alphabetical order: https://github.com/ros-planning/moveit/blob/0d006508180f72ad6d3354b72dc3eaba65720ca8/moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp#L276

13. In the list in the "Scene Objects" tab an object can be selected and an interactive marker will let the user move the object about. There is no way in the UI to deselect the object anymore (and get rid of the marker) without selecting a different one or changing the tab - though no object is selected when the user first opens the tab. Clicking the selected object in the list should probably deselect it. EDIT (rhaschke): Deselecting can be performed with Ctrl+Click in Qt views. If that's not enough, I suggest to install an eventFilter for the list and deselecting any object if the background of the list is clicked. Clicking an object for deselecting, as proposed by Michael, violates common Qt practice.

14. In the "Joints" tab, joint values are given in degree. Some people think this is the correct way to show things to the user. But, in addition to this being a debatable choice, this makes it awful to set values from debugging output (in rad) to look at the robot state visually. As there are two clear opinions on this issue, I would propose to add a checkbox to switch units.

15. The joints tab can handle start and goal state, though almost everyone will only use it for the goal state. The issue here is that the magic bit which of the two is represented is set through the last modified one. So if you by any chance check the dropdown list for the start state in the Planning Tab, the joints tab will select the start state until the goal state is updated again. There is even a text field at the top of the joints panel to indicate which state is used, but no way to change it. Instead I would propose a bullet selection or checkbox at the top right of the panel.

16. When you look through the allowed collisions list in the setup assistant, click the checkbox for any link pair that is shown in red/green (not allowed/allowed collision). The color of the pair should change instantly, but only changes once you select a different pair and go back again. There's an update hook missing.

17. After moving the interactive marker with the mouse in rviz, the selection box in the Motion Planning panel will still show a named value "", "home", or whatever named state you selected last. It would be better usability to show a new value "" or "" there that the user cannot select from the box themselves.

18. Setup a warehouse (sqlite is easiest), connect to it from the motion planning panel in rviz, go to the robot states tab and add a state. You will have to type a name for it. As users are likely to create multiple related states together and there is no namespacing in the warehouse I propose to set the entered name with a new suffix (e.g., counting up) as the default value when a name for the next state has to be entered.

Already done/PR created:

• geometric::TrajOpt is not implemented but in panda_moveit_config https://github.com/ros-planning/moveit_resources/pull/85
• on replay trajectory panel says "Play" even when the button stops #2737
• The "Joints" tab in the panel should switch its position with the "Manipulation" tab which is basically dead code #2744
• The "Joints" tab will list mimic joints (panda_finger_joint2 for the panda config), but their special state is not visually indicated and clicking on them prints edit: editing failed to the command line #2744
• pilz should only complain about Multi-DOF joints when such a joint should actually be planned for (only shows before https://github.com/ros-planning/moveit_resources/pull/86) - Addressed in #2940
• In the RViz display, the property "Planning Group" under "Planning Request" allows to type in a custom string and goes blank if the string is not a valid group name. I'd propose to simply disallow custom strings here and turn it into a simple drop-down list

[rhaschke]

Why is the XYOrbit view "totally unusable"? I think that's the default in rviz.

[v4hn]

Why is the XYOrbit view "totally unusable"? I think that's the default in rviz.

Yes it is and it's a great choice for mobile robots. I'm not proposing to change it outside MoveIt. For robotic manipulation though most people I know end up looking at the robot from the side instead of the top. If you try to move the camera from a sideways view you end up a long way away from the real robot because of the 2d projection. Also you can't zoom in on the end-effector which is usually the relevant part of the scene.

Of course this is less of a problem if you choose your ground plane to be a table surface, but it's still a bother.

[felixvd]

I agree that Orbit view should be preferred over XYOrbit for the default configs.

[jaskiratsingh2000]

@felixvd @rhaschke I am beginner starting with the code contribution and super interested to contribute to this repo. So please please redirect me to beginner-friendly issues. I am looking forward to hearing from you. Thanks

[rhaschke]

@jaskiratsingh2000, good first-timer issues are labeled with good first issue. From the above list, I suggest the following items: 6. The default planner is set here called from here 7. Manually adapt the rviz config in templates based on some real rviz config file. 11. ~~Adapt the ProgressBarEditor to also show units.~~ 10. ~~Allow to drive currently selected joint with left / right keys. To this end, either augment the JointsWidgetEventFilter of the QTreeView or extend the widget itself (the former is probably easier).~~

[AbhiramL]

Was issue 11 for progress editor bar fixed? If not can I help out, Im a beginner in github but I know a good amount of c++ @rhaschke @v4hn

[rhaschke]

The original issue 11 In the joints tab "Nullspace exploration:" is visible even when there is no slider below was fixed via #2944 as indicated by the PR id next to this line. However, there is a related issue mentioned in https://github.com/ros-planning/moveit/issues/2741#issuecomment-881953482 that is still open: Adapt the ProgressBarEditor to also show units. I'm looking forward to your contribution :+1:

[gquey]

is number 15 still available on the list to be fixed? Looking to make a contribution. Thanks!

[rhaschke]

Yes, so far we didn't receive a PR to fix the display of units in the joints tab. @AbhiramL, did you start working on this?

[gquey]

@rhaschke would it be okay if I started working on number 15 then if it is still available? Thanks

[rhaschke]

@gquey, sure! I'm looking forward to your PR.

[mralderman]

I am looking to contribute to this project. I was wondering if any of these issues are still avaliable? @rhaschke

[rhaschke]

Sure. All issues not listed as done should be still available. Before starting, just check whether the latest source build still shows the mentioned problem.

[7Arms]

Greetings @rhaschke , I want to solve one of these issues. Is it possible I could still work on any of the issues listed?

[rhaschke]

As I wrote before: Just pick an issue, verify that it is still pending, mark the issue as being worked on and start. We are looking forward to your contribution! If you have questions, please open a new issue for them.

[aaryanmurgunde]

Hi, I would like to work on the following issue, where can I find the relevant piece of code ?

(Update) Found the files, so the conclusion is to add a check box to show the joint angles in radians right ?

14. In the "Joints" tab, joint values are given in degree. Some people think this is the correct way to show things to the user. But, in addition to this being a debatable choice, this makes it awful to set values from debugging output (in rad) to look at the robot state visually. As there are two clear opinions on this issue, I would propose to add a checkbox to switch units.

[Jscastro197]

Can I still work on these issues? & do i need to create a new issue to get the relevant piece of code ?