mouse sensor coordinate conventions: FLU or RFU?

[carlsondc-ceva]

Hello! Looking at the "mouse" sensor output, I'm having a hard time understanding the coordinate systems in use. The relevant tf_static message is:

- header:
    stamp:
      sec: 1649934605
      nanosec: 502703618
    frame_id: base_link
  child_frame_id: mouse
  transform:
    translation:
      x: 0.10195013880729675
      y: 0.08774954080581665
      z: 0.04
    rotation:
      x: 0.0
      y: 0.0
      z: 0.9277159639721808
      w: 0.37328687385329695

The rotation corresponds to a 136.16 degree rotation about +Z. To verify this, I slid the robot along the floor from a central point to various locations on a circle, every 45 degrees (going clockwise). e.g. forward to 12 o'clock and back, then forward/right to 1:30 and back, then right to 3 o'clock and back, etc.

The X and Y outputs looked like this:

So it appears that sensor X is at 10:30 and sensor Y is at 7:30. This would be a 46.16 degree rotation about +Z to take X and Y from Forward and Left to these positions.

Is the mouse sensor reporting data in non-FLU conventions? This would make the published transform consistent, for example, with the raw sensor output being in Right-Forward-Up conventions instead.

[justinIRBT]

If I start from 0 and drive straight, /odom goes from:

header:
  stamp:
    sec: 1650310476
    nanosec: 361175318
  frame_id: odom
child_frame_id: base_link
pose:
  pose:
    position:
      x: -2.0966406736988574e-05
      y: 2.4170678443624638e-05
      z: 0.0
    orientation:
      x: -0.0022328663617372513
      y: -0.005287309177219868
      z: -0.00013136824418324977
      w: 0.9999834895133972

to

header:
  stamp:
    sec: 1650310595
    nanosec: 358193838
  frame_id: odom
child_frame_id: base_link
pose:
  pose:
    position:
      x: 1.7290308475494385
      y: 0.015543133020401001
      z: 0.0
    orientation:
      x: -0.00022472145792562515
      y: 8.089982293313369e-05
      z: -0.0003444966860115528
      w: 0.9999999403953552

The corresponding /mouse data starts from:

header:
  stamp:
    sec: 1650310342
    nanosec: 582040720
  frame_id: mouse
integrated_x: 0.01509608794003725
integrated_y: 0.02204170636832714
frame_id: 261
last_squal: 105

and goes to:

header:
  stamp:
    sec: 1650310563
    nanosec: 843901433
  frame_id: mouse
integrated_x: -1.2043135166168213
integrated_y: -1.2039449214935303
frame_id: 261
last_squal: 91

This is illustrated in rviz:

From the 0,0 starting point where the mouse frame was oriented 136 degrees, after driving forward 1.7m, the mouse is now at -1.2 in that original mouse x coordinate frame and -1.2 in that original mouse y coordinate frame as the mouse data reports. So I believe the mouse frame orientation is consistent in this test. If I I understanding your test correctly, it looks like you got positive mouse x for forward motion? Were you driving the robot forward or moving it by hand?

[carlsondc-ceva]

Hello! Thanks for the quick response.
My apologies, I was running a stale build of an in-house utility for extracting data from a ROS bag. The updated behavior looks as you described, with +Y at 4:30 and +X at 7:30. When I move forward, I see negative X and Y motion.

Sorry for the false alarm!