Localization warnings and errors

[bsb808]

I still get a number of warnings and an error when using the robot localization example as described here: https://github.com/osrf/vrx/wiki/tutorials-ExampleVrx

Setup: I'm working with the master branch and running on, what I believe to be, an updated noetic docker image from dockwater.

When I run roslaunch wamv_gazebo localization_example.launch...

1. navsat_transform_node terminates with the following error:

terminate called after throwing an instance of 'GeographicLib::GeographicErr'
  what():  Latitude -33.7228, longitude 150.674 out of legal range for UTM zone 4
[wamv/robot_localization/navsat_transform_node-4] process has died [pid 1043, exit code -6, cmd /opt/ros/noetic/lib/robot_localization/navsat_transform_node /wamv/robot_localization/gps/fix:=/wamv/sensors/gps/gps/fix __name:=navsat_transform_node __log:=/home/bsb/.ros/log/a4e586bc-1192-11ec-81cf-0242ac110002/wamv-robot_localization-navsat_transform_node-4.log].
log file: /home/bsb/.ros/log/a4e586bc-1192-11ec-81cf-0242ac110002/wamv-robot_localization-navsat_transform_node-4*.log

• I have partially fixed this with PR Updating datum for navsat_transform_node #341

• But the way the datum rosparam is specified appears to be inconsistent with the robot_localization documentation - it is missing the explicit frame declarations. Have we verified that these frames do not need to be specified?

• Once I fix that issue, then I still get warnings that are note documented in the wiki tutorial https://github.com/osrf/vrx/wiki/tutorials-ExampleVrx

  • E.g.

[ WARN] [1631208711.225154935, 468.467000000]: Transform from wamv/imu_wamv_link to wamv/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1631208711.253446492, 468.493000000]: Transform from wamv/gps_wamv_link to wamv/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1631208713.442757568, 470.467000000]: Transform from wamv/imu_wamv_link to wamv/base_link was unavailable for the time requested. Using latest instead.

[ WARN] [1631208713.470328905, 470.493000000]: Transform from wamv/gps_wamv_link to wamv/base_link was unavailable for the time requested. Using latest instead.

AND

         at line          at line 278278 in  in /tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp/tmp/binarydeb/ros-noetic-tf2-0.7.5/src/buffer_core.cpp

Warning: Warning: TF_REPEATED_DATA ignoring data with redundant timestamp for frame wamv/lateral_propeller_link at time 471.232000 according to authority unknown_publisherTF_REPEATED_DATA ignoring data with redundant timestamp for frame wamv/lateral_propeller_link at time 471.232000 according to authority unknown_publisher

If these warnings are expected, we need to let users know that.

I feel like I may have a problem with my setup as I know folks have worked extensively on these issues.

[caguero]

@tfoote and I found a relatively easy fix. We just need to change the joint type connecting the base_link to the IMU, GPS and ball shooter links. If the type is a revolute joint with no limits we see the issue. If we change the type to a fixed joint it fixes the problem.

The only reason I'm holding the fix is because I remember Kevin from UF raised an issue and if I remember correctly that was the reason for this change. Unfortunately, the issue was on BitBucket and it's pretty much gone. What I remember is that the GPS/IMU was always located at the base_link (as opposed to be located at the exact pose set by the team) unless we made this change (converting it to a revolute joint with no limits).

[M1chaelM]

The relevant issue was migrated to #188 of this repository. Further, @tfoote observes:

somewhere in the process of URDF -> SDF there's an "optimization" which collapses fixed links into a single link for obvious simulation computational improvements. However in doing so the intermediate links "disappear" and so the child links are reparented to the combined parent link. However if this is done without adjusting the pose of the child. I suspect that this is actually done, but the plugin assumes that the sensor is at the origin of the link because we typically create a specific link to represent the mounting posiiton of the sensors. But if the links are collapsed then suddenly the GPS or IMU is no longer attached to the semantically useful sensor mount link on the roof, but to the base link at the rear axle etc.

The double publishing I think is a separate bug that should be resolved. Which we're just avoiding rather than solving by changing the link type.

So it looks like our workaround for a previous bug is preventing us from using a workaround for the current bug. Consequently, this will take more looking into. I will move the issue to a future release.

[caguero]

Apparently it's possible to suppress the tf warnings via a ros parameter. I looked into the code to understand how that parameter was used and I realized that it wasn't fully propagated to all the places. I created a pull request upstream to fix it.

cra-ros-pkg/robot_localization#705

Then, it works for me locally adding this line to localization_example.launch.

<!-- Supress tf warnings -->
  <rosparam param="silent_tf_failure">true</rosparam>

I'll add it to VRX when the upstream patch is merged.

[caguero]

The upstream patch has been merged. Now we need to suppress the warnings. See #402.