Ask Your Question
1

Current state of Cartesian functionality in MoveIt!

asked 2018-04-25 16:01:54 -0500

BrettHemes gravatar image

Can anyone comment on (or link to) the current state and/or future plans of MoveIt!'s Cartesian functionality? Maybe I am off base or missing something but I feel that MoveIt! lacks in terms of general support for such motions.

I am aware of things like the Cartesian Path Planner Plugin and moveit::planning_interface::MoveGroupInterface::computeCartesianPath but these seems to assume "as fast as possible" motions and/or require subsequent custom time parameterization by the user. What about support for linear moves with Cartesian velocity limits/targets that are supported by basically all industrial robot controller (e.g., movelin, circ, constant velocity splines, blending, etc.).

I would be happy to help develop on such a front (and even have some stuff implemented already) but admittedly don't know what all exists to date or if anything is planned. Is this wanted by the community and, if so, where do I start?

Something to live in moveit_core/trajectory_processing possibly?

edit retag flag offensive close merge delete

Comments

1

I believe this is a topic that is going to be discussed at the next MoveIt maintainers meeting.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 02:00:36 -0500 )edit

Maybe I am off base or missing something but I feel that MoveIt! lacks in terms of general support for such motions.

tbh I've never felt that MoveIt was necessarily 'missing' something here, per se. It's initial design just didn't include this functionality, as it was not part of its ..

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 02:01:38 -0500 )edit

.. functional requirements (ie: planning collision free paths for n-dof systems in joint space, where the destination matters, not the path itself necessarily). With the increased usage of ROS (and consequently MoveIt) in more 'industrial' contexts, where Cartesian trajectories are more ..

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 02:02:51 -0500 )edit

.. prevalent, and typically constructed piece-wise from simple motion primitives, the discrepancy between what MoveIt was created for and these new use-cases became more and more noticable.

Not claiming that this should not be addressed, just that there's a rationale for it.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 02:04:31 -0500 )edit

I believe this is a topic that is going to be discussed at the next MoveIt maintainers meeting.

Sounds good; I look forward to hearing the outcome. :)

BrettHemes gravatar imageBrettHemes ( 2018-04-26 08:11:28 -0500 )edit

tbh I've never felt that MoveIt was necessarily 'missing' something here, per se. It's initial design just didn't include this functionality, as it was not part of its functional requirements

Fair enough, however, I think it belongs somewhere in ROS/ROS-I if not in MoveIt specifically

BrettHemes gravatar imageBrettHemes ( 2018-04-26 08:16:37 -0500 )edit

Oh, I completely agree that this is functionality that we all would like to have. I'm not disagreeing with you there.

I just wanted to mention that this is not supported as it was never really what MoveIt was intended for (or at least, insofar as we can know what it was intended for).

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 09:36:09 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-04-26 08:37:36 -0500

v4hn gravatar image

gvdhoorn:

I believe this is a topic that is going to be discussed at the next MoveIt maintainers meeting.

Partly. I believe Cartesian velocity and splines were not a topic recently. The big topic lately was/is jump detection for IK-based interpolation (i.e. computeCartesianPath).

I pretty much agree with you Brett, more extensions for Cartesian trajectories would enhance MoveIt a lot these days. I know more than one group that claims to "use MoveIt", but never touched the planning functionality. They would appreciate better support for Cartesian trajectories too.

In my opinion, the simplest extension is to implement fixed eef-velocity profiles for the Cartesian path planning service. We just add a full-limits IPTP parameterization there at the moment and adjusting the time profile there to slow down everything to the eef-speed of the slowest trajectory segment is certainly possible. It would be nice to have such a function available in moveit_core/trajectory_processing.

Splines and blending are very high on my personal wish list, but I don't have the resources to look into this myself and it has not been discussed at all where/how to add them in MoveIt. Help there is more than welcome! Just open issues with your ideas and others can provide more input.

One more point that is involved here is that the computeCartesianPath support is not properly integrated as a Planner(Manager) in MoveIt - One side-effect of this is that there is no velocity/acceleration scaling factor for the Cartesian trajectories. Multiple maintainers are unhappy with this situation. Sadly changing this also implies that we need to have some more glue code that is not yet written.

edit flag offensive delete link more

Comments

In my opinion, the simplest extension is to implement fixed eef-velocity profiles for the Cartesian path planning service. We just add a full-limits IPTP parameterization there at the moment and adjusting the time profile there to slow down everything to the eef-speed of the slowest trajectory ...

BrettHemes gravatar imageBrettHemes ( 2018-04-26 08:48:02 -0500 )edit

... segment is certainly possible. It would be nice to have such a function available in moveit_core/trajectory_processing.

I had this approach in mind as well. Currently I am solving analytically the acceleration profiles based on the slowest joint(s) but this is much simpler. I would be

BrettHemes gravatar imageBrettHemes ( 2018-04-26 08:49:05 -0500 )edit

... interested to see the difference in output quality.

BrettHemes gravatar imageBrettHemes ( 2018-04-26 08:49:20 -0500 )edit

@v4hn: I'll be able to make an announcement in a few weeks that could make you happy I believe.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 09:34:15 -0500 )edit

BrettHemes, It would be great to see the difference in quality in some graphs! (together with the implementations of course ;)) Naturally, the analytical approach is more than welcome too. :-)

v4hn gravatar imagev4hn ( 2018-04-26 11:33:25 -0500 )edit

@gvdhoorn: I'm still waiting for your good news on UR. :P But additions to MoveIt are welcome too ;)

v4hn gravatar imagev4hn ( 2018-04-26 11:33:45 -0500 )edit

re: UR: you will be surprised.

gvdhoorn gravatar imagegvdhoorn ( 2018-04-26 11:34:21 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-04-25 16:01:54 -0500

Seen: 508 times

Last updated: Apr 26 '18