Now I am going to go into some specifics that you will likely not like at all.
The creators of our motor_node wanted to use some very low level code rather than directly pubish /odom. So here we go … hold onto your hats!
In our motor node we periodically update what is called the robot ‘joints’ which in this case means the wheel rotations.
Deep in the depths of some OTHER shared ROS code lies the stuff that takes our wheel geometries and rotation rates in rad/sec and keeps track of ‘wheel odom frame’. This I ‘think’ is what you are asking about basically.
So we instantiate this module as hardware_interface::JointStateHandle joint_state_handle How do do what YOU want to do will be really involved and require digging deep into the _joints stuff.
I personally HATE that layer and NEVER use it on my robots. I leep all my odom frame stuff easily viewable in my own code. We could argue the ‘religion’ of use of pre-existing ROS standards all day and who am I to ‘pass judgement’. Frankly I myself feel it is such a wild abstration that it is if near zero value and was only done because it seemed like the right thing to do at the time.
I myself really have not followed it into the depths. It is a ‘ROS’ sort of ‘standard’ but IMHO is nearly unsupportable by anybody but a ROS Guru (WHICH the guy who did it certainly is). I prefer supportable code that is able to be followed over the ‘beauty of object oriented abstractions’. Again, that is me, hey, I am by title the hardware guy so ‘what do I know’?
There you have it. Such is the case. It works but we do not mess with it.