add dummy physics for imu sensor to make gyro work

[jgueldenstein]

The gyro needs to be child to a Node with a a Physics element. Otherwise the following warning will pop up:
WARNING: DEF Robot <robotname> (PROTO) > HingeJoint > Solid > HingeJoint > Solid > Solid > Gyro: this node or its parents requires a 'physics' field to be functional.

In URDFs there is often an extra frame for an IMU which is attached by a fixed joint to the actual link the imu is attached to.

This PR adds a dummy physics node to the link holding the imu similar to the dummy physics added so tools don't fall off here:

urdf2webots/urdf2webots/writeProto.py

Line 135 in aa6706a

# add dummy physics and bounding object, so tools don't fall off

[jgueldenstein]

The relevant part of the generated proto:

Solid {
  translation -0.025450 0.053500 -0.023500
  rotation -1.000000 -0.000000 -0.000000 1.570800
  physics Physics {
  }
  boundingObject Box {
  size 0.01 0.01 0.01
  }
  children [
    Accelerometer {
      name "imu_head accelerometer"
    }
    Gyro {
      name "imu_head gyro"
    }
    Compass {
      name "imu_head compass"
    }
  ]
  name "imu_frame_2"
}

[omichel]

I am not sure this is the best way to address the problem. Adding a dummy physics-enable object will cause other problems, including performance drop and instability due to this useless mass. Instead, we should remove the intermediate Solid so that the Gyro is a direct child of the upper parent Solid which has physics, so instead, the relevant part should look like that:

Accelerometer {
  translation -0.025450 0.053500 -0.023500
  rotation -1.000000 -0.000000 -0.000000 1.570800
  name "imu_head accelerometer"
}
Gyro {
  translation -0.025450 0.053500 -0.023500
  rotation -1.000000 -0.000000 -0.000000 1.570800
  name "imu_head gyro"
}
Compass {
  translation -0.025450 0.053500 -0.023500
  rotation -1.000000 -0.000000 -0.000000 1.570800
  name "imu_head compass"
}

[jgueldenstein]

I agree and will work on it, a problem is if there are multiple fixed joints in series the first link/solid with physics when going up the kinematic chain towards the root should be used. The transforms would have to be multiplied.

[omichel]

Note: Webots has a mechanism called Solid merger that avoids to create fixed joints. Instead, it multiplies transforms to merge them together into a single Solid, adding masses of each part. So, you should not worry about this in the PROTO file.

[jgueldenstein]

I have tested the solution you proposed but it only works if there is a Physics node in the direct parent.

I think a better solution might be to make the following call recursive and adapt the transformation matrix. https://github.com/cyberbotics/webots/blob/a05248b57540c72651f7353dfd34718c8ffaceba/src/webots/nodes/WbGyro.cpp#L150

What do you think about this solution?

[jgueldenstein]

Or somethink like here could be done: https://github.com/cyberbotics/webots/blob/a05248b57540c72651f7353dfd34718c8ffaceba/src/webots/nodes/WbAccelerometer.cpp#L154

[omichel]

Or somethink like here could be done: https://github.com/cyberbotics/webots/blob/a05248b57540c72651f7353dfd34718c8ffaceba/src/webots/nodes/WbAccelerometer.cpp#L154

Yes, this is exactly what I meant. I believe this is way to go.

[StefanFabian]

Any update on this?
We're having the same problem and this PR is of great interest to us!

[jgueldenstein]

We currently just add a dummy physics node to the Solid which has the IMU as children but I would like to fix this in webots in the future, I just have not gotten to it. It is a bit more complicated than I thought though since the acceleration is not the same as the first parent node with physics if there is a transform in between.

[omichel]

@jgueldenstein: I am happy to help you if you have any question and to review your patch proposals.