We have been using the UR3e for an application that involves the installation of a plate onto the wrist and then the pressing and picking up of subsequent layers of sticky material to this plate and previous layers of this material. I have attached some crude diagrams of the setup and function below. The TCP is left at the wrist, but the initial configuration with the plate has been added with an estimated payload from the payload wizard in the teach pendant. We recently have started using RTDE communication to receive the forces experienced by the tool when lifting up. We initially plotted the z-forces and then switched to the scalar force, but in both cases, we seem to have an issue where the force drifts significantly over the running of the program. Below is an example of this drift over time. We expect the forces to be very low, (<5 N) and the weight of the material for the below example is less than 2 N by the end, so I don’t think the weight is making this drift occur. One last thing of note is that the part that is picked up is not always perfectly centered with the wrist, I’m not sure if this is the issue, but I would have thought that the z-force would not demonstrate this drift despite the off-centeredness. Thank you in advance for your help.
I’ve also noticed drift when monitoring the value of the force sensor. I always used the “zero_ftsensor()” script function to tare the sensor to 0 before taking a measurement that I cared about. Keep it mind this would zero the sensor including whatever weight was already at the tool, meaning it could already have a few pieces stuck to the end but the force will read 0.
So, I currently run zero_ftsensor() before the start of the script, but I think you’re right, I could zero between each vertical pull, to measure the force at that time….I really like that, thank you!
I wonder why there’s this drift though? It’s a bit frustrating since it means the sensor can’t be relied upon to read continuously accurate information, relying instead on periodic zeroing within the script. The main reason for this question was to see if it’s something that I’m doing with the application/scripting, whether our sensor may have some sort of problem, or if it’s just a known issue of the sensor. Any of them are fine, just requires different approaches depending on which one.
It’s a good question. I’ve thus far just accepted it as a limitation of the robot based on nothing other than observation lol. You could reach out on myUR and see if they say anything different.
Just found the following info in the Robotiq website that discusses the use of the FT 300-S sensor that is also shown on the UR website, maybe similar stuff applies to the UR arms’ buil in FT sensor? Looks like it might just be an aspect of the particular FT sensor design. Just leaving this comment for your info as well as anyone else who may be running into the same!
You got it right. The sensor built into the tool mounting bracket on the URs is built by Robotiq, so it’s most likely very similar to the FT300 sensor.
It’s not designed to be consistent, and UR claims that a zero is to be used every time you are to perform a precise force-related movement/measurement. The built-in nodes (Force and Until Tool Contact) do a zero themselves before performing the action.
The sensor built into the tool mounting bracket on the URs is built by Robotiq, so it’s most likely very similar to the FT300 sensor.