Sensor transforms debugged on Dev/naveen

[naveenoid]

After lot of testing, finally the sensor-link transforms seem correct. Atleast definitely for subject 1. The refactored version makes it much more obvious to debug. The key is that despite the fix in the URDF to maintain the revolute joints on Y, the Drake URDF loader still seems to impose the Z axis rotations. This necessitates a little tweak on the organisation of Rotation matrix going from the Global frame G to frame 0. Every other computation derives from this..so if the URDF issue gets fixed this rotation must be reverted. The PredictSensorMeasurement script computes the sensor data prediction using a modified version of featherstone RNEA.

Remember to add tests, and helperFunctions to the path to be able to run predictSensorMeasurement.

@claudia-lat @traversaro @iron76

[traversaro]

The key is that despite the fix in the URDF to maintain the revolute joints on Y

Which fix are you referring to? As far as I knew, Drake urdf loader always used the spatialV1 library, that supported only revolute joint that rotate on the Z-axis.

[naveenoid]

I know that. What did not make sense is how the URDF can be written with Y revolute joints and how drake maintains a Z revolute similar structure. Possibly facilitated because its planar kinematic chain so wont change so much except for link0?

Anyways, the diagram presented in https://github.com/iron76/bnt_time_varying/tree/dev/naveen/experiments/humanFixedBase shows all link/joint frames according to URDF design whereas in reality all of them are rotated to use Y rotation. I am not sure how to document this in a sustainable manner.

On Mon, Jan 25, 2016 at 8:59 AM, Silvio Traversaro <notifications@github.com

wrote:

. The key is that despite the fix in the URDF to maintain the revolute joints on Y Which fix are you referring to? As far as I knew, Drake urdf loader always used the spatialV1 library, that supported only revolute joint that rotate on the Z-axis.

— Reply to this email directly or view it on GitHub https://github.com/iron76/bnt_time_varying/pull/18#issuecomment-174431235 .

[traversaro]

@naveenoid what is missing in this PR to be merged?

[naveenoid]

MAP computation doesn't work yet. Although it executes without error, it works completely wrong with non-physical sense! So before merging MAP stuff, I will concentrate to fix it.

in my opinion MAP dynamics and the iDyntree cross check must be updated. For sure the map dynamics script (main.m) atleast executes without error, nevermind the calculation errors in results. iDyntree crosscheck is not yet tested / ported. On the other hand, they can very well be done once this is merged to master too. I prefer the latter option.

---

Naveen Kuppuswamy, PhD Post-doctoral Fellow, Cognitive Humanoids Lab, Department of Robotics, Brain and Cognitive Sciences (RBCS), Istituto Italiano di Tecnologia, Genova, Italy

On Fri, Jan 29, 2016 at 2:38 PM, Silvio Traversaro <notifications@github.com

wrote:

@naveenoid https://github.com/naveenoid what is missing in this PR to be merged?

— Reply to this email directly or view it on GitHub https://github.com/iron76/bnt_time_varying/pull/18#issuecomment-176759748 .

[claudia-lat]

MAP computation doesn't work yet. Although it executes without error, it works completely wrong with non-physical sense! So before merging MAP stuff, I will concentrate to fix it.

[iron76]

It has to do with the variance of the measurements. How did you choose them?

[claudia-lat]

Using your own variances and playing with us. But I think that the problem is in how we are passing data into the structure.

[naveenoid]

I wrote you an email on the subject..we must consider the IMU as a pure accelerometer and eliminate the sections from the Y matrix corresponding to rotational acceleration (i.e. IMU is a 3D linAcceleration only). This is essential and only then other (hidden?) problems can be resolved. Have you checked this out?

---

Naveen Kuppuswamy, PhD Post-doctoral Fellow, Dynamic Interaction Control Lab, iCub Facility, Istituto Italiano di Tecnologia, Genova, Italy

On Mon, Feb 1, 2016 at 10:29 AM, claudia-lat notifications@github.com wrote:

Using your own variances and playing with us. But I think that the problem is in how we are passing data into the structure.

— Reply to this email directly or view it on GitHub https://github.com/iron76/bnt_time_varying/pull/18#issuecomment-177873780 .

[iron76]

Hey guys is this pull request still valid? How should we proceed? It would be difficult for me to go through all the changes that have been applied.

[claudia-lat]

It is not valid anymore since it concerns changes related to the old code. I would suggest to merge my branch that currently is working.

[naveenoid]

as noted, changes have been integrated in the dev/claudia branch. Im closing this for now.