Fix timestamp

[exhaustin]

Naively converting the timestamp to a float would result in loss of precision, causing time differences to be incorrectly calculated.

Changes proposed:

Changed the tensor representation of a timestamp to a int32 tensor of size 2, with the first element representing seconds and the second representing nanoseconds.

Test plan:

Tested on a custom controller that uses the timestamp

Potential issue

• Our current way of directing the robot_state into the loaded controller is hard-coded, which may confuse users that are writing custom controllers as to what fields exists in the input state_dict => Update docs
• We should add tutorials for using RobotInterface and running custom controllers using send_torch_policy to the documentation

[1heart]

Why not use a double? Also, let's add a test that catches this particular issue.

[exhaustin]

Why not use a double? Also, let's add a test that catches this particular issue.

Timestamps represent some notion of a absolute point in time and thus are extremely large integer values, while in most of our applications we care about differences in time in the scale of milliseconds. Float64 is able to represent around 16 significant decimal digits, which might still not be sufficient. Ideally we should obtain the exact time difference by subtracting the seconds and nanoseconds then converting that result to float, which should then be easily represented. This is something I realized only after writing the circular motion controllers.