0
$\begingroup$

Rosanswers logo

Hello~

I have a UR5 which I would like to control in a more direct and continuous manner than what MoveIt allows. I imagine setting a pose/position for the arm's endeffector and through some kinematic magic the arm simply (un-)folds to reach this position (while respecting some velocity/acceleration/joint value limits).

I think I could use ros_control, maybe even an already existing controller for this, but I'm a bit lost in the whole ROS->MoveIt->ros_control->hardware chain and don't know where to start or what to look for (the documentation for most parts is... unhelpful). Also, is there a way to directly talk to a controller?

Thanks in advance, ~


Originally posted by Managarm on ROS Answers with karma: 28 on 2018-01-26

Post score: 1


Original comments

Comment by JuanTelo on 2018-02-02:
Hi, did you manage to implement your idea? I'm trying to do a similiar thing but with the ur10 and I need to define a certain position of the end effector and the robot unfolds to get there. Have you managed this?

Comment by Managarm on 2018-02-02:
@JuanTelo I'm not sure if I'll have time for it. I was thinking of writing a custom controller which listens to a pose topic, calculates the IK solution and then does linear interpolation for the joints (with some de-/acceleration constraints). Let me know if you find/write something!

Comment by JuanTelo on 2018-02-02:
@Managarm I also thought that, write a script in which it would listen to a given pose of the endeffector and calculate the solution of the joints to make it move. My problem is with the IK since I don't have that much experience I'm having some difficulties in getting the IK of the ur5/ur10

Comment by Managarm on 2018-02-03:
@JuanTelo You can use the /compute_ik service for that, which will use the IK solver configured for your robot (for me trac-ik works best). See this answer

Comment by alinwegy on 2023-07-27:
Hi, I know I'm a little bit late to the party, but How is it with implementing your own direct controller. I am trying to do the same for my master thesis. The whole way of controlling the robot with the trajectory action client is not working well for me and I also want to have my custom controller (not a PID). If you managed to find a way would you please give me some tips?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Depending on your exact requirements there is no need for ros_control: most drivers for robot arms in ROS support FollowJointTrajectory actions, which take in a JointTrajectory and execute that.

You can create those JointTrajectory instances yourself, without any planning component involved.

Note: you are now responsible for sanity checking, collision avoidance and detection and trajectory smoothness, as drivers do not typically do any of that.


ros_control can be helpful, if you're looking for a closed-loop approach and wish to do something other than executing trajectories.

And in the case of components like ur_modern_driver: that particular component exposes a /joint_speed topic that accepts joint velocity commands.


Edit:

Unfortunately I don't want to plan ahead

I'm not sure what you mean by this exactly. Robot control is (mostly) reactive in this case, so you'll always be planning, it's just that the timescales are much smaller.

but I was hoping I could leverage ros_control's existing functionality

at least the ur_modern_driver has ros_control capabilities built-in (comes with a `hardware_interface).

That is typically used with a joint_trajectory_controller (which would be trajectory based again), but doesn' t need to be.

I don't have any experience with velocity control using ros_control, so that would be something you'd have to check for yourself.


Originally posted by gvdhoorn with karma: 86574 on 2018-01-28

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by Managarm on 2018-02-01:
Thank you for your reply! Unfortunately I don't want to plan ahead,so I think a controller would really be the best option. The joint_speed topic sounds like an option,but I was hoping I could leverage ros_control's existing functionality instead of implementing my own transmission/controller chain.

Comment by Managarm on 2018-02-02:
Depends on what you mean by planning :) I don't want to precompute when the robot should be where. Especially the "when" is causing a lot of problems for me. Thank you for your efforts. It's not really an answer but I got some ideas from it, so I'll take it.

Comment by gvdhoorn on 2018-02-02:
I'm rather confused: if you create a JointTrajectory with just two points in it (where you are now, and where you want to go), set the time_from_start=0 for the first, and time_from_start=duration_of_motion for the second, wouldn't that do what you want?

ros_control is nog going to help ..

Comment by gvdhoorn on 2018-02-02:
.. with that.

ros_control is a resource management infrastructure that provides a set of controllers. All are joint space, with some in the community adding Cartesian control. If you were looking for Cartesian control, you'll have to find those controllers and add them.

Comment by gvdhoorn on 2018-02-02:
I believe my confusion comes from what you mean exactly by "direct control". It's a rather ambiguous description.

Comment by Managarm on 2018-02-03:
I see what you mean. I have 2 problems (both are well known if I remember correctly): 1) when not using the joint_trajectory_controller there is no trajectory blending. In my usecase the trajectory is frequently updated, but to reliably start the new trajectory I have to stop the robot and wait...

Comment by Managarm on 2018-02-03:
...for ~200ms or the start point will have passed and the new trajectory will fail. So continuously interpolating towards a goal seems like a better solution. And 2) when trajectories are sent at a high frequency after a few times the robot suddenly starts moving much faster, ignoring...

Comment by Managarm on 2018-02-03:
...all velocity and acceleration limits. I believe this is caused by the time parametrization and possibly a queue somewhere which is not handled fast enoug. We're still on Indigo here by the way. I already added the new iterative cubic spline algorithm,but it still happens and we can't have that :/

Comment by gvdhoorn on 2018-02-03:
Using position control for tracking a moving target is going to be suboptimal in any case (unless you can exploit a controller feature in some way, such as conveyor tracking). Trajectory blending tries to improve the situation a bit, but it's not ideal.

Comment by gvdhoorn on 2018-02-03:
You could take a look at something like cob_twist_controller, which should be able to follow arbitrary TF frames using a velocity interface to your robot. I've not used it myself, but from the description is sounds like it could be used to implement ..

Comment by gvdhoorn on 2018-02-03:
.. tracking behaviour. cob_cartesian_controller can generate trajectories for TF frames.

But that is all assuming that is something you actually want/need.

Comment by Managarm on 2018-02-05:
@gvdhoorn Thank you very much! These sound very promising - I'll have a look into them.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.