add list of default capabilities #359
Conversation
|
Format checking failed and I expected that: Now I could change that, but I kinda disagree with the formatter here. This is independent of the actual content of this request though, so feel free to ignore this error during review. |
|
+1. |
|
@rhaschke beat me to the response - I occasionally disagree with clang and use those commands, yes. Documented: ros-planning/moveit.ros.org#106 |
v4hn
force-pushed
the
pr-kinetic-default-capabilities
branch
from
3990e23
to
b376520
Compare
Functionality in MoveIt!'s move_group node is implemented in terms of MoveGroupCapability plugins. But until now the choice of which plugins are loaded was solely left to the user who in many cases is not familiar with these plugins at all. This entails that whenever we introduce or change a basic capability we have to annoy the user with warnings on startup that bug him to change and/or update his move_group.launch file. This commit changes the startup behavior of move_group to load a specified list of default capabilities and provides a new ROS parameter `disable_capabilities` that can be used to disable default plugins. Fixes ros-planning#125.
|
On Tue, Nov 15, 2016 at 07:58:53AM -0800, Dave Coleman wrote:
Good to know, thanks @rhaschke! I updated the commit |
| @@ -41,6 +41,25 @@ | |||
|
|
|||
| namespace move_group | |||
| { | |||
| // These capabilities are loaded unless listed in disable_capabilities | |||
| // clang-format off | |||
| static const char* DEFAULT_CAPABILITIES[] = { | |||
There was a problem hiding this comment.
is char* really the best option here? MoveIt! almost always uses std::string - and this structure gets inserted into an std::string set
There was a problem hiding this comment.
I call bike shed. I don't see how this makes any difference.
Incidentally, I used vector<string> before, but this requires braced-initializer-lists from C++11 and I decided to write this standard-agnostic because I'm unsure whether to backport it.
So I changed it to full C-style structure instead.
|
Backporting: the adverse affect I see is that users who purposefully removed a capability in the past, for example because they created their own custom version, will suddenly have it re-enabled during a routine update. But I've never heard of anyone doing this and am not sure what use-cases there are for it. I think if we announce this feature on the mailing list with a small warning, its safe to backport. |
|
ok, merging. |
Functionality in MoveIt!'s move_group node is implemented in terms of MoveGroupCapability plugins. But until now the choice of which plugins are loaded was solely left to the user who in many cases is not familiar with these plugins at all. This entails that whenever we introduce or change a basic capability we have to annoy the user with warnings on startup that bug him to change and/or update his move_group.launch file. This commit changes the startup behavior of move_group to load a specified list of default capabilities and provides a new ROS parameter `disable_capabilities` that can be used to disable default plugins. Fixes ros-planning#125.
Functionality in MoveIt!'s move_group node is implemented in terms of MoveGroupCapability plugins. But until now the choice of which plugins are loaded was solely left to the user who in many cases is not familiar with these plugins at all. This entails that whenever we introduce or change a basic capability we have to annoy the user with warnings on startup that bug him to change and/or update his move_group.launch file. This commit changes the startup behavior of move_group to load a specified list of default capabilities and provides a new ROS parameter `disable_capabilities` that can be used to disable default plugins. Fixes ros-planning#125.
Functionality in MoveIt!'s move_group node is implemented in terms of MoveGroupCapability plugins. But until now the choice of which plugins are loaded was solely left to the user who in many cases is not familiar with these plugins at all. This entails that whenever we introduce or change a basic capability we have to annoy the user with warnings on startup that bug him to change and/or update his move_group.launch file. This commit changes the startup behavior of move_group to load a specified list of default capabilities and provides a new ROS parameter `disable_capabilities` that can be used to disable default plugins. Fixes #125.
* Add forward_trajectory local solver plugin (ros-planning#359) * Use ros2_control based joint simulation and remove unnecessary comment * Update copyrights * Restructure hybrid planning package * Fix formatting and add missing time stamp in local solver plugin * Remove unnecessary logging and param loading * Enable different interfaces between local planner and controller * Use JointGroupPositionController as demo hardware controller
Functionality in MoveIt!'s move_group node is implemented in terms of
MoveGroupCapability plugins. But until now the choice of which plugins
are loaded was solely left to the user who in many cases is not familiar
with these plugins at all. This entails that whenever we introduce or change
a basic capability we have to annoy the user with warnings on startup that
bug her/him to change and/or update his move_group.launch file.
This commit changes the startup behavior of move_group to load a specified
list of default capabilities and provides a new ROS parameter
disable_capabilitiesthat can be used to disable default plugins.
I'm unsure about whether or not we should backport this to indigo/jade.
Personally I'm mildly in favor of backporting.
Fixes #125.