-
Notifications
You must be signed in to change notification settings - Fork 943
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
select planning group in planning tab and simplify selecting goal and start states #1198
Conversation
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.
Yes! That's so much more usable! Thank you a lot for improving this @2scholz !
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.
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); |
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 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' |
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.
Did you changed the default intentionally here?
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.
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 |
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 do you need to touch the planning_group_combo_box
?
Semantically this doesn't fit into fillStateSelectionOptions()
.
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.
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.
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.
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.
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.
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); |
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.
These are obsolete when using QSignalBlocker :-)
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 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.
This is indeed more laborious now. However, I didn't used random postures much in the past... |
ebc920b
to
188f82c
Compare
@2scholz Please have a look at #1198 (comment) |
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.
63a608b
to
76d4c33
Compare
@@ -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); |
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, you don't need to block signals here. setCurrentText
only sends a new signal, when the text actually changed.
@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. |
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.
76d4c33
to
cafe7f2
Compare
I removed the signal blocker in |
@2scholz thanks for this contribution! Can you please update the melodic tutorials to reflect the new location of the planning group option? See
|
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.
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:
The first addition is a dropdown menu for choosing a planning group:
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:
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