Frame IDs in the /ins topic seem incorrect. Also missing covariances on some variables.

[Srijal97]

Hello!

As per the ROS nav_msgs/Odometry template, the pose part of the message has to be specified w.r.t header.frame_id, and the twist part has to be in the frame specified by child_frame_id. However, in the case of the uINS, even though it reports both pose and twist, only header.frame_id is populated. Also, this value of header.frame_id is filled with the sensor frame on the robot, when it should actually be the world fixed frame w.r.t which pose is calculated. child_frame_id should be the name of the sensor frame on the robot.

Additionally, why are covariances not reported for all variables in /ins? I see this part of code commented in the source files, could you please explain why this was excluded?

[andrewpriddis]

@Srijal97 - The header.frame_id is a parameter intended to be set by the user according to their needs. This is described in the README. For our development purposes the default frame_id suffices and the child_frame_id is not needed. One of the beauties of open source code is that the user is free to add whatever features they require. In this case you will want to add the appropriate child_frame_id.
Previously covariance information has not been available. Our next firmware release includes a new feature allowing the publishing of covariance data. The development branch of this repo has the new code required to get covariance data as well as other updates. It will be released with our next firmware release.

[Srijal97]

I personally found the documentation under README very confusing. Maybe some examples and additional descriptions would be helpful. Could you please make a few clarifications:

1. ins topic description says that the "pose portion is from inertial to body"; from what I understand, the inertial frame is the NED/ENU frame (chosen by the LTCF parameter), centered at GPS_ref_lla? If this is the case, then header.frame_id needs to be a world-fixed frame that I create in NED/ENU format at the reference GPS LLA that I set?
2. child_frame_id needs to be set to the uINS sensor frame ID on the body of the robot as all twist readings is in the uINS's own frame, so I will go ahead and do that on my end.
3. What exactly are the parameters INS_rpy_radians and INS_xyz? The description mentions that its the rotation and translation from the INS frame to the output frame. The documentation at Inertialsense Docs mentions a "INS Output Frame", so the naming is inconsistent. My guess is that these parameters are useful if you want the uINS measurements to be directly converted to a different frame on the robot body (e.g. base_link).

It is interesting that publishing covariances is an upcoming feature. Can I use the development branch code with the existing uINS firmware?