Closed sharpe-developer closed 4 years ago
- Is this delay normal or is something causing a problem?
No, this should not be the case. It is normal that it is not coming instantly, as the program is being compiled when started, but it shouldn't take that long.
- Is there a programmatic way to detect when the robot is ready to receive commands rather than using an arbitrary delay?
You can listen to the robot_program_running topic. But in that situation described I would consider this a workaround rather than a solution.
Are there any other URCaps involved? Does your program contain anything else than the ExternalControl? The program is fetched from the host machine during the start of the program. This is when you will see the Sent program to robot
output. As soon as the program enters the ExternalControl program node.
I performed a Wireshark capture of the interface and didn't see anything unusual. There is a steady stream of packets going back and forth during period between the message "Sent program to robot" and "Robot ready to receive control commands". I have attached the capture for reference if it is helpful. wireshark.zip
There are other urcaps installed on the teach pendant
However, none of the urcaps are actively being used except external control. I can try removing them from the teach pendant to see if it changes anything.
The program only contains the external control unit. There is nothing else in the program.
I removed all the other urcaps and found it was the Robotiq urcap that was causing the problem. I had version Robotiq Grippers 1.6.0.4 installed. Removing the robotiq urcap brought the time between sent program and robot ready messages down to around 50 milliseconds.
I tried updating to Robotiq Grippers 1.8.4.4844 and the time between sent and ready was still milliseconds. It must have been something with the older version installed on the robot.
However, I noticed a new problem. When the robot is rebooted and this setup is executed the dashboard server disconnects. If I re-launch the nodes on the ROS side (don't change anything on the robot) then everything works fine. So it is only the initial launch after restarting the robot that has an issue. If I remove the Robotiq urcap and restart the robot there are no problems on the initial launch. So the new Robotiq urcap does not have the delay but does not work perfectly either. Here is the log output when this error occurs>
You can start planning now!
[ INFO] [1599685906.093207380]: Robot mode is now POWER_ON
[ INFO] [1599685908.360545374]: Robot mode is now BOOTING
[ INFO] [1599685915.583168000]: Robot mode is now POWER_ON
[ INFO] [1599685916.116860271]: Robot mode is now IDLE
[ INFO] [1599685918.972324485]: Robot mode is now RUNNING
[ INFO] [1599685920.697553900]: Disconnecting from Dashboard server on 192.168.100.1:29999
[ERROR] [1599685920.697901565]: Exception thrown while processing service call: Did not receive answer from dashboard server in time. Disconnecting from dashboard server.(Configured timeout: 1 sec)
[ERROR] [1599685920.710130045]: Attempt to write on a non-connected socket
[ERROR] [1599685920.710239055]: Exception thrown while processing service call: Failed to send request to dashboard server. Are you connected to the Dashboard Server?
[ INFO] [1599685921.372080406]: Robot requested program
[ INFO] [1599685921.372174363]: Sent program to robot
[ INFO] [1599685921.566657241]: Robot ready to receive control commands.
I am curious. Why would having a urcap installed on the robot cause this when the urcap is not in use. Is having the urcap loaded on the robot enough to change how the robot operates?
Is having the urcap loaded on the robot enough to change how the robot operates?
In general: no, but there are a lot of URCaps which, as part of their initialisation routine, either start or run or use additional processes and/or threads, which can do whatever. And URCaps can also contribute pieces of code to the initialisation section of every program run / created on the controller. This is all done without you "using" the URCap.
As there is some isolation between URCaps, but not total (how could there be), there is certainly room for one URCap to influence the behaviour of others -- even if it doesn't do this intentionally.
However, I noticed a new problem.
To increase visibility of that problem, perhaps opening a new issue is in order?
To increase visibility of that problem, perhaps opening a new issue is in order?
Indeed. I have opened issue #262
Summary
I am experiencing an 8 to 10 second delay between the message "Sent program to robot" and "Robot ready to receive control commands".
I am running an Ubuntu PC as the ROS machine. Real time patch is installed. The UR3 control box is connected directly via Ethernet to the Ubuntu PC (no switches, etc.).
When I launch all goes well. I am using remote control mode and a python script that powers on the robot, loads the external control program, and runs it. This all works great but then I have to add a 15 second delay in my script before moving the robot since it is not ready to receive commands. As long as I add a delay before moving the robot then I can move the robot repeatedly without any issues. The delay seems excessive so I suspect something is going wrong.
My firewall is disabled as discussed in #8. I also tried updating to the newer external control urcap (v1.0.4). I looked at #1 and #237 but didn't see anything that stood out.
Questions:
Versions
Issue details
Here is my log output. As you can see by the timestamps at the end it took approximately 8 seconds between sent program and ready to receive commands. The delay seems to be random in the range of 8 and 10 seconds.