the ActiveDrive toolbar for the FT300 has a feature where it detects drift or variance of the sensor and zeroes it before starting active drive.We tried sending a "CLEAR ZRO" message over the TCP, but instead of setting the means and deviations near zero like the "Zero Sensor" button does, sending "CLEAR ZRO" is more like rolling the dice and getting new random values in our observed means and deviations.How can we replicate the "Zero Sensor" feature in our own code? Specifically it seems to not just de-mean, but to settle the standard deviations as well. What's the trick!?thanksjoe
@jkimmel over Universal Robots, you need to send the command rq_set_zero() in order to zero the values of the sensor. You can use this script command as often as you like in your programs. Post below if you have questions.
Thank you Annick, that does it!Can you describe how to do it over the USB / serial port connection as well? We're considering serial port because of the issue where samples stutter or come in bursts over the UR's TCP link.
Hi @Annick_Mottard - Actually I spoke too soon. I've observed the following several times now:1.) i run a 5 second loop that collects F/T samples and calculates the mean and standard deviation2.) the standard deviation is high (around e.g. 8-10), so i send rq_set_zero()3.) the standard deviation remains high (same value band)4.) If i go to the ActiveDrive URCap and start active drive, i'm shown the "zero sensor" button, which i tap5.) the standard deviation is now between zero and 1. It is crucial for our application to be able to reproduce this "zero sensor" functionality outside of polyscope, and rq_set_zero doesn't do the whole job. Your help is appreciated!
Hi @Annick_Mottard Here is a sample log showing the behavior described above. From this it is clear that the "Zero Sensor" button is still doing something I don't have access to. We are an OEM customer - if we can get the FT300 to work we will be including it with our product, meaning we will help you sell dozens to hundreds of FT sensors over the next few years. However for us to ship this product with this sensor we need to be able to make it behave! Both the standard deviations and the means are substantially closer to zero after we hit the "Zero Sensor" Button, but we are not able to produce that result by sending rq_set_zero. ====collect data for 5 seconds====000:01:45.954 : mean force in 0 dimension: -4.284168 ; std.dev: 1.381715000:01:45.954 : mean force in 1 dimension: 3.387685 ; std.dev: 2.745489000:01:45.954 : mean force in 2 dimension: -5.012393 ; std.dev: 1.871867000:01:45.954 : mean torque in 3 dimension: -0.858545 ; std.dev: 0.010466000:01:45.954 : mean torque in 4 dimension: -0.194845 ; std.dev: 0.007020000:01:45.954 : mean torque in 5 dimension: -0.120874 ; std.dev: 0.005809000:01:45.954 :============= send rq_set_zero; collect data for 5 seconds ==================000:01:50.954 : mean force in 0 dimension: -4.412461 ; std.dev: 1.237861000:01:50.954 : mean force in 1 dimension: 3.614715 ; std.dev: 2.585051000:01:50.954 : mean force in 2 dimension: -3.742489 ; std.dev: 2.147263000:01:50.954 : mean torque in 3 dimension: -0.867762 ; std.dev: 0.023664000:01:50.954 : mean torque in 4 dimension: -0.188405 ; std.dev: 0.014364000:01:50.954 : mean torque in 5 dimension: -0.120133 ; std.dev: 0.010451000:01:50.954 :============= send rq_set_zero; collect data for 5 seconds==================000:01:55.954 : mean force in 0 dimension: -4.960074 ; std.dev: 1.969650000:01:55.954 : mean force in 1 dimension: 1.735947 ; std.dev: 3.182038000:01:55.954 : mean force in 2 dimension: -3.560291 ; std.dev: 2.301502000:01:55.954 : mean torque in 3 dimension: -0.876225 ; std.dev: 0.017010000:01:55.954 : mean torque in 4 dimension: -0.196555 ; std.dev: 0.010236000:01:55.954 : mean torque in 5 dimension: -0.123971 ; std.dev: 0.009918000:01:55.954 :============= Start ActiveDrive via URCAP plugin; Tap "Zero Sensor" Button (also send rq_set_zero) collect data for 5 seconds==================000:02:00.954 : mean force in 0 dimension: -0.746051 ; std.dev: 0.346670000:02:00.954 : mean force in 1 dimension: -0.568846 ; std.dev: 0.749325000:02:00.954 : mean force in 2 dimension: 0.401761 ; std.dev: 0.679969000:02:00.954 : mean torque in 3 dimension: -0.875134 ; std.dev: 0.013150000:02:00.954 : mean torque in 4 dimension: -0.191830 ; std.dev: 0.006998000:02:00.954 : mean torque in 5 dimension: -0.119637 ; std.dev: 0.006380please observe that in the last block the deviations are roughly 1/4 of their previous values! This "quiet" stable behavior typically persists for several hours, until the means start to drift and the deviation increases, at which point the only thing that reliably works is using the ActiveDrive plugin "zero sensor" button.thanks for your help!
@Annick_Mottard or @jkimmel anything further with this issue? I am experiencing the same issue. Not only do I get high deviations which are causing the sensor to think it has found the object during a search well before it actually gets there, think 12-15 mm away sometimes, it doesn't even always set the sensor to the same level. Sometimes after I set the sensor to 0 using the rq_set_zero() function is usually somewhere between 2-3N and bouncing a lot, other times its as high as 20N after the rq_set_zero().Any ideas are greatly appreciated. At this point I have basically had to incorporate the robot force mode into the search function to guarantee that I do not fault out the robot
the ActiveDrive toolbar for the FT300 has a feature where it detects drift or variance of the sensor and zeroes it before starting active drive.
We tried sending a "CLEAR ZRO" message over the TCP, but instead of setting the means and deviations near zero like the "Zero Sensor" button does, sending "CLEAR ZRO" is more like rolling the dice and getting new random values in our observed means and deviations.
How can we replicate the "Zero Sensor" feature in our own code? Specifically it seems to not just de-mean, but to settle the standard deviations as well. What's the trick!?
thanks
joe