How to replicate the "Zero Sensor" button via TCP commands? (FT 300/150)

jkimmel

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

Annick_Mottard

@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.

jkimmel

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. 

jkimmel

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 deviation

2.) 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 tap

5.) 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!

jkimmel

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.381715

000:01:45.954 :  mean force in 1 dimension: 3.387685 ;  std.dev: 2.745489

000:01:45.954 :  mean force in 2 dimension: -5.012393 ;  std.dev: 1.871867

000:01:45.954 :  mean torque in 3 dimension: -0.858545 ;  std.dev: 0.010466

000:01:45.954 :  mean torque in 4 dimension: -0.194845 ;  std.dev: 0.007020

000:01:45.954 :  mean torque in 5 dimension: -0.120874 ;  std.dev: 0.005809

000: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.237861

000:01:50.954 :  mean force in 1 dimension: 3.614715 ;  std.dev: 2.585051

000:01:50.954 :  mean force in 2 dimension: -3.742489 ;  std.dev: 2.147263

000:01:50.954 :  mean torque in 3 dimension: -0.867762 ;  std.dev: 0.023664

000:01:50.954 :  mean torque in 4 dimension: -0.188405 ;  std.dev: 0.014364

000:01:50.954 :  mean torque in 5 dimension: -0.120133 ;  std.dev: 0.010451

000: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.969650

000:01:55.954 :  mean force in 1 dimension: 1.735947 ;  std.dev: 3.182038

000:01:55.954 :  mean force in 2 dimension: -3.560291 ;  std.dev: 2.301502

000:01:55.954 :  mean torque in 3 dimension: -0.876225 ;  std.dev: 0.017010

000:01:55.954 :  mean torque in 4 dimension: -0.196555 ;  std.dev: 0.010236

000:01:55.954 :  mean torque in 5 dimension: -0.123971 ;  std.dev: 0.009918

000: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.346670

000:02:00.954 :  mean force in 1 dimension: -0.568846 ;  std.dev: 0.749325

000:02:00.954 :  mean force in 2 dimension: 0.401761 ;  std.dev: 0.679969

000:02:00.954 :  mean torque in 3 dimension: -0.875134 ;  std.dev: 0.013150

000:02:00.954 :  mean torque in 4 dimension: -0.191830 ;  std.dev: 0.006998

000:02:00.954 :  mean torque in 5 dimension: -0.119637 ;  std.dev: 0.006380





please 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!

matthewd92

@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