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

URScript execution status #19

Closed
khssnv opened this issue Oct 30, 2019 · 10 comments
Closed

URScript execution status #19

khssnv opened this issue Oct 30, 2019 · 10 comments

Comments

@khssnv
Copy link
Contributor

khssnv commented Oct 30, 2019

Excuse me not use issue template. It's not a bug, but a question or functionality request.

Is there an interface to track execution of URScript sent to /ur_hardware_interface/script_command? For me it's necessary to know when execution completes.

@fmauch
Copy link
Collaborator

fmauch commented Oct 30, 2019

No, there isn't such a thing. Depending on what you want to do, you can write a wrapper around this and use information published by the driver (IO states, joint states, etc.) to infer whether your script code has finished execution.

However, since it's a longer running script, I assume that this is being run as a primary script without the control script (aka External Control) being active.

We are currently working on publishing more robot state data, so you will be able to see whether there is a program running currently.

@slessans
Copy link

Access to more controller state data would be super helpful. This driver is awesome so far!

@fmauch
Copy link
Collaborator

fmauch commented Nov 2, 2019

#20 aims at implementing the controller status. Currently Robot mode and Safety mode are published on topics and are available through the dashboard client.

@khssnv
Copy link
Contributor Author

khssnv commented Nov 20, 2019

As discussed in #40, there is no native status tracking for URScript sent to /ur_hardware_interface/script_command topic.

@khssnv khssnv closed this as completed Nov 20, 2019
@gavanderhoorn
Copy link
Contributor

gavanderhoorn commented Nov 20, 2019

As discussed in #40, there is no native status tracking for URScript sent to /ur_hardware_interface/script_command topic.

As a clarification: there is no feedback about urscript execution status - period.

Not in the driver, not coming from the controller.

There is the isProgramRunning field in the RobotModeData packet. This could be used, but:

  • would mean the primary/secondary interface would have to be used again
  • would only work for primary programs

It would also be difficult to disambiguate between external control running and a urscript snippet.

@mgkwon
Copy link
Contributor

mgkwon commented Jan 9, 2020

URSim 5.4.0.76181

As @gavanderhoorn mentioned, "/ur_hardware_interface/robot_program_running" monitors only the primary program, specifically status of 'external control' node in the program. Therefore, this won't work for the script snippets we sent thorough the secondary interface.

However, I've tried using the dashboard interface, querying this topic "/ur_hardware_interface/dashboard/robot_running" and this tells you exactly what the dashboard shows you on the UI (not sure 'PAUSED' state).

Currently, this service topic is not available due to #75.

Until the PR is accepted, we can use query this topic "/ur_hardware_interface/dashboard/raw_request" with 'running'. Check these pages for reference:

@fmauch
Copy link
Collaborator

fmauch commented Jan 9, 2020

@mgkwon thank you for the PR! However, using the running field from the dashboard will also only tell you, whether there is a primary (or at least any - primary or secondary) program running, right?

@mgkwon
Copy link
Contributor

mgkwon commented Jan 9, 2020

@fmauch Sorry, actually, I am not sure what the difference between primary and secondary programs.

Yes, querying running from the dashboard interface tells us if there is a program running or not, regardless of which interface the script is sent from. Script snippets are sent through secondary interface with port 30002.

On the other hand, robot_program_running topic only tells us if the external control from urcap is active or not. I guess it helps to disambiguate between external control running and a urscript snippet as @gavanderhoorn said.

So I've tested publishing scripts through script_command with some other thread polling on the dashboard topic and it worked fine. I think this allows us not to put IOstate changes anymore.

@fmauch
Copy link
Collaborator

fmauch commented Jan 10, 2020

The main problem remains, however. As soon as you have the normal program running with the External Control node from the URCap this will report that a program is running. When you send a primary script (as a non-secondary script, see secondary program doc), it will interrupt program execution of the External Control program. From that point on, it is correct, you can check the mentioned interface whether there's a program running. Additionally, this information is posted on the RTDE interface and there are two PRs pending publishing this data to a ROS topic: #72 and #35

In my opinion this implementation is better than polling it through the dashboard interface.

This is basically the same as the RobotModeData packet information mentioned by @gavanderhoorn, but it has the drawbacks mentioned.

The more I'm thinking about it: Execution status of secondary programs do not really make sense, anyway, right? As secondary programs are required to "not take any physical time to execute" they are expected to return immediately, anyway.

Still the main problem is there that you will only know whether ANY program is currently running. This could be a program running on the TP, this could be your script_command or it could be someone physically pressing one of the motion buttons on the TP.

@mgkwon
Copy link
Contributor

mgkwon commented Jan 13, 2020

@fmauch Thank you! and sorry for the late response. I understand what the secondary program is now... I was thinking that anything goes through 'send_command' was considered as secondary program. So yes, there is no execution of status of secondary programs.

Thank you again for the clarification :)

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

5 participants