New moveit_kinematics package consolidates IK solvers #247
Conversation
davetcoleman
force-pushed
the
kinetic-kinematic-pkg
branch
from
d2a2045
to
a77da3d
Compare
|
Impopular maybe, but I'm not convinced that placing |
davetcoleman
force-pushed
the
kinetic-kinematic-pkg
branch
2 times, most recently
from
30d6bfd
to
9450fea
Compare
|
Ready to merge |
| @@ -0,0 +1,9 @@ | |||
| # MoveIt! IKFast | |||
There was a problem hiding this comment.
This file shows as if it was added rather than moved, not sure that it can be easily fixed but it be nice if it kept the history.
There was a problem hiding this comment.
ive restored the file to its original state so that it can be tracked
|
|
||
| Generates a IKFast kinematics plugin for MoveIt using [OpenRave](http://openrave.org/) generated cpp files. | ||
|
|
||
| Tested on ROS Hydro and greater with Catkin using OpenRave 0.8 with a 6dof and 7dof robot arm manipulator. Does not work with greater than 7dof. |
There was a problem hiding this comment.
I know this PR is about rearranging packages but I'm not sure that this line still makes sense to keep as it has to have been tested for this code to make it into the main development branch.
There was a problem hiding this comment.
this should be changed/discussed in a different PR.
| <run_depend>moveit_core</run_depend> | ||
| <run_depend>pluginlib</run_depend> | ||
| <run_depend>actionlib</run_depend> | ||
| <run_depend>angles</run_depend> |
There was a problem hiding this comment.
Is angles not a build dependency also?
There was a problem hiding this comment.
I feel that openrave should be listed as a run dependency since the ikfast script won't be able to do anything without the solution generated by openrave.
There was a problem hiding this comment.
good catch on the angles run_depend, it should not be there (removed)
There was a problem hiding this comment.
openrave definitely should not be added as a dependency
- it would be huge install requirement imposed on all moveit users
- they haven't kept up releasing with the latest Ubuntu versions AFAIK
- openrave is only needed once during header file generation, after which a generated ikfast plugin can be used indefinitely without openrave
- our documentation explains to users how to manually install openrave
davetcoleman
force-pushed
the
kinetic-kinematic-pkg
branch
3 times, most recently
from
6e6ba0e
to
776c5f6
Compare
|
I agree with you on the dependency burden that it would cause. Since there
|
|
@jrgnicho wrote:
OpenRAVE installation on anything but Ubuntu 12.04 is notoriously difficult / involved (see the many installation related issues on the OpenRAVE tracker). I've used a Docker image in the past to avoid all that. Related: rdiankov/openrave#394. |
davetcoleman
force-pushed
the
kinetic-kinematic-pkg
branch
from
776c5f6
to
0f0ca09
Compare
|
@gavanderhoorn I now remember running into this issue with OpenRave a while ago. @davetcoleman it feels to me that there isn't much of a point in having the ikfast scripts in indigo, jade or kinetic if they can't be used unless a rather involved workaround is used as suggested by @gavanderhoorn . The alternative to not having ikfast is to grab the ik generating code from OpenRave and build it into moveit_kinematics, I realize this would be non trivial but it's perhaps the right approach. |
|
I've had some success using personalrobotics/ros-openrave. Not sure whether we want to depend on an outside image, but it might be an idea.
I'm not sure that would be feasible. I've seen people install just enough to get the kinematics solver generation working, but extracting it would be a something else entirely. |
|
@k-okada just recently updated our tutorials for Ubuntu 14.04 using the newly released binary packages of OpenRave, so it is working in indigo and hopefully soon 16.04. You can also still install OpenRave from source for 16.04, so there is value in having the ikfast code.
This would be extremely hard (I started on that task years ago), as Rosen's coding style is difficult and he also uses a different robot model format (Collada). We've long been happy with the moveit_ikfast package, but since the repo merge we haven't been able to release it because its version number was too high (3.x). This is the workaround suggested by @v4hn . I wasn't trying to debate the existence of moveit_ikfast in this PR, but merely move it from its current location in |
|
Note Travis is passing for shadow-fixed, so should be merged even though #257 hasn't been merged in |
|
@davetcoleman sounds like there are viable ways to run the openrave ik generator from what you described. I'm ok with the changes here, however shouldn't travis be entirely error free before merging? |
|
In this case no - Travis will not pass on the non-shadow-fixed build until the next build farm sync. Click on "Details" next to the failed build, above, and you'll see the shadow-fixed passed. If someone would merge #257 Travis would pass, also... But I'd rather just merge this now |
|
thanks for the cleanup @davetcoleman! |
Addresses the versioning issue for moveit_ikfast and the idea proposed in #67
Because we are just moving plugins this does not break any dependencies.
I have changed no code for any of the plugins, simply moved them to a new location within the moveit repo. This will allow us to release moveit_ikfast in I/J/K, and therefore should be cherry-picked to all three branches.
I have more plans for the ikfast plugin, but will save them for another PR.