Hand teaching and pendant manual motion disabled by ROS driver. about universal_robot HOT 37 CLOSED

On a related note, using the arrows to move the arm from the Pendant "Move" tab results in the arm moving only a few cm before stopping. The arm can be repeatedly "jogged" to a position, but it's annoying at the very least.

from universal_robot.

Has there been any progress on this issue?

I'm a beginner with ROS and ur_driver, but I've found that messing with the timeout values in ur_driver.py sometimes makes it work, but I'm not sure how to proceed.

from universal_robot.

As @paturdc mentioned on the ros-industrial mailinglist (https://groups.google.com/forum/#!topic/swri-ros-pkg-dev/5KBACyQNJro), he probably found a way to solve this.

@paturdc could you create a PullRequest with your changes, so that your solution can be discussed here and tested by other users? It will also give this issue some new stimulus...

from universal_robot.

Changing the timeout before the script is re-uploaded will not fix the issue. At best it will make it occur less frequently.

The problem is that any action on the pendant interrupts the current UR script. The python side detects this and re-uploads the script and by that interrupts the action you started from the pendant. Increasing the timeout might give you enough time to finish whatever movement you were trying to do from the pendant, but only if you're lucky.

What would help is if the python side didn't re-upload the script until it is actually needed, to execute a trajectory. Then the feedback on port 30002 should be used most of the time, so it might be worth it to always use that feedback and remove the feedback from the UR script (except for a heartbeat to detect the connection dropping).

from universal_robot.

Changing the timeout is just a hack I came up with, because I really needed
both *ur_driver *and manual control at the same time. If it is not a
workable solution, I'll just keep it in my private files, for when it is
needed.

What would help is if the python side didn't re-upload the script until it
is actually needed, to execute a trajectory. Then the feedback on port
30002 should be used most of the time, so it might be worth it to always
use that feedback and remove the feedback from the UR script (except for a
heartbeat to detect the connection dropping).

Would that solution mean the driver stops transmitting /joint_state ?

On 17 June 2014 11:39, de-vri-es [email protected] wrote:

Changing the timeout before the script is re-uploaded will not fix the
issue. At best it will make it occur less frequently.

The problem is that any action on the pendant interrupts the current UR
script. The python side detects this and re-uploads the script and by that
interrupts the action you started from the pendant. Increasing the timeout
might give you enough time to finish whatever movement you were trying to
do from the pendant, but only if you're lucky.

What would help is if the python side didn't re-upload the script until it
is actually needed, to execute a trajectory. Then the feedback on port
30002 should be used most of the time, so it might be worth it to always
use that feedback and remove the feedback from the UR script (except for a
heartbeat to detect the connection dropping).

—
Reply to this email directly or view it on GitHub
#54 (comment)
.

from universal_robot.

No, the driver could continue to publish joint state information if it parses the feedback from the connection to the robot on port 30002. It already does that as a fallback for when the feedback from the UR script stops.

from universal_robot.

I'm curious, what is the reason that teaching mode and the ROS driver cannot work together?

NB: URScript contains functions teach_mode()``and``end_teach_mode(). I've tried to uses these once, which didn't work then, but I haven't spent much time on it to get it to work. Could these be used to support teaching mode using the ur_driver?

from universal_robot.

It could be that there is some (unknown) interaction between the ServoThread and the teach mode functionality. I've often wondered whether there could be a bug in the state machine in the ServoThread, causing the servoj() function to be called too often.

from universal_robot.

The main problem is that most buttons on the teach pendant work by sending a new script to the controller. That will interrupt the driver script running on the robot. Then the python driver notices it's not getting new data anymore and re-uploads the driver script, which in turn interrupts the action you started from the teach pendant.

IMO, the best approach is to not upload the driver script immediately when the driver script is killed. Instead, the script can be uploaded when the driver actually has commands for the arm. Of course, that means there is no data being sent from the script to the python driver either, but all that information is available through other interfaces as well.

The problem with those other interfaces is that they've changed quite a bit through all the versions of the robot software. So supporting all of them will be difficult.

edit:
As for teach_mode and end_teach_mode, they worked properly for me, but I haven't tested them together with the driver script.

from universal_robot.

If I'm not mistaken, the AdditionalInfo object in the binary data being broadcasted on the 30002 port contains the state of the Teach button (see here). That could probably be used to wait with uploading the driver until the user has disabled the free-drag mode. I would personally prefer a state-based method over a time-based one.

Of course, that means there is no data being sent from the script to the python driver either, but all that information is available through other interfaces as well.

The problem with those other interfaces is that they've changed quite a bit through all the versions of the robot software. So supporting all of them will be difficult.

The driver was updated some time ago to deserialise the binary data broadcast on 30002 and 30003 instead of running its own (URScript based) feedback loop.

One of the drawbacks is indeed having to support each and every version of the protocol, but it had enough advantages.

from universal_robot.

Ah, awesome.

However, the teach button is just one of the ways to interact with the robot through the teach pendant. I'm also not sure if it works for both the software button and the hardware button. Either way, theres also the tool space and joint space movement controls that would still not work if you just look at the teach button.

from universal_robot.

I agree, this is the behavior I observed as well. The UR5 computer and ROS node fight for control of the arm and nothing productive results.

Also, there is a new API being released soon; maybe it will unlock new capabilities.

Sent from my Apple ][

On Feb 13, 2015, at 8:28 AM, de-vri-es [email protected] wrote:

The main problem is that most buttons on the teach pendant work by sending a new script to the controller. That will interrupt the driver script running on the robot. Then the python driver notices it's not getting new data anymore and re-uploads the driver script, which in turn interrupts the action you started from the teach pendant.

IMO, the best approach is to not upload the driver script immediately when the driver script is killed. Instead, the script can be uploaded when the driver actually has commands for the arm. Of course, that means there is no data being sent from the script to the driver either, but all that information is available through other interfaces as well.

The problem with those other interfaces is that they've changed quite a bit through all the versions of the robot software. So supporting all of them will be difficult.

—
Reply to this email directly or view it on GitHub.

from universal_robot.

However, the teach button is just one of the ways to interact with the robot through the teach pendant.

True. I just thought to give an example of a state-based way in which at least the free-drag mode issue could be fixed, instead of relying on time-outs (twiddle-factors, imho).

from universal_robot.

@jeff-o: you are talking about the LLSI? Afaik, that is a replacement for the C-API right?

from universal_robot.

I agree timeouts are a crutch at best. But I'm not proposing timeouts. I'm proposing not uploading the script at all until the python driver has a command for the arm. No timeouts involved.

from universal_robot.

I'm proposing not uploading the script at all until the python driver has a command for the arm.

I've thought about that too: taking it further we could just do away with the prog script entirely, and send individual URScript statements to 30002, similar to how oroulet/python-urx works. I'm just not sure about the performance impact.

from universal_robot.

There is already a parameter that can be used to prevent programming, i.e. upload the prog

from universal_robot.

@ipa-fxm: yes, but then the driver won't do anything at all, right? But it could indeed be used as part of a 'wait with programming until X' scheme.

from universal_robot.

I've experimented a bit with sending loose servoj commands (both wrapped in a function/script or plain). The results weren't very pretty, but it's possible I did something wrong.

Alternatively, an entire trajectory could be turned in to a single script with movej or servoj commands. I noticed however that parsing time for large scripts is terrible. I don't know the exact numbers anymore, but iirc a trajectory with a few hundred waypoints (servoj or movej commands) already took multiple seconds to parse. During the parsing, the robot wasn't moving.

And to get linear tool space motion with a FollowJointTrajectoryAction interface you will need a lot of waypoints.

from universal_robot.

@ipa-fxm: yes, but then the driver won't do anything at all, right? But it could indeed be used as part of a 'wait with programming until X' scheme.

Well, the parameter is queried from the parameter server every driver cycle here. Thus, you could change the value on the parameter server before you want to use the teach mode...and afterwards change it back to false again...there might be more elegant ways to do this than using rosparam set on the terminal...but you get my point...

from universal_robot.

Well, the parameter is queried from the parameter server every driver cycle here. Thus, you could change the value on the parameter server before you want to use the teach mode...and afterwards change it back to false again...there might be more elegant ways to do this than using rosparam set on the terminal...but you get my point...

Fair enough, but it still complicates using the teach pendant. Ideally you could just use both the driver and teach pendant without extra user actions.

from universal_robot.

The main problem is that most buttons on the teach pendant work by sending a new script to the controller.

Thanks for the info, @de-vri-es. I didn't know that, but it explains the behaviour, and why it's more difficult to fix.

I also thought that the "teach" state of the robot could be read out in one of the status bits. I think it makes sense to wait with uploading prog until the teaching mode has ended (plus possibly a small additional delay of a few seconds). This would avoid the "fighting" over control, but still restore the control in a nice way within reasonable time.

Furthermore, if the teach_mode functions could be integrated into the driver, this would possibly provide a way to enter teach mode without having to use the buttons on the teach pendant (that are the root cause of this issue). This could be used in some (probably not all) situations.

With respect to support of different versions, I think it would be acceptable to fall back on a generic recovery mechanism (e.g. retry to connect once every 30 or 60 seconds or so) for software versions that are not supported.

from universal_robot.

By the way, if I remember correctly, the teach button on the TP seems to be disabled now when the driver is running. I always had to stop the driver in order to use the button. In earlier versions of the driver the button could be used (which caused the connection to be lost such that the driver had to be reset). Is this behavior changed at some point? Can the driver disable the TP button?

from universal_robot.

@tnl-woi: I'd rather not have some invisible interface to a behaviour which could possibly lead to damage to my robot, my cell or myself.

If fi payload isn't properly defined, entering teach mode can do unexpected things. Having to physically be near the robot, and depress a physical button seems like a good thing, also because letting go of that button (as a reaction to an unexpected behaviour) immediately disables free-drag.

With respect to support of different versions, I think it would be acceptable to fall back on a generic recovery mechanism (e.g. retry to connect once every 30 or 60 seconds or so) for software versions that are not supported.

This was actually a comment on having to support all versions of the binary protocol. If a version isn't supported, retrying every 30 seconds won't solve that :).

