Matty - integrate protocol version 8 (IMU data)

[m3d]

There is new FW available for Matty platform supporting now IMU data (see robotika/matty#14). This is the first step to accept new (longer) messages with [roll, pitch, yaw] angles in 1/100th degrees resolution. This change should be fully backward compatible.

[m3d]

Added also option to plot the data:

[tajgr]

I would like to keep some standard terminology. For this kinds of data we already have rotation. Please, could you use it instead of rpy?

[m3d]

OK, thanks - and is "rotation" defined as "roll, pitch, yaw" in 1/100deg, i.e. integers?

…

On Fri, Aug 8, 2025 at 6:54 PM Jakub Lev ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In osgar/platforms/matty.py <#1028 (comment)>: > @@ -61,10 +61,11 @@ class Matty(Node): def __init__(self, config, bus): super().__init__(config, bus) bus.register('esp_data', 'emergency_stop', 'pose2d', 'bumpers_front', 'bumpers_rear', 'gps_serial', - 'joint_angle') + 'joint_angle', 'rpy') I would like to keep some standard terminology. For this kinds of data we already have rotation. Please, could you use it instead of rpy? — Reply to this email directly, view it on GitHub <#1028 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLG4YOOHX527TKZBPIY7O33MTI25AVCNFSM6AAAAACDN4AKG2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTCMBRGU4DANBWHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tajgr]

According to this link:
https://github.com/robotika/osgar/blob/master/osgar/drivers/imu.py#L97
it should be [yaw, pitch, roll] 1/100deg (integers).

[m3d]

I remember that with the angles there was so much confusion that we started to use Quaternions - I would use that too in some later PR (terrain does not seem to be that critical for DTC). What I would like to have is if I go 20deg uphill, that it will be clear from the angles and the number will be the same if I go north or west, i.e. "yaw" is absolute heading here. Also the numbers I publish are 1:1 to what I receive from ESP32, no modifications. I could rename it to "rotation" and swap the order without taking care if applied order is the same, but it will be most probably wrong.

[m3d]

OK, added also rotation and orientation quaternion - I am not sure if that is correct, actually I am almost sure it is wrong, but at the moment I am more interested in calibration and proper raw values from ESP32 (i.e. to be fixed by some later PR?)

[tajgr]

Thanks. From my (formal) perspective, it's fine.