Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Continuous Servoing #1

Open
futureneer opened this issue Aug 4, 2014 · 2 comments
Open

Feature Request: Continuous Servoing #1

futureneer opened this issue Aug 4, 2014 · 2 comments

Comments

@futureneer
Copy link

Hello! I have been using URX for a while and it is really great code. I really appreciate the clean interface to the robot, as opposed to some other wrappers interacting with universal robots.

I was wondering if it is possible to continuously servo the robot to a pose using URX. I have tried sending a sequence of movel commands using urx, but it seems that the rate is limited by how long it takes to upload the program to the robot. Is there a better way of commanding the robot at say, 50-100Hz? I have an application where I would like to have the robot follow the pose of a Razer Hydra, and with the method I mentioned above I seem to only get about 4Hz communication rate to the robot. I would not be surprised if I am doing it wrong, but I figured I would ask.

I have seen other (bad) implementations that load a program to the robot and communicate with that program over a socket to rapidly send a sequence of movel commands, but it seems that URX was written in sort of a one-program-per-command paradigm (which I like and which makes sense for discrete commands).

If there is no way to do this with the current implementation, I would be happy to contribute this feature, I just wanted to make sure that I wasn't missing something first.

Thanks for the help and the great software!

Cheers,
Kel

@oroulet
Copy link
Collaborator

oroulet commented Aug 4, 2014

Hi,

Nice to hear that you enjoy python-urx.
urx uses the socket interface of the robot. There are 2 main limitations of
that interface:
1- every new command stops the current move. That means that you cannot get
path blending between commands
2- the robot interpretes commands at around 10Hz

Concerning 1 I did try to find a solution last year but did made it. both
movel and movep commands stop the robot, but servoj does not.
I think that the simplest(But not so simple) solution to you problem is to
send servoj commands at 10Hz. This is tested and works but requires you to
handle the kinematic yourself.
It is also possible to send a socket listener program to the controller,
and make the program interpret commands. then the max frequence seems to be
24Hz. A collegue has example code if you want

I you do a test with all the available commands movel, movep, speedl,
speedj, servoj, etc (for exampe by sending the same command at 10Hz and see
if the move is smooth).... please tell me the result

Olivier

On 4 August 2014 07:20, Kel Guerin notifications@github.com wrote:

Hello! I have been using URX for a while and it is really great code. I
really appreciate the clean interface to the robot, as opposed to some
other wrappers interacting with universal robots.

I was wondering if it is possible to continuously servo the robot to a
pose using URX. I have tried sending a sequence of movel commands using
urx, but it seems that the rate is limited by how long it takes to upload
the program to the robot. Is there a better way of commanding the robot at
say, 50-100Hz? I have an application where I would like to have the robot
follow the pose of a Razer Hydra, and with the method I mentioned above I
seem to only get about 4Hz communication rate to the robot. I would not be
surprised if I am doing it wrong, but I figured I would ask.

I have seen other (bad) implementations that load a program to the robot
and communicate with that program over a socket to rapidly send a sequence
of movel commands, but it seems that URX was written in sort of a
one-program-per-command paradigm (which I like and which makes sense for
discrete commands).

If there is no way to do this with the current implementation, I would be
happy to contribute this feature, I just wanted to make sure that I wasn't
missing something first.

Thanks for the help and the great software!

Cheers,
Kel


Reply to this email directly or view it on GitHub
#1.

@futureneer
Copy link
Author

Hi Oliver,

I would love to see that sample code. I think your second point makes the most sense, sending a socked listener to the robot. I will look into this and make changes to my fork.

Cheers,
Kel

@futureneer futureneer mentioned this issue Aug 6, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants