-
Notifications
You must be signed in to change notification settings - Fork 958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up Rviz plugin, fix mesh scaling #2142
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2142 +/- ##
==========================================
- Coverage 57.97% 57.96% -0.02%
==========================================
Files 327 327
Lines 25676 25676
==========================================
- Hits 14885 14882 -3
- Misses 10791 10794 +3
Continue to review full report at Codecov.
|
There are no screenshots and CI failed. :) |
I mixed up the screenshots and only uploaded the one in the other thread. I fixed the OP. I think the new commit fixes the build warning, but I don't see the warning locally either way. Do I have to enable something to show it? |
We are building MoveIt on Travis with flags |
Thanks. Is that worth adding to the doc somewhere? |
💯 This is a great idea! I ran into this issue myself when I was trying to create a realistic planning scene by populating it with some meshes I had downloaded. Besides scaling, you could also add some logic for positioning: if the bounding box of the imported mesh doesn't overlap with the bounding box of the current planning scene, ask the user whether the imported mesh should be centered in the current scene. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the need to renaming all the code symbols. However, I see your point that the UI should be improved.
@@ -172,8 +172,8 @@ private Q_SLOTS: | |||
void onClearOctomapClicked(); | |||
|
|||
// Scene Objects tab | |||
void importFileButtonClicked(); | |||
void importUrlButtonClicked(); | |||
void import3DObjectFromFileButtonClicked(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, you should revert renamings of all (internal) symbols. At most, I agree with importFrom[File|Url]...
If you want to clarify (for the user) that a single object (instead of a full scene) is imported, provide a tooltip to the corresponding buttons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd go for "Object" over "3DObject", but I would like to separate a saved Scene from a saved Object more clearly. Is there a reason not to be descriptive?
I think the fact that these functions are closely related and somewhat easy to confuse is hinted at by computeLoadSceneButton
being defined in motion_planning_frame_objects.cpp
instead of motion_planning_frame_scenes.cpp
. I assume the separation was introduced later during development.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should distinguish scene and object loading/saving if needed. But can we actually import a whole scene?
If so, the corresponding symbols should be renamed to scene as well?
However, if there is only object loading, why should we rename the symbols?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's sufficiently messy to clear up. There are:
import_file_button
which connects toimportFileButtonClicked
and imports a meshimport_url_button
which connects toimportURLButtonClicked
and imports a meshimport_scene_text_button
which connects toimportFromTextButtonClicked
and imports a .scene file (containing scene geometry (shapes), but no other info)load_scene_button
which connects toloadSceneButtonClicked
which loads a scene frommoveit_warehouse
(I don't know if this actually works)load_state_button
which connects toloadStateButtonClicked
and loads robot states (not necessarily clear to first-time codebase readers that this is only the robot state, not the state of the scene)load_query_button
which loads planning queries, and a few correspondingsave
buttons.
The symbols are all in the same big motion_planning_frame
file, so I think they should be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned below, I renamed some more of these.
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame_objects.cpp
Outdated
Show resolved
Hide resolved
<property name="text"> | ||
<string>Import &File</string> | ||
<string>Import &Object</string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An "object" is imported in both cases. Hence, "File" to indicate that we import from file was correct, wasn't it? Please revert and better use tooltips if you want to be more specific.
<string>Import &Object</string> | |
<string>Import &File</string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find the hint that this imports a mesh rather than some other format (a scene? a YAML? some other list of objects?) is hard to discover. I think it should be more visible than a tooltip. How about Import Mesh
?
To be clear, the problem is not that the button is incorrect, it's that it doesn't convey what a common user would be looking for or understand at first sight. Reading "Import File" as a new user makes me think "What kind of file? Ugh, I'll look into it later", "Import Mesh" makes me think "Oh cool, now I know I can do that".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The key point is that both buttons essentially import an object mesh, once from a local file, once from an url.
Hence the button names should distinguish file and url.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, it is a bit of a break in consistency, but I value the discoverability higher. The current state leaves the arguably most important piece of information ("this imports an object mesh") unspoken.
I would prefer to express the main function on the more common button and let the user discover the secondary option via tooltips/dialogue details. E.g. one button "Import Mesh" with tooltip "Import mesh from file" and one button "From URL" with tooltip "Import mesh from URL".
I am making the silent assumption here that importing via URL is uncommon, but I think it's a reasonable one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The whole GUI block is dealing with objects only as indicated by the frame header "Curren Scene Objects". As said above, changing the button text from file to object obscures the fact, that we will load from a file in contrast to from url.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my experience that's not enough to indicate what the button does. It could also mean "Import Scene Objects", for example. The word "Mesh" is more important than "File" in my opinion, and would make the button a lot more expressive.
Another argument: This Import File
button in the Current Scene Objects
frame does not actually import a "Scene Object", it imports a mesh, and the button that actually imports a "Scene Object" (or multiple ones) is Import From Text
in the Scene Geometry
tab.
I just committed an alternative, will post the pictures below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I really like this idea.
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I approve like this. Would be great to augment file filters as suggested.
<property name="text"> | ||
<string>Import &File</string> | ||
<string>Import &Mesh</string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think that file would be better here.
I added the file filter and fixed the scaling problem, which occurred because mesh scaling keeps the mesh's centroid constant, but the mesh centroid was not at the center of the interactive marker. It's fixable as discussed here, but considering that scaling is unlikely to be a very common operation, and there are more things to consider when scaling multi-shape objects, I would probably just leave it as is. For now, meshes imported via the Rviz plugin are shifted so that the center point is at the origin. edit: And I renamed some more buttons and functions because I thought this is not a good way to be. |
Is Travis failing because CHOMP timed out? I tried building with the warnings enabled and ran clang-format and clang-tidy. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more remarks regarding the variable renamings...
...tion_planning_rviz_plugin/include/moveit/motion_planning_rviz_plugin/motion_planning_frame.h
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
...it_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui
Outdated
Show resolved
Hide resolved
...it_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui
Outdated
Show resolved
Hide resolved
The build just passed, looks like it failed on a CHOMP test before. |
I fixed the comments, the misnamed button "Filter" and changed "State" to "Robot State" in the frame titles since there was space and it is not self-evident that the tab is about robot states. Maybe we should stop before we iterate through the whole plugin. My thoughts on changes that could be a good WMD or newcomer issue:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More comments, sorry.
...it_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui
Outdated
Show resolved
Hide resolved
@@ -245,8 +245,21 @@ void MotionPlanningFrame::removeStateButtonClicked() | |||
|
|||
void MotionPlanningFrame::clearStatesButtonClicked() | |||
{ | |||
robot_states_.clear(); | |||
populateRobotStatesList(); | |||
QMessageBox msg_box; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why introducing a security message box, if the data is only removed from memory?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmation dialogues in front of destructive operations are just prudent, in my opinion. You never know how many states the user has stored, or if they misunderstood the button. Consider non-native speakers, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For me, confirmation dialogues are just annoying 😉
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
moveit_ros/visualization/motion_planning_rviz_plugin/src/motion_planning_frame.cpp
Outdated
Show resolved
Hide resolved
break; | ||
default: | ||
return; // Pressed cancel, do nothing | ||
// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please cleanup this comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed and rebased
clang-format
Fix comment
2c56b69
to
840e75d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the "Import File" vs. "Import Mesh" button text, I approve.
And I'm in favor of "Import Mesh" and happy to see it merged 😎 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about proposing to drop the URL import altogether - it's not like click, download, select file is much of a hassle and it's a good idea to have the file stored locally anyway.
But then, there's no harm in having the button there and it keeps the grid symmetry 😎
The current patch looks good to me. I'll merge.
Thanks to both of you for all these iterations |
* Clarify object importing * Add suggestion (LARGE_MESH_THRESHOLD) * Add file filter * Add tooltip, clarify names * Fix and clarify names in robot states tab * Add dialogue to Clear button in robot states (cherry picked from commit 5af7258)
* Clarify object importing * Add suggestion (LARGE_MESH_THRESHOLD) * Add file filter * Add tooltip, clarify names * Fix and clarify names in robot states tab * Add dialogue to Clear button in robot states (cherry picked from commit 5af7258)
…gRequestAdapterChain classes (moveit#2142) * Cleanups * Add documentation and more cleanups * Revert size_t change
Description
While reviewing #2137, I realized that the Rviz panel has an option to import meshes that I have never discovered, because the buttons and dialog windows are not very instructive.
This PR should clarify the interface as shown in the screenshot below, and adds a dialog to fix STL files that are encoded with mm units. Sadly, scaling the mesh did not work as I expected, as described here. I will remove the WIP when that's fixed.
Checklist