Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Comparing sensors data between Python and Simulate #719

Closed
itamar-dw opened this issue Jan 31, 2023 · 7 comments
Closed

Comparing sensors data between Python and Simulate #719

itamar-dw opened this issue Jan 31, 2023 · 7 comments
Labels
bug Something isn't working

Comments

@itamar-dw
Copy link

itamar-dw commented Jan 31, 2023 •
edited
Loading

Hi,
I am comparing the numerical values of accelerometer and gyro sensors with the visualization in the Simulate app, and get different results. I want to understand where does this difference come from (my code or something else). I'll focus on gyro since it's enough to demonstrate the issue.

Here is a model which explains my question:

Mujoco XML model 
<mujoco model="sensors_test_no_gravity">
  <option gravity="0 0 0"/>
  <asset>
    <texture name="grid" type="2d" builtin="checker" rgb1=".1 .2 .3" rgb2=".2 .3 .4" width="300" height="300"/>
    <material name="grid" texture="grid" texrepeat="8 8" reflectance=".2"/>
  </asset>

  <worldbody>
    <geom name="floor" size="2 2 .01" type="plane" material="grid"/>
    <light name="top" pos="0 0 2"/>

    <body name="box_and_sphere"  pos="0 0 1" euler="0 0 0">
      <site name="imu1" pos="0 0 .2" rgba="0. 1. 0. .5"/>
      <joint name="ball_joint" type="ball" pos="0 0 0" />
      <geom name="red_box" type="box" size=".1 .1 .2" rgba="1 0 0 1"/>
    </body>
  </worldbody>
  <sensor>
      <gyro name="gyro" site="imu1" />
  </sensor>
  <keyframe>
    <key name="init_qvel" qvel="1 1 1" />
  </keyframe>
</mujoco>
In Simulate app I load the keyframe, then start the simulation for about 4 sec. In Python, I load the keyframe in the code, and run for 4 sec:
Python code 
import mujoco
import numpy as np

with open('test.xml', 'r') as f:
    xml = f.read()
model = mujoco.MjModel.from_xml_string(xml)
data = mujoco.MjData(model)
mujoco.mj_resetDataKeyframe(model, data, 0) 

gyro = []
ts = []
while data.time < 4:
    mujoco.mj_step(model, data)
    gyro.append(data.sensor(0).data.copy())
    ts.append(data.time)
  
gyro = np.vstack(gyro)
ts = np.r_[ts]

When I plot gyro I see that:

  1. The z component is constant
  2. The x component grows above the value of 1 and then drops to 0
    image

However, when looking at the sensor visualtization in Simulate, I see that

  1. The x component does not grow above 1
  2. The z component oscillates between 1 and ~0.7.

So, the x behavior may be explained if the value is just clipped to 1 by the graph's y-axis upper limit (that is, a visualization issue). But the behavior of z component cannot be explained. (btw as a sanity check I also compared with data.qvel and not surprisingly got the same values as in data.sensor(0).data).

Sensor visualization at t=1.3, demonstrating both issues:
image

[EDIT] When I use the "watch" option in Simulate I see indeed the the x value is clipped by the visualization, but the z value is constant at 1, like I get in Python, while in the graph it oscillates.
@itamar-dw itamar-dw added the question Request for help or information label Jan 31, 2023
@yuvaltassa
Copy link
Collaborator

Interesting! This could either be due to a bug in simulate or in the Python bindings.

Could you please do the following two checks:

  1. In simulate please use the "print data" button to save the entire state of mjData to a text file.
  2. In Python, instead of using the accessor data.sensor(0).data, please use data.sensordata.

The numbers that you see correspond to which values?

@yuvaltassa
Copy link
Collaborator

I took a look a quick look myself.
This is disturbing. Marking as a bug.

@yuvaltassa yuvaltassa added bug Something isn't working and removed question Request for help or information labels Feb 1, 2023
@itamar-dw
Copy link
Author

Interesting! This could either be due to a bug in simulate or in the Python bindings.

Could you please do the following two checks:

1. In `simulate` please use the "print data" button to save the entire state of `mjData` to a text file.

2. In Python, instead of using the accessor `data.sensor(0).data`, please use `data.sensordata`.

The numbers that you see correspond to which values?

I guess you already saw it: Only the visualization does not match, all other numbers do match

@yuvaltassa
Copy link
Collaborator

But does it make sense that the z-axis value is constant?
Intuitively I would expect them all to oscillate, even a little bit, right?

@itamar-dw
Copy link
Author

itamar-dw commented Feb 1, 2023 •
edited
Loading

But does it make sense that the z-axis value is constant? Intuitively I would expect them all to oscillate, even a little bit, right?

Yes, it makes sense since in torque-free rotation (which is the case since I set gravity="0 0 0") the z component of the angular velocity is a constant of motion. See for example https://phys.libretexts.org/Bookshelves/Classical_Mechanics/Variational_Principles_in_Classical_Mechanics_(Cline)/13%3A_Rigid-body_Rotation/13.20%3A_Torque-free_rotation_of_an_inertially-symmetric_rigid_rotor

(Actually it should be the case also with gravity, since gravity operates on the center-of-mass so it is still torque-free)

@itamar-dw
Copy link
Author

But does it make sense that the z-axis value is constant? Intuitively I would expect them all to oscillate, even a little bit, right?

Yes, it makes sense since in torque-free rotation (which is the case since I set gravity="0 0 0") the z component of the angular velocity is a constant of motion. See for example https://phys.libretexts.org/Bookshelves/Classical_Mechanics/Variational_Principles_in_Classical_Mechanics_(Cline)/13%3A_Rigid-body_Rotation/13.20%3A_Torque-free_rotation_of_an_inertially-symmetric_rigid_rotor

(Actually it should be the case also with gravity, since gravity operates on the center-of-mass so it is still torque-free)

Just to be clear, this holds because of the inertial symmetry of the specific body I use (box with equal width and depth)

@yuvaltassa
Copy link
Collaborator

yuvaltassa commented Feb 3, 2023 •
edited
Loading

The issue was: the plot was not being clipped, but the y-axis didn't have enough precision to show that. I.e., the y-axis was changing but you couldn't see it. So this is now fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@yuvaltassa @itamar-dw