Autoeare.Universe:Unable to initialize using Eagleye method

[yuanchao16]

We are using GNSS connected to the RTK base station. The GNSS has dual antennas with an accuracy within 10cm. We take the IMU from the combined inertial navigation as the value for the /sensing/imu/tamagawa/imu_raw topic, the speed value obtained from the combined inertial navigation as the value for the /sensing/gnss/ublox/twist topic，the latitude and longitude values obtained from GNSS are assigned as the value for the /sensing/gnss/ublox/nav_sat_fix topic.
The options in eagleye_config.param.yaml are as follows:

The options in eagleye_rt.launch.xml are as follows:

However, the topic eagleye/fix has no value, and the heading value of eagleye/heading_interpolate_3rd remains at 0. As a result, we cannot get eagleye/pose_with_covariance to initialize the pose.

May I know the reason for this? Please provide answers or suggestions.

Thank you very much,
Warmest regards,

[maxime-clem]

Thank you for opening this discussion.

May I suggest also creating an issue on the eagleye repository ? https://github.com/MapIV/eagleye
I think this will increase the chance that some eagleye developers notice your issue.

Also, when sharing source code, I recommend using copy and paste (inside a code block using the delimiter ```) instead of screenshots.

[yuanchao16]

Thank you for your suggestion！

[rsasaki0109]

@yuanchao16

To verify that Eagleye is running properly, it has two initialization phases: static initialization and dynamic initialization. I recommend checking the following topics:

• /eagleye/yaw_rate_offset_stop topic
  When the enabled_status of this topic becomes true, the static initialization is complete, which involves a few seconds of stoppage, regardless of whether you are indoors or outdoors.
• /eagleye/heading_xx, /eagleye/enu_absolute_pos topics
  Dynamic initialization requires straight-line driving in an environment with GNSS speed (it's okay if a curve is involved midway). I particularly check these two topics. When heading_xx's enabled_status becomes true, you can assume that the initialization is progressing without any issues. When the enabled_status of position becomes true, it indicates that all initialization processes are complete.

The following may be helpful.
https://autowarefoundation.github.io/autoware-documentation/main/how-to-guides/integrating-autoware/launch-autoware/localization-methods/eagleye-guide/

[yuanchao16]

Thank you for your suggestion！
I saw in your previous response that it was possible to use dual antennas for static initialization.
https://github.com/orgs/autowarefoundation/discussions/3644
“If use_multi_antenna is set to true and gnss_compass_pose is entered into eagleye, the position posture is output without Dynamic Initialization.”
The GNSS I use can directly output the pose correctly. Do I still need to use gnss_compass_pose to output the /gnss_compass_pose (geometry_msgs/PoseStamped) /gnss_compass_odom (nav_msgs/Odometry) /illigal_gnss_compass_odom (nav_msgs/Odometry) /diagnostics ([diagnostic_msgs/DiagnosticArray) and /tf(from "map" to "base_link") ？
In addition, I have some questions about /main/mosaic/gga (nmea_msgs/Gpgga) and /sub/mosaic/gga (nmea_msgs/Gpgga) in gnss_compass_pose. When we use dual-antenna GNSS connected to RTK, only one pose will be output when the solution is fixed. I don’t quite understand what /main/mosaic/gga and /sub/mosaic/gga refer to? The GNSS output we use will only output one GPGAA.
Looking forward to your reply, thank you very much！！！

[yuanchao16]

In my test today, I found that when /eagleye/yaw_rate_offset_stop's enabled_status、 /eagleye/heading_1st's enabled_status and /eagleye/enu_absolute_pos's enabled_status all become true, the display in RVIZ is still uninitialized.

In addition, the fix2pose_node was not running. Therefore, even though the topic /eagleye/fix already exists, the topic /localization/pose_estimator/pose_with_covariance is not published.

Do you know what caused it?

[rsasaki0109]

Sorry for the late reply. I didn't notice. I think there should be messages related to fix2pose in the terminal output, so we need to check that.