Skip to content
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.

Use custom robot collision padding in occupancy map shape padding #509

Open
wants to merge 2 commits into
base: indigo-devel
Choose a base branch
from
Open

Use custom robot collision padding in occupancy map shape padding #509

wants to merge 2 commits into from

Conversation

davetcoleman
Copy link
Member

Currently you can only use one padding and scale value for all robot self-filtering. I have an application where the fingers and end effector should have no padding or scaling, but I'd like the rest of the robot to still have padding.

This change uses the same variable collision padding as set in the planning scene monitor for the perception pipeline. Does not change API because the new function parameters have default values.

This does break user's current sensors_rgbd.yaml files in that it will not longer use padding from there, but instead from paddings.yaml file.

I'd also be happy to create default configuration files for the Setup Assistant for these changes.

@@ -593,6 +593,10 @@ void planning_scene_monitor::PlanningSceneMonitor::excludeRobotLinksFromOctree()
const std::vector<const robot_model::LinkModel*> &links = getRobotModel()->getLinkModelsWithCollisionGeometry();
for (std::size_t i = 0 ; i < links.size() ; ++i)
{
const double &link_padding = getPlanningScene()->getCollisionRobot()->getLinkPadding(links[i]->getName());
const double &link_scale = getPlanningScene()->getCollisionRobot()->getLinkScale(links[i]->getName());
std::cout << "link " << links[i]->getName() << " has padding " << link_padding << " and scale " << link_scale << std::endl;
Copy link
Contributor

Choose a reason for hiding this comment

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

This line seems spammy -- should probably be a ros debug or something.

Copy link
Member Author

Choose a reason for hiding this comment

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

It totally is, good catch!

@mikeferguson
Copy link
Contributor

+1, as long as docs also get updated (although, I'm not even sure where the docs are anymore...)

@davetcoleman davetcoleman deleted the occupancy_map_variable_padding branch December 11, 2014 02:26
@davetcoleman davetcoleman restored the occupancy_map_variable_padding branch December 11, 2014 02:51
@davetcoleman davetcoleman reopened this Dec 11, 2014
@davetcoleman
Copy link
Member Author

Would be great if someone was interested in porting this PR to the new repo, but I have lost interest in it so will close it for now.

@v4hn v4hn reopened this Sep 8, 2016
@v4hn
Copy link
Contributor

v4hn commented Sep 8, 2016

@davetcoleman I do not think it is a good idea to just close contributions that worked at some point.
I don't think there is anything wrong with keeping the request open over here.
In case someone becomes interested in it again (it is a perfectly valid issue), he will find it more easily

@davetcoleman
Copy link
Member Author

Sure no problem, though its my PR so can close as I wish ;-)

otamachan pushed a commit to otamachan/moveit_ros that referenced this pull request Oct 22, 2017
…eit#509)

**Issue**
When editing an existing moveit_config pkg, MSA opens the location of MSA packace, which is useless.

**Approach with the suggested change**
Opens the "current" directory where `setup_assistant.launch` was started, which is often where the existing moveit_config package you'd like to edit is located.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants