mikkelkh / FieldSAFE

Agricultural Dataset with Static and Moving Obstacles
22 stars 18 forks source link

Pose Estimation - General Questions #6

Closed jmount1992 closed 2 years ago

jmount1992 commented 2 years ago

Thanks for the dataset. I am looking at using it in my own research, however, I have a few questions regarding the demo.launch.

  1. I noticed in the rtk_gps_node you subscribe to the topic /fmData/can_rx_rtk_gps but, this topic does not exist (in the list of provided topics or in the example bag). This means that /Trimble_rtk_gps/course_speed_can and /Trimble_rtk_gps/GNSS_position_data_can are not generated. Are these topics not required?
  2. In the robot_localization.launch you use a navsat_transform_node to produce odometry from GPS. Why do you utilise the /Trimble_rtk_gps/imu topic, created by converting the GPS heading data into a sensor_msgs/Imu message, rather than utilising the /VectorNav_IMU/imu topic? Is it simply to increase the amount of information going into the EKF?
mikkelkh commented 2 years ago

Hi jmount,

  1. I understand your confusion. The node rtk_gps_node can handle inputs from the GPS by two interfaces, either as either serial messages or CAN bus messages. Therefore, both topics exist. In our case, we use serial messages, and therefore /fmData/can_rx_rtk_gps doesn't exist, which means the two *_can topics are not generated. Instead, /Trimble_rtk_gps/SerialSentence is generated, which is passed to nmea_navsat_driver that generates the required GPS messages. In short, the CAN topics are not required.
  2. We trust the GPS heading more than the IMU heading (yaw), as the GPS is a dual-antenna RTK GPS. Therefore, we convert it to a sensor_msgs/Imu message and use that with the EKF. If you look inside robot_localization.launch, you can see that we still use pitch and roll from the actual IMU (/VectorNav_IMU/imu), but just replace its yaw measurements with the one from the GPS (Trimble_rtk_gps/imu). A bit hacky, but it works :-)
jmount1992 commented 2 years ago

Thanks @mikkelkh! That all makes sense to me. I did see that you were still using the /VectorNav_IMU/imu in the localisation stage and assumed that it was for the reason you described. However, I just wanted to confirm my suspicions.