Closed jmount1992 closed 2 years ago
Hi jmount,
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.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 :-)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.
Thanks for the dataset. I am looking at using it in my own research, however, I have a few questions regarding the
demo.launch
.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?robot_localization.launch
you use anavsat_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 asensor_msgs/Imu
message, rather than utilising the/VectorNav_IMU/imu
topic? Is it simply to increase the amount of information going into the EKF?