Problem about IMU coordinate system

[yenlunliao]

Sorry to bother,

I am using Tamagawa TAG300N1000 IMU in egaleye, but the result is not satisfied. The movement that eagleye predicts seems having a wrong direction against the gnss signal.

Blue line is gnss signals and the red line is the prediction from eagleye. When the prediction activates, it owns a correct distance but wrong direction.

I guessed it is due to wrong coordinate system. I would like to make sure whether my IMU settings is correct. IMU in my system has x-direction for head of car, y-direction indicates the right of car, and z-direction points to the ground currently.
Do I need to add transform or change the settings of the imu to make the eagleye works?

Thanks.

[rsasaki0109]

Please change the following true/false values. Alternatively, modifying the tf of base_link-imu is also acceptable.
https://github.com/MapIV/eagleye/blob/autoware-main/eagleye_rt/config/eagleye_config.yaml#L30

[yenlunliao]

Thanks for the response,
I changed reverse_imu_wz factor to true, but it seems that the result is not improved.

[rsasaki0109]

It may not be an issue with the IMU coordinate system. If you could provide the rosbag, I can check what the problem might be.
If the problem seems complex, I might not be able to provide a solution right away, though...

[yenlunliao]

This is the link of the ros2 bag: https://drive.google.com/drive/folders/1gwB4HfVbIHz_Lkaxrx9eUYSB5y6vEhls?usp=drive_link

I am using:

/rav4/ma65/fix                      #gnss position (2 hz)
/rav4/ma65/gnss_vel            #gnss velocity (2 hz)
/rav4/adv_nav0/can_twist    # wheel speed
/imu/data                              # tamagawa imu (200 hz)
/rav4/adv_nav0/imu             # another imu (50 hz)

I only have geometry_msgs/TimeStamped for gnss velocity topic in the bag. So I canceled the covariance checking in https://github.com/MapIV/eagleye/blob/main-ros2/eagleye_util/gnss_converter/src/gnss_converter_node.cpp#L112 to make it works.

Thanks you a lot, sorry for taking your time.

[rsasaki0109]

I can't say for sure if this is the cause, but it feels like the car speed sensor's resolution is too rough. It seems a bit difficult, so I'll take another look at it later.

[yenlunliao]

Some update:
I try to use canless mode to get rid of the influence of the speed sensor. Eagleye will start as every gnss point it received and predict the path until getting next gnss signal. However, it seems that the direction of predicted path is incorrect as well.

[rsasaki0109]

Can you show me the YAML file you're using?

[rsasaki0109]

I checked the /rav4/ma65/nmea_sentence in your rosbag, but it seems like it's not RTK, right? Since the canless mode requires RTK positioning, I feel like it wouldn't be able to position...
https://github.com/MapIV/eagleye?tab=readme-ov-file#can_less-mode

[yenlunliao]

This is my settings of config:

  ros__parameters:
    # Estimate mode
    use_gnss_mode: RTKLIB
    use_can_less_mode: true

    # Topic
    twist:
      twist_type: 0 # TwistStamped : 0, TwistWithCovarianceStamped: 1
      twist_topic: /rav4/adv_nav0/can_twist
    imu_topic: /imu/data_raw
    gnss:
      velocity_source_type: 4 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, ublox_msgs/NavPVT: 2, geometry_msgs/TwistWithCovarianceStamped: 3
      velocity_source_topic: /rav4/ma65/gnss_vel
      llh_source_type: 1 # rtklib_msgs/RtklibNav: 0, nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
      llh_source_topic:  /rav4/ma65/nmea_sentence

    sub_gnss:
      llh_source_type: 1 # nmea_msgs/Sentence: 1, sensor_msgs/NavSatFix: 2
      llh_source_topic:  /sensing/sub_gnss/nmea_sentence

I added a message of type geometry_msgs/TwistStamped to receive gnss message. It is similar to geometry_msgs/TwistWithCovarianceStamped but without check of covariance.

I am not using RTK, so I set up the RTK bit manually. My target is receive an acceptable localization result with more than 10 hz. So I try to replace the computed velocity with wheel speed to find whether it works.

I will check the hardware settings and test whether it is the speed sensor yeild the bad performance. Thanks for the suggestion.