I seem to be encountering an apparent change in behavior between 5.2.x and 5.4.x with respect to the FT sensor data transmitted over the RTDE interface. I’m curious if this change in behavior is intentional and whether there is a recommendation for handling the new behavior.
- Setting the robot payload via “set_payload()” resulted in the RTDE force data being zero’ed. That is, if the RTDE force data vector was [ -10,0,10] before setting the payload, it would report [0,0,0] (within noise limits) after setting the payload. This was the behavior regardless of the payload applied – even in the case where the active payload was reapplied.
- I believe the same can be said for a “zero_ftsensor()” call as well but I have not taken the time to verify this.
- Setting the robot payload via “set_payload()” can result in changes to the RTDE force data being reported, but the call does NOT zero it. As a for instance, setting the payload from 0kg to to 5kg resulted in a large change to the z-axis force reported.
- Calls to “zero_ftsensor()” seem to have no effect on the force data reported on the RTDE interface.
Is this behavior change anticipated? Is this a bug? Is this a feature? Is anyone else seeing this behavior?
Does the RTDE data match the controllers get_tcp_force() output?
As it turns out there was no relation between the update to 5.4.3 and the loss of force zeroing behavior. The SDCard containing Polyscope was corrupted during a power cycle prior to the 5.4.3 upgrade. After the reimaging to 5.2.0 force behavior was not retested. The Polyscope version was updated to 5.4.3 and that was when force zero behavior was determined to be broken. After some digging it was determined that the ftsensor.conf file was missing from the controller. A backup of the file was uploaded onto the controller and pushed to the sensor by executing a script file provided by UR support. Force zeroing now works as expected.