Controlling a robot arm directly

asked 2018-01-26 08:13:38 -0500

Managarm
28 ●3 ●4 ●8

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, ~

edit retag flag offensive close merge delete

Comments

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?

JuanTelo ( 2018-02-02 04:44:25 -0500 )edit

@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!

Managarm ( 2018-02-02 06:56:21 -0500 )edit

@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

JuanTelo ( 2018-02-02 09:37:28 -0500 )edit

@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

Managarm ( 2018-02-03 06:10:40 -0500 )edit

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?

alinwegy ( 2023-07-27 08:05:34 -0500 )edit

add a comment

answered 2018-01-28 07:08:32 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2018-02-02 03:44:23 -0500

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.

edit flag offensive delete link

Comments

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.

Managarm ( 2018-02-01 09:23:05 -0500 )edit

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.

Managarm ( 2018-02-02 06:52:37 -0500 )edit

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 ..

gvdhoorn ( 2018-02-02 09:15:59 -0500 )edit

.. 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.

gvdhoorn ( 2018-02-02 09:17:30 -0500 )edit

I believe my confusion comes from what you mean exactly by "direct control". It's a rather ambiguous description.

gvdhoorn ( 2018-02-02 09:19:33 -0500 )edit

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...

Managarm ( 2018-02-03 06:13:43 -0500 )edit

...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...

Managarm ( 2018-02-03 06:15:50 -0500 )edit

...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 :/

Managarm ( 2018-02-03 06:18:31 -0500 )edit

see more comments

Controlling a robot arm directly

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Controlling a robot arm directly edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Controlling a robot arm directly