TCP position fails to update when moving until contact

Technical Questions Report a Bug
1

We are using RTDE and the UR5e to perform a pick and place procedure. It uses a move command with the until contact function to touch down onto a socket for placing an item. This should return the position that the TCP is at when it makes contact, but instead is stops updating the actual_TCP_pos as soon as this command is called. This is causing problems in moving to the correct location after the command is run, as it is providing the wrong TCP position.

Robot generation: URCobot 5e

Steps to reproduce:

  • Setup TCP above an obstacle
  • Track the actual_TCP_pos at its starting location
  • Move down until contact with obstacle
  • Check actual_TCP_pos again

Expected behavior: It is expected that the actual_TCP_pos would be updated with the final position of the TCP whenever the until contact criteria has been met.

Actual behavior: The actual_TCP_pos is not updated when the ‘until contact’ criteria has been met. Instead, it continues to give the position of the TCP at the point when the move command with until contact was started.

2

Hi @luke.larson, can you share your program please? Will make it easier to see what’s going on and suggest alternative approaches.

3

Hi @ajp, thank you for responding! We are working on putting together a quick demo to aid in diagnosing our problem. I intend to post this for you by end of day Tuesday (April 26). Just a quick update as the weekend is approaching.

1 Like
4

Upon further investigation, we believe we have located the problem. While I was working on the demo, I was able to get it to updated the actual_TCP_pose as expected. This pushed us to investigate the original code further.

In this code, we have a switch statement on the pendant that is driven by Python code. What we found is that the switch case for the ‘move until contact’ command was being re-entered before the data could be extracted for the final position when contact was made. By preventing re-entry into the switch case, we are able to get the value for actual_TCP_pose that we need.

Thank you for your willingness to help @ajp .

5

No problem, glad to see you got it resolved.