Skip to content
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

select planning group in planning tab and simplify selecting goal and start states #1198

Merged
merged 3 commits into from
Nov 27, 2018

Conversation

2scholz
Copy link
Contributor

@2scholz 2scholz commented Nov 13, 2018

Fixes #1069.

The request consists of multiple commits.

The first one fixes rviz crashing when the planning group is changed while executing a trajectory.
The problem was the destruction of a MoveGroupInterface that also holds the SimpleActionClient used to execute the trajectory. The proposed solution here creates a local shared pointer of the object for execution to ensure that the object is not destroyed asynchronously.

The other two commits change the gui in the planning tab.
This is the old state of the planning tab:
old_gui

The first addition is a dropdown menu for choosing a planning group:
partial_change
Previously it was only possible to choose the planning group in the MotionPlanning display. The dropdown menu is synchronized with the display property.

The final commit tries to streamline the interface and should improve usability further. It gets rid of the update buttons and makes both dropdown menus for the start and goal state constantly visible:
full_change

The choice is instantly confirmed when it is clicked in the dropdown menu. As a consequence repeatedly updating random states is now a bit more complicated, but still possible by simply clicking on that option repeatedly.

@v4hn

Copy link
Contributor

@v4hn v4hn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! That's so much more usable! Thank you a lot for improving this @2scholz !

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I approve this. Great job!
There is only a small nitpick to further improve the code.

void MotionPlanningFrame::fillStateSelectionOptions()
{
ui_->start_state_selection->clear();
ui_->goal_state_selection->clear();
ui_->start_state_combo_box->blockSignals(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a nice utility class taking care of unblocking signals automatically: QSignalBlocker.

ui_->start_state_combo_box->blockSignals(false);
ui_->goal_state_combo_box->blockSignals(false);
ui_->start_state_combo_box->setCurrentIndex(2); // default to 'current'
ui_->goal_state_combo_box->setCurrentIndex(2); // default to 'current'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you changed the default intentionally here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was indeed an intentional change.
The goal state is always the current state after the planning group was changed and I think the combo box should reflect this.

ui_->goal_state_combo_box->blockSignals(false);
ui_->start_state_combo_box->setCurrentIndex(2); // default to 'current'
ui_->goal_state_combo_box->setCurrentIndex(2); // default to 'current'
ui_->planning_group_combo_box->setCurrentText(QString::fromStdString(group)); // currently chosen group
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need to touch the planning_group_combo_box?
Semantically this doesn't fit into fillStateSelectionOptions().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is needed to update the combo box, whenever the planning group is changed via the display property.

I deleted this line and replaced the functionality by calling fillPlanningGroupOptions() in changePlanningGroupHelper() instead.
Let me know if you would prefer a seperate function that only chooses the correct planning group instead of retrieving the planning groups and refilling the combo box at each change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. The planning_group_combo_box only needs to be updated once when the RobotModel was loaded. I implemented and pushed the corresponding fix to your PR branch. @2scholz, please have a final look and rebase onto current melodic-devel.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense to only fill the options of the planning_group_combo_box once when the RobotModel is loaded.
But this breaks the synchronization between the property in the MotionPlanningDisplay and the drop-down menu in the panel. Whenever the planning group is changed via the property, the drop-down menu does not show the currently selected group anymore.

To fix this I added the method setPlanningGroupText to update the index of the planning_group_combo_box. It is used in the changePlanningGroupHelper.

ui_->start_state_selection->setCurrentIndex(2); // default to 'current'
ui_->goal_state_selection->setCurrentIndex(0); // default to 'random valid'

ui_->start_state_combo_box->blockSignals(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are obsolete when using QSignalBlocker :-)

Copy link
Contributor

@rhaschke rhaschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix the following uic errors:

/root/ws_moveit/src/moveit/moveit_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui: Warning: Tab-stop assignment: 'start_state_selection' is not a valid widget.
/root/ws_moveit/src/moveit/moveit_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui: Warning: Tab-stop assignment: 'use_start_state_button' is not a valid widget.
/root/ws_moveit/src/moveit/moveit_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui: Warning: Tab-stop assignment: 'goal_state_selection' is not a valid widget.
/root/ws_moveit/src/moveit/moveit_ros/visualization/motion_planning_rviz_plugin/src/ui/motion_planning_rviz_plugin_frame.ui: Warning: Tab-stop assignment: 'use_goal_state_button' is not a valid widget.

@rhaschke
Copy link
Contributor

As a consequence repeatedly updating random states is now a bit more complicated, but still possible by simply clicking on that option repeatedly [twice].

This is indeed more laborious now. However, I didn't used random postures much in the past...

@2scholz 2scholz force-pushed the rviz_ui_simplification branch 2 times, most recently from ebc920b to 188f82c Compare November 16, 2018 16:02
@rhaschke
Copy link
Contributor

@2scholz Please have a look at #1198 (comment)

@rhaschke rhaschke mentioned this pull request Nov 26, 2018
12 tasks
changing the planning group destroyed the MoveGroupInterface which
also destroyed the SimpleActionClient used to execute the trajectory.
A shared pointer is now used to ensure that the object exists until the
end of the execution of the trajectory.
@2scholz 2scholz force-pushed the rviz_ui_simplification branch 2 times, most recently from 63a608b to 76d4c33 Compare November 26, 2018 16:28
@@ -260,6 +260,12 @@ void MotionPlanningFrame::fillPlanningGroupOptions()
ui_->planning_group_combo_box->addItem(QString::fromStdString(group_name));
}

void MotionPlanningFrame::setPlanningGroupText()
{
const QSignalBlocker planning_group_blocker(ui_->planning_group_combo_box);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, you don't need to block signals here. setCurrentText only sends a new signal, when the text actually changed.

@rhaschke
Copy link
Contributor

@2scholz Can you please also cleanup the commit history? I would like to keep your three initial commits but suggest to squash the fixup commits into the last one.

Benjamin Scholz added 2 commits November 27, 2018 15:35
simplifies choosing a planning group.
The group is chosen via dropdown menu.

The combo box is synchronized with the one in the MotionPlanning display
under Planning Request, so that both boxes will always show the same
value.
The update buttons were removed and the goal and start state are now
updated directly after an option was clicked in the combo box.
Random states can be updated by clicking on that choice repeatedly.

The combo boxes were previously in a QToolBox where only one of the
selections was visible at a time.
Because the removal of the update buttons saves a lot of space the
QToolBox was removed as well, so that both combo boxes are visible at
all times.
@2scholz
Copy link
Contributor Author

2scholz commented Nov 27, 2018

I removed the signal blocker in setPlanningGroupText and cleaned up the commit history.

@rhaschke rhaschke merged commit 15e52cd into moveit:melodic-devel Nov 27, 2018
@davetcoleman
Copy link
Member

@2scholz thanks for this contribution!

Can you please update the melodic tutorials to reflect the new location of the planning group option? See

In Planning Request, change the Planning Group to panda_arm.

https://ros-planning.github.io/moveit_tutorials/doc/quickstart_in_rviz/quickstart_in_rviz_tutorial.html

rhaschke pushed a commit that referenced this pull request Apr 29, 2022
Rviz crashed when switching the move group while a motion was being executed through the plan and execute button.
The same issue was already fixed for the execute button (#1198) and is now also fixed for the plan and execute button.
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants