add ApplyPlanningSceneService capability #686
Conversation
|
This obviously depends on ros-planning/moveit_msgs#21 |
| * POSSIBILITY OF SUCH DAMAGE. | ||
| *********************************************************************/ | ||
|
|
||
| /* Author: Michael 'v4hn' Goerner */ |
There was a problem hiding this comment.
im a big fan of descriptions in header files for what the class does....
There was a problem hiding this comment.
On Mon, Jun 13, 2016 at 03:41:28PM -0700, Dave Coleman wrote:
im a big fan of descriptions in header files for what the class does....
Now you're being unfair. :)
I totally agree, but none of the other capabilities include a description
and I wouldn't even know what to describe here, as it's pretty self-documenting.
"ApplyPlanningSceneService : MoveGroupCapability is a MoveGroupCapability
that provides a service to apply a given PlanningScene" is just overly redundant.
There was a problem hiding this comment.
You are exactly right about not having enough documentation throughout the code base and I know the others lack it. How about:
"Provides ability to update the shared planning scene with a remote blocking call"
|
@davetcoleman: now this request also spans 4 repos :-) I do care quite a lot about a compatible ABI within ros distros until we add sonames to our libraries to explicitly mark updates as ABI-breaking. Any comments on the question of namespacing? |
| if (!scene_) | ||
| return false; | ||
|
|
||
| bool ret; |
|
i don't have an opinion on the namespacing, other than we should do it as the other services have been done. i don't know of any current uses cases needing more than one planning scene |
v4hn
force-pushed
the
apply-planning-scene
branch
3 times, most recently
from
e19bc02
to
ebd8565
Compare
|
Ok, I renamed all the |
|
I'll merge these as soon as @mikeferguson gives me a +1 on the moveit_msgs change. Until then, could you add a section to the documentation here mentioning this new way to update the PS? It doesn't need to be much. |
|
@davetcoleman -- we need to merge the moveit_msgs and then release it as Debs so that this can properly build, else the CI will be broken |
|
just restarted build after merging msgs and core |
This is required for capabilities to update the planning scene. ABI-compatible.
This new capability allows to apply changes to a monitored planning
scene and *blocks* until the changes are applied. This is meant to
replace the quasi-standard pattern:
```
planning_scene_interface.addCollisionObjects(...)
sleep(2.0)
group.pick("object")
```
by
```
ros::ServiceClient client = n.serviceClient<moveit_msgs::ApplyPlanningScene>("apply_planning_scene");
client.call(...)
group.pick("object")
```
This makes it much more convenient to add&interact with objects
without useless and arbitrarily long sleeps to ensure planning scene
updates succeeded.
v4hn
force-pushed
the
apply-planning-scene
branch
from
ebd8565
to
1e03977
Compare
See https://groups.google.com/forum/#!topic/moveit-users/D7MWZEUSKLc
for a longer discussion on why this makes sense to have around.
The only thing I'm unsure about is whether the service should be
~-namespaced or not. There might be multiple monitored scenesaround, so I moved it to the namespace. On the other hand,
the ClearOctomap service is not namespaced...