Eagleye Test and Comparing Other Localization Sources

[meliketanrikulu]

This report includes the comparison results of pose estimation modules of Autoware Ndt-Ekf and ClapB7 GNSSINS Receiver EKF output and Eagleye.

Our test car has includes these sensors:

Sensor	Model
GNSS/INS	ClapB7
Lidars	RS Helios 32 - 2 X RS-Bpearl

You can see here our test robot :

We are using concatenated point cloud for NDT and we also feed velocity to EKF for Autoware standart pipeline. Here linear velocity source is our vehicle odometry and angular velocity is comes from imu data.

In this test scenario, the standard Autoware EKF output (only NDT and velocity input are given), the EKF output produced by the GNSSINS sensor(CLAPB7) used, the raw GNSS data and the positions obtained in the eagleye output (comes from /eagleye/fix topic) are compared.
At some point during the test, the RTK connection was disconnected and the responses of the eagle and the sensor EKF(CLAPB7 GNSSINS) were monitored in a scenario where GNSS errors were high.

During the tests, the standard Autoware EKF output fed by NDT was also used as the base localization result. The position values of both localization sources (CLAPB7 GNSSINS EKF results and eagleye output) were compared with these position values. Position differences were monitored using plotjuggler.

Note: Local Cartesian UTM projection method was used for the map and incoming position values.

Tests

On the Rviz screen:

1. Trajectories

• Green Trajectory --> Eagleye Output (comes from /eagleye/fix topic)
• Red Trajectory --> ClapB7 GNSSINS EKF Output
• Yellow Trajectory --> ClapB7 GNSSINS Raw GNSS Data
• Blue Trajectory ---> Autoware standart EKF output (only NDT and velocity input are given)

2. GNSS Error RVIZ Plugin : CLAPB7 GNSSINS EKF Absolute Position Error (uses position_x and position_y RMSE)
3. Plotjuggler:
   • clap_ekf_position_difference_x: Autoware Standart EKF (only NDT and velocity input are given) and ClapB7 EKF output position difference for X axis
   • clap_ekf_position_difference_y: Autoware Standart EKF (only NDT and velocity input are given) and ClapB7 EKF output position difference for Y axis
   • eagleye_position_difference_x: Autoware Standart EKF (only NDT and velocity input are given) and Eagleye output position difference for X axis
   • eagleye_position_difference_y: Autoware Standart EKF (only NDT and velocity input are given) and Eagleye output position difference for Y axis

Results

Test ID	Description	Video Link
1	In this video, you can watch the eagleye results, standard Autoware EKF (only NDT and velocity input are given), raw GNSS data, and the trajectories of GNSSINS EKF results. After 2:28 in the video, RTK connection is lost and GNSS errors increase. You can also see the results in this condition	Video 1
2	In this video, you can see the position differences of the eagleye and Clap sensor EKF compared to Autoware's standard EKF (only NDT and velocity input are given) in x and y in Plotjuggler, along with the RVIZ results. RTK connection is lost after 3:36 in the video. You can see the increase in GNSS errors here.	Video 2
3	This video includes covariance values output (/eagleye/fix)	Video 3

Conclusion:

• In cases where GNSS errors are high, eagleye gives more successful results than the sensor (CLAPB7 GNSSINS) EKF we use.
• Position differences between NDT and eagleye output increase during turns.
• The covariance values high that is output /eagleye/fix topic 's output. We discuss it in this issue . Because it uses default values instead of covariance data that comes from gnss. I think it can be cause some problems in the future when we want to use that position values as a localization source. Maybe we can add option for people who want to use gnss covariance values.

For reproduce the test:

• Parameter file is here
• Test data is here
• Please run this command for transformation between sensor and base_link:

ros2 run tf2_ros static_transform_publisher 0.0 0.5 1.1350 0 0 0 base_link GNSS_INS/gnss_ins_link

• Run projection converter tool (I project all localization sources in LocalCartesianUTM with that tool) (optional)