I was wondering if someone could clarify the use cases and limitations of the /ur_hardware_interface/script_command topic and the URcap vs headless modes in the context of an implementation. Recommend best practices for using URScript with this driver, if there are any, would also be appreciated.
Background:
We are trying to optimize the running time of a new data-driven lab technique as part of an academic project by interfacing a UR10 with prototype lab equipment through ROS and would like to use computer-generated URScripts to control the UR10.
We have created many URScripts with the pendant for the procedure. Currently, these need to be manually chosen/modified based on data from the lab equipment and a FE model and then executed at specific times. Example: modify velocity and location of waypoints for movel commands based on external data from python scripts and execute URscript when a previous step of the procedure finishes.
The procedure usually needs to be run multiple times with each iteration using new data and since nothing has been interfaced yet it takes an awfully long time.
Requirements:
Be able to generate/modify a URScript on the PC programmatically before sending it to the UR10.
Be able to send a URScript (which includes movel so no secondary function) to the UR10 for execution.
Be able to repeat this procedure without user input to the pendant except for powering everything on at the beginning of the first iteration of the procedure.
Attempted/issues:
Tried sending URScripts using /ur_hardware_interface/script_command but URcap external control program stops and we’d like to not have to restart manually every time.
Tried using the ur_modern_driver which doesn’t require the external control URcap but we have SW 3.11 and no compatibility as of November 2019.
I have read about using IO ports to signal the end of a URScript to ROS so a recommendation would ideally allow for this to automate the procedure even further.
I am also aware of the existence of headless mode. Since the URcap is meant as a plug in for existing programs, would headless mode solve the continuity problem resulting from the external control URcap or is it intended for other purposes?
If I understand correctly, you don’t want to control the robot motions with ROS, but rather generate a custom script generating the motions. May I ask, why? I guess one reason is the lack of a cartesian interpolation abstraction being available through the ROS interface? An answer here could help us improving the driver in future versions.
If you only want to use the driver to act as a script relay, you can simply use the mentioned script_command and not care about a running external_control at all. Strictly speaken, this is only necessary to control robot motions using ROS natively.
As a consequence, it won’t matter whether you will be using the so-called headless mode or not.
Another option (depending on the level flexibility of your use-case) would be to predefine different programs on the robot and load and start them using the dashboard interface, also available through the driver.
Indeed, the reason I am using URscript is the lack of cartesian control abstraction in ROS. I have used tesseract and descartes to implement cartesian control before but I mentioned this method in room full of mechanical engineers without coding experience that will be using and possibly modifying the laboratory set up in the future and saw too many raised eyebrows. URScript seems like a good compromise to enable high level control of the robot arm with access to cartesian control and force mode. Not to mention everyone is comfortable with URScript in its visual form already and I can leverage that in the future.
I see, from reading the repo’s documentation. I was under the impression that the external control URCap was a requirement. This is great then!
With regards to the alternative way, each motion must be planned based on data obtained in previous steps. Therefore, unless the motion scripts can be predefined in the robots with variables and later populated from ROS it doesn´t fit our needs.
I was also trying to send a ur script on the script_command topic and I just sent a single line to test if it works (digital output 0 true as a sec program) as a string but even though I could see the whole line being published on the topic using the echo command, the digital output was still false.
Any ideas what could be going wrong?
Also how do we send a bigger program (ur_script) with multiple lines and a next line is not considered to be in between the " " and thus only the first line will be sent for publishing. Does the space count as a new line in here?
Are you using an e-Series robot? If that’s the case, make sure the robot is in remote_control mode. Otherwise it will not accept script commands being sent from any external source.
When you want to sent multi-line script commands, the newlines have to be inside the string itself. If you remove the closing " while entering a command on the shell, pressing ENTER will result in a newline of the string. Alternatively, you can save your command inside a textfile and publish your message by loading this file on the fly. See the rostopic pub documentation for details.
Also the headless mode was set to true and ur caps was not running. But even if ur caps was running with head less set to false nothing happened. Also I tried with port 30002 instead of 50002 still no luck. I tried “set_digital_out(0, True)” instead of “sec program(): set_digital_out(0, True) end” bur still nothing. Do I need to include socket or something maybe?
First of all, make sure to have the latest version of the driver installed. There has been a change in the newline management for script commands a while ago…
Simply try to start the driver without any modifications (It doesn’t matter whether running in headless mode or not) and try to send set_digital_out(0, True) as script command (before doing anything else). This should work (given that the driver was able to connect to the robot).
I had a similar issue when I first tried sending urscripts using the /ur_hardware_interface/script_command topic. It turned out to be an encoding problem of the strings and .script files that I was sending (end-of-line characters such as /n ). Specifically, I noted that opening the .script files saved by Polyscope on Python using the non-truncating binary “rb” argument and then publishing them to the topic worked, while using the “r” mode caused the robot to ignore them after being published. I am not sure if this affects single line messages published from the command line so I would first give them a try like mauch suggests, but it may be worth a shot if that doesn’t work.