Remove pause when connecting rviz to planning scene monitor #1934
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
It makes sense to keep the wait in the
From my point of view this is the actual bug. |
Dale-Koenig
force-pushed
the
remove_get_psm_wait
branch
from
3deac9e
to
0c0396e
Compare
Fair enough, if there's a possibility the sleep is important I guess that's better. I'll change the PR, although I don't really know enough about the background job manager to be confident I'm not doing something terrible. |
|
At first glance I would think moving the request into the background should also add some flag to indicate late initialization (and updating the display/monitor via from topics).
Did you test the change by starting the display without move_group and then starting move_group later?
@rhaschke please have a look.
…On Fri, Mar 06, 2020 at 01:38:11AM -0800, Dale Koenig wrote:
> Requesting the planning scene should be a background job in RViz, updating the status of the display on error.
Fair enough, if there's a possibility the sleep is important I guess that's better. I'll change the PR, although I don't really know enough about the background job manager to be confident I'm not doing something terrible.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1934 (comment)
--
Michael 'v4hn' Görner, M.Sc. Cognitive Science, PhD Student
Universität Hamburg
Faculty of Mathematics, Informatics and Natural Sciences
Department of Informatics
Group Technical Aspects of Multimodal Systems
Vogt-Kölln-Straße 30
D-22527 Hamburg
Room: F-315
Phone: +49 40 42883-2432
Website: https://tams.informatik.uni-hamburg.de/people/goerner/
|
|
My use case doesn't use MoveGroup, I can play around with it later to make
sure. Its possible there's weird behavior if you start move group later
but still within the 5 second timeout
…On Friday, March 6, 2020, Michael Görner ***@***.***> wrote:
At first glance I would think moving the request into the background
should also add some flag to indicate late initialization (and updating the
display/monitor via from topics).
Did you test the change by starting the display without move_group and
then starting move_group later?
@rhaschke please have a look.
On Fri, Mar 06, 2020 at 01:38:11AM -0800, Dale Koenig wrote:
> > Requesting the planning scene should be a background job in RViz,
updating the status of the display on error.
>
> Fair enough, if there's a possibility the sleep is important I guess
that's better. I'll change the PR, although I don't really know enough
about the background job manager to be confident I'm not doing something
terrible.
>
> --
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub:
> #1934 (comment)
--
Michael 'v4hn' Görner, M.Sc. Cognitive Science, PhD Student
Universität Hamburg
Faculty of Mathematics, Informatics and Natural Sciences
Department of Informatics
Group Technical Aspects of Multimodal Systems
Vogt-Kölln-Straße 30
<https://www.google.com/maps/search/Vogt-K%C3%B6lln-Stra%C3%9Fe+30+%0D%0D%0AD-22527+Hamburg+%0D%0D%0A+%0D%0D%0ARoom:+F?entry=gmail&source=g>
D-22527 Hamburg
Room: F-315
Phone: +49 40 42883-2432
Website: https://tams.informatik.uni-hamburg.de/people/goerner/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1934>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMAEPFS3CKM3NQEQQGZADGTRGDA6RANCNFSM4LC3ZTFQ>
.
--
Dale Koenig
Robotics Software Engineer
Rapyuta Robotics
"empowering lives with connected machines"
www.rapyuta-robotics.com
|
v4hn
pushed a commit
to v4hn/moveit
that referenced
this pull request
Mar 30, 2020
v4hn
pushed a commit
to v4hn/moveit
that referenced
this pull request
Mar 31, 2020
v4hn
pushed a commit
to v4hn/moveit
that referenced
this pull request
Mar 31, 2020
sjahr
pushed a commit
to sjahr/moveit
that referenced
this pull request
Jun 21, 2024
* Install moveit_ros_occupancy_map_monitor headers additional directory * Install moveit_ros_perception within additional directory * Install moveit_ros_planning headers within additional directory * Install moveit_ros_planning_interface headers within additional directory * Install moveit_ros_robot_interaction headers within additional directory * Install moveit_ros_visualization headers within additional directory * Install moveit_ros_warehouse headers within additional directory
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When calling
PlanningSceneMonitor::requestPlanningSceneStatethere is a 5 second wait for the service to be connected to a client. This causes rviz to freeze for 5 seconds for each planning scene topic it is listening for whenever you try to connect to it, unless you specifically broadcast those topics before starting rviz.I propose removing this wait entirely, and simply failing if we are not connected. If it is frequently necessary to wait in order to successfully get the full state of the planning scene when only diffs are being published, I suggest at least reducing the wait to a much lower time.Changes to call the planning scene request as a background thread so that it does not freeze rviz.