HIGHRES_IMU attribute collision

[Domattee]

In MAVLink v2, HIGHRES_IMU (id 105) messages have a field called "id", which collide with the message type class attributes (also "id"). The class attribute intended to store the message id instead stores the ID of the source IMU. This causes issues when using msg.id to determine the type of message received, in my case HIGHRES_IMU messages were being treated as heartbeats. I assume the collision is present in all v20 dialects, since it is a base mavlink message, but definitely in ardupilotmega and cubepilot.
I think pymavlink message composing/parsing methods might also be affected, because I kept getting missing attribute errors trying to use msg.get_msgId() on HIGHRES_IMU messages.

[peterbarker]

Have you tried the get_type method?

[Domattee]

I used get_msgId, the issue with that was a bug on our side with bad V1 vs V2 communication.