Force Torque sensors are extremely noisy at iter=50, sor=1.4

[osrf-migration]

Original report (archived issue) by Jesper Smith (Bitbucket: jespersmith).

The original report had attachments: iter250ForceTorque.png, iter200ForceTorque.png, iter50ForceTorque.png

---

During testing of the force torque sensors I saw that they where extremely noisy. Using the tests written for #193 (#193) I measured the noise for iter=50, iter=200 and iter=250.

iter=50 (see iter50ForceTorque.png)

Signal noise
Mean
 Force X: 2.9184
 Force Y: 1.4692
 Force Z: -58.7554
 Torque X: -1.3587
 Torque Y: 42.4429
 Torque Z: 0.98366
Std dev
 Force X: 53.455
 Force Y: 58.4858
 Force Z: 33.9999
 Torque X: 55.7359
 Torque Y: 0.80908
 Torque Z: 42.8304

iter=200 (see iter200ForceTorque.png)

Signal noise
Mean
 Force X: 4.3924
 Force Y: 1.5287
 Force Z: -58.9146
 Torque X: -1.2543
 Torque Y: 42.4333
 Torque Z: 1.0472
Std dev
 Force X: 43.5975
 Force Y: 61.2231
 Force Z: 29.3226
 Torque X: 57.9369
 Torque Y: 0.61266
 Torque Z: 45.187

iter=250 (see iter250ForceTorque.png)

Signal noise
Mean
 Force X: 5.0497
 Force Y: -0.074208
 Force Z: -58.6046
 Torque X: 0.071245
 Torque Y: 42.4289
 Torque Z: -0.057907
Std dev
 Force X: 5.6372
 Force Y: 6.4062
 Force Z: 3.4137
 Torque X: 6.0927
 Torque Y: 0.075793
 Torque Z: 4.6055

It seems that the noise on the force torque sensor is drastically reduced when the number of iterations is increased from 200 to 250, however increasing from 50 to 200 doesn't seem to affect the noise at all.

Initial tests showed that increasing the global CFM decreases the noise as well, but greatly increases the joint constraint error. Maybe it is possible to increase the CFM locally.

[osrf-migration]

Original comment by Jesper Smith (Bitbucket: jespersmith).

---

When I increase the mass of one of the links I also need to increase the number of iterations for a relatively noise-free force-torque sensor.

[osrf-migration]

Original comment by DavidC (Bitbucket: DavidC).

---

In another thread I made a suggestion that it might be worth investigating adding filtering within a time step. This noise seems to be due to simulator errors related to modeling of collision forces.

Let's say we use iters=50. Applying a filter to the last 25 iterations might be more representative of "reality" than any single iteration. At the next time step, the filter is re-initialized at the 25th iteration.

This may very well be a bad idea for any number of reasons, but has anyone considered it?

[osrf-migration]

Original comment by Jesper Smith (Bitbucket: jespersmith).

---

• changed priority from "major" to "minor"

Reducing priority, filtering helps for the wrist sensors if we don't care about fast signals.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

@DavidC:

I think we will hold off on filtering data in simulation and leave that to the users.

I briefly tested explicit residual filtering of \Delta \lambda after a few number of LCP iterations, but failed to find significant improvement to noise and seemed to have unpredictable effects to overall simulation stability. Maybe implicit filter will do better? but going down this road feels like a research project. I'll hold off on this endeavour unless you find simultaneous improved simulation error reduction and un-degradaded stability?

Thanks, John

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Here's the kind of velocity jitter I get with 50 iterations in my tests in qual 2 holding the drill, see video.

This is done from this gazebo branch with this sandia-hand branch.

[osrf-migration]

Original comment by Jesper Smith (Bitbucket: jespersmith).

---

That is with damping = 30nm/rad/s I pressume? Lower damping probably inreases the jitter on the velocity, although I was referring to the force torque sensors here. I still think lower damping is desirable, to allow fast hand position changes to work in the driving task.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Hi @jespersmith,

Here are the IMU plots:

1. Here's the grasping behavior with damping = 10nm/rad/s and
2. Here again is grasping with 30nms/rad again with imu values.

The goal here is to achieve indefinite grasp-hold of the object at hand, but as demonstrated in first video, 10 nms/rad fails to do so.

John

[osrf-migration]

Original comment by Chris Atkeson (Bitbucket: catkeson).

---

For the VRC, I am not sure indefinite grasp-hold is more useful than faster finger movements. Which task needs indefinite grasp-hold against gravity? Can't we just make sure the hand is always below the hose? The valve and and steering wheel aren't pulled away from the hand by gravity.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Grasp hold was mainly for task 3, it would be nice to be able to holding the fire hose without trying to keep the hand below the hose. But at least for the Q2 grasp example, relaxing viscous damping by applying them adaptively appears to allow for faster finger motion (on the order of 2rad/s(F2) and 4rad/s(F1) when not holding an object).

[osrf-migration]

Original comment by Jesper Smith (Bitbucket: jespersmith).

---

I just picked up the drill with our very simple controller (based on force control and velocity feedback for force distribution) and the robot has held the drill for at least 6 minutes simulation time now without the drill falling out of the hand. This is with the damping parameters for the fingers at 0.1 Nms/rad!

So I think the high damping parameters are only necessary for the controller you used and I think the damping parameters should not be based on a controller implementation but on on real, measured values on the hand.

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

Hi @jespersmith, You are right, high joint damping values are indeed not necessary, 0.1 Nms/rad is stable with cfm damping, and behaves fine when the hand is not holding heavy objects. However, we feel that 1.0 Nms/rad is a better approximation than current setting of 10.0 Nms/rad, while trading off faster finger movements for filtering out high frequency jitters in simulation. Thoughts? John

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

see sandia-hands pull request #25

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

• changed state from "new" to "on hold"

damping reduced

[osrf-migration]

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

---

• changed state from "on hold" to "open"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "open" to "closed"

DRCSim users can choose custom iter values.