from universal_robot.

@gavanderhoorn Good point, I agree. (Although a software method would possibly be convenient but that isn't worth the additional risks. So I prefer to find a way to recover from using the button.)

from universal_robot.

Making prevent_programming dynamic_reconfigurable is started on my branch.
Prevent sending the programm in case the teach button is pressed is started on my branch.

Both branches still need to be tested with the hardware - thus, no PR yet...

Some more comments:
I prefer not to use teach_mode() and end_teach_mode() to enable teach mode through the ur_driver. Btw, these functions are only available with ScriptingAPI version 3.0.

Using the AdditionalInfo from the secondary protocol RobotState seems reasonable to allow teach mode when the teach button is pressed. It's the approach I chose to give a try.
However, the slot teach_button_pressed is only available since revision 8. But I added this field to the older revision set to False by default to ensure data compatibility. That means pressing the teach button on an older revision will not prevent ur_driver from sending the program (but I thought this behaviour reasonable, as it is the current behaviour for those revisions anyway). Maybe the teach_button_pressed state is encoded somehow within the control_bits slot...but I can't tell.
(Please note the difference between the slot names teach_button_pressed and teach_button_enabled!)

There is another way to determine whether the robot is in teach mode or not (and this version would most likely also work for the software teach button - and not only for the little black button on the back of the pendant): Since revision 12 there is a slot ControlMode in the RobotModeData of the secondary protocol...but as this is not available for older versions, I chose to use AdditionalInfo...

Comments and compatibility reports welcome...

from universal_robot.

However, the slot teach_button_pressed is only available since revision 8. But I added this field to the older revision set to False by default to ensure data compatibility. [..]

You could just check for existence of teach_button_pressed in the state.additional_info object (with something like hasattr()). I think the data structures in deserialize.py should mirror the protocol documentation, and we shouldn't start adding fields on our own.

I'll see if I can do some wireshark sniffing on Monday, and determine whether control_bits somehow encodes the state of the button.

There is another way to determine whether the robot is in teach mode or not (and this version would most likely also work for the software teach button - and not only for the little black button on the back of the pendant): Since revision 12 there is a slot ControlMode in the RobotModeData of the secondary protocol...but as this is not available for older versions, I chose to use AdditionalInfo...

Comments and compatibility reports welcome...

Could robot_mode (RobotMode) be of use? One of its values is FREEDRIVE?

from universal_robot.

Why bother trying to find out if the robot is in teach mode? It has to be done differently for different software versions, it doesn't work for manual tool space and joint movement from the teach pendant and there's no real advantage to having the script running all the time.

On the other hand, not re-uploading the script unitl the python driver wants to send a command works for every software version and for every possible action you want to take from the teach pendant.

from universal_robot.

On 15-2-2015 17:27, Maarten de Vries wrote:

Why bother trying to find out if the robot is in teach mode? It has to be done differently for different software versions, it doesn't work for manual tool space and joint movement from the teach pendant and there's no real advantage to having the script running all the time.

On the other hand, not re-uploading the script unitl the python driver wants to send a command works for every software version and for every possible action you want to take from the teach pendant.

It seems to me that avoiding reuploading when the robot is in teachmode
solves a rather significant shortcoming of the current implementation,
without changing too much of the underlying code. All-in-all it will
probably take 5 minutes with wireshark to see whether this is possible
for older revisions of the protocol (I already have the dissector).
Avoiding reuploading is essentially a simple feedback loop (checking for
'teach mode' in the already deserialised state data).

You're right though that it won't fix the other issue(s) with TP
jogging, those will have to be solved in some other way.

from universal_robot.

You're right though that it won't fix the other issue(s) with TP
jogging, those will have to be solved in some other way.

Allright, I'll see if I can find the time to put together a pull request. With the data already coming from the controller directly the hard part has already been done.

from universal_robot.

The dynamic reconfigure works quite nice (see #162 and #163)

However, although the robot_state.additional_info.teach_button_pressed changes it's value when I press the button on the teach pendant, the `prog``is still running and blocks going into teach_mode!
So this branch does not work yet...I guess, the reset_prog needs to be send or something else...

Unfortunately, I don't have time right now to work on this feature...@de-vri-es and @gavanderhoorn would you be able to continue this as you seem to be involved in this anyway....

from universal_robot.

Unfortunately, I don't have time right now to work on this feature...@de-vri-es and @gavanderhoorn would you be able to continue this as you seem to be involved in this anyway....

Well, I'd like to go with the option of not re-uploading the script at all until a new trajectory or service call is received. I can probably find the time to do that.

from universal_robot.

Hi!
just want to ask: Is there any way to use the teachmode with my PolyScope 1.8.11281?

from universal_robot.

Just run rosrun rqt_reconfigure rqt_reconfigure with the driver running.
There should be an entry with ur_driver with a checkbox prevent_programming.
With prevent_programming active, you should be able to use any function on the pendant. toggling it back to prevent_programming disabled and you should be able to use the ur_driver from ROS as before...

from universal_robot.

Great! Thanks, that works fine.
Is it also possible to do that in the C-API?

from universal_robot.

I guess not...I never used the C-API myself...but I always heard that you are loosing the pendant-functionality due to the patches to the UR controller required to be able to use the C-API...

from universal_robot.

'disengaging' the driver has become possible with the merge of #163. The implemented solution is not ideal (as not uploading prog when not needed would be better, the approach taken by the ur_modern_driver), it is functional.

As such, I'm going to close this issue.

from universal_robot.