Align endeffector of robot with vector

Hi!

as it says in the header I want to align my endeffector with a vector in space. In my case the z-axis of the EE should be aligned with the vector. This means that the x-, and y-axis are not specified.

Right now I only manage to navigate the EE to a certain pose where the x-, y-, and z-axis are all determined. But sometimes the robot cannot reach this pose due to collisions or being out of reach. A simple turn around the z-axis would do the trick that the pose can be reached and still the goal "aligning with the vector" is achieved.

My question: Is there an implementation in ROS or particularly in Moveit to automatically solve this?

Best regards!

Edit:

My approach right now is to calculate the path to the target with angles from -180° till +180° in steps of 10° (All of them fullfill the requirement of alignment with the vector, but not all of them are possible for the robot). After that I know which angels are possible and can choose. But this takes some minutes as I have to set up the planner each time.

So again the question: I'm looking for a way to this faster. And maybe there is an implementation? For example constraints for the target pose or something?

edit retag close merge delete

Hey bluefish, I know the questin is rather old, but could you tell me a bit of how you managed it to align your end-effector with a given vector? I tried to getRPY->CurrentVector (using sin, cos) -> create quaternion between CurrentVector <> given goal vector. Failed due to wrong current vector...

( 2017-02-03 08:40:55 -0500 )edit

Sort by » oldest newest most voted

Perhaps you can use the goal tolerance part of the planning request for this. See MotionPlanRequest: Setting up a Pose Request - Define a tolerance on the MoveIt wiki.

Edit:

Hi, thanks for your answer! This solution really seems to be interesting. However the C++API described here seems to different to the one described on the moveit-c++-tutorial.

Can I use them side by side? Using the move-group-interface there I can just find the command group.setGoalTolerance(0.001), which sets both angle and position tolerance at the same time, I think

Oh! No I was wrong! There is also group.setGoalOrientationTolerance(). But there I can't limit the tolerance to one angle around an axis, can I?

The page I linked is a bit more low-level. The page you linked describes using moveit_msgs::OrientationConstraint, but as far as I know such a constraint will influence planning of the whole trajectory, not just the state at the end. The methods you mention don't seem to support what you want. From the moveit::planning_interface::MoveGroup::setGoalTolerance docs:

Set the tolerance that is used for reaching the goal. For joint state goals, this will be distance for each joint, in the configuration space (radians or meters depending on joint type). For pose goals this will be the radius of a sphere where the end-effector must reach. [..]

I don't think this can then be used to express a rotational tolerance around a single axis.

Perhaps you could use the Descartes planner from ROS-Industrial for your use case. Afaiu that does support 'toleranced frames', which could be used to indicate a "don't care" for orientation along a particular axis. See wiki/descartes_trajectory - AxialSymmetricPt.

more

Hi, thanks for your answer! This solution really seems to be interesting. However the C++API described here seems to different to the one described on the moveit-c++-tutorial.

( 2015-05-08 02:45:35 -0500 )edit

Can I use them side by side? Using the move-group-interface there I can just find the command group.setGoalTolerance(0.001);, which sets both angle and position tolerance at the same time, I think

( 2015-05-08 02:48:03 -0500 )edit

Oh! No I was wrong! There is also group.setGoalOrientationTolerance();. But there I can't limit the tolerance to one angle around an axis, can I?

( 2015-05-08 02:50:52 -0500 )edit

that sounds really like what I'm looking for. I'll try it and will report :)

( 2015-05-11 05:40:25 -0500 )edit

Hi! I didn't manage to set up the descartes package. However, I came up with another solution. Again I turn around the axis in steps of 10°. But this time I use the InverseKinematik. This takes only 1 or 2 seconds and perfectly suits for my implementation. Thanks for your support!!

( 2015-05-20 03:12:39 -0500 )edit

Ok. Did you encounter specific difficulties getting it to work? It would be very valuable if you could report those then.

( 2015-05-20 04:53:18 -0500 )edit

I stated my problem here. However, I didn't try to hard to solve it, as I found another convenient solution for my problem regarding aligning with the vector. Anyway thanks again @gvdhoorn for help on all channels!!

( 2015-05-21 05:37:51 -0500 )edit

You can align the end effector without actually specifying the whole pose. Let's say we keep the position but only set the orientation of the end effector.

Here in python the solution by modifying a bit the moveit tutorial :

pose_target = geometry_msgs.msg.Pose()
# Then set pose_target position as the current position
pose_target.position=group.get_current_pose().pose.position

# Then set orientation as you want
pose_target.orientation.w = 1.0
group.set_pose_target(pose_target)
# Planning
plan1 = group.plan()
group.go()


I don't know if it's really what you want but that's the first solution I have in mind

more

Hi! Thanks for your answer. I tried your approach. The problem is that the orientation values are automatically set to 0.0 when not specified. Then the pose is fully determined again and no automatic turn around the target-vector is possible.

( 2015-05-07 10:13:14 -0500 )edit

You can set the orientation quaternion in the direction you want. You can look at function to transform orientation from roll pitch yaw to quaternion. This link for example http://answers.ros.org/question/69754...

( 2015-05-07 20:43:25 -0500 )edit

I'm not sure you got me right. I know how to set the direction and I know how to set it right to align with the vector. But setting the orientation completely means that the system is over-determined for this problem. Cause the EE is aligned when 0° turned around the z-axis but also when 90° turned.

( 2015-05-08 01:21:00 -0500 )edit

I added some lines to the question to clarify the problem.

( 2015-05-08 01:38:02 -0500 )edit