The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
Ah, I figured our your issue from edit 1. navsat_transform_node needs ukf_localization_node to produce one message before it can compute the odom->utm transform. When you don't include your /imu/altitude topic, the first message that ukf_localization_node receives is an IMU message with orientation data in it. This causes the odom->utm transform to be computed with the heading that's in that first IMU message. However, when you do include the /imu/altitude topic, the first message ukf_localization_node receives is an altitude message, and so its first output has a different heading, because it hasn't received any heading data yet.
Two things:
ukf_localization_node. In fact, if you turn on publish_filtered_gps, you should find that the GPS data it outputs (/gps/filtered) is the same, even if the X-Y odom frame positions are different.| | 2 | No.2 Revision |
Ah, I figured our your issue from edit 1. navsat_transform_node needs ukf_localization_node to produce one message before it can compute the odom->utm transform. When you don't include your /imu/altitude topic, the first message that ukf_localization_node receives (and therefore the first filtered odometry message it produces) is an IMU message with orientation data in it. This causes the odom->utm transform to be computed with the heading that's in that first IMU message. However, when you do include the /imu/altitude topic, the first message ukf_localization_node receives is an altitude message, and so its first output has a different heading, because it hasn't received any heading data yet.
Two things:
ukf_localization_node. In fact, if you turn on publish_filtered_gps, you should find that the GPS data it outputs (/gps/filtered) is the same, even if the X-Y odom frame positions are different.| | 3 | No.3 Revision |
Ah, I figured our your issue from edit 1. navsat_transform_node needs ukf_localization_node to produce one message before it can compute the odom->utm transform. When you don't include your /imu/altitude topic, the first message that ukf_localization_node receives (and therefore the first filtered odometry message it produces) is an IMU message with orientation data in it. This causes the odom->utm transform to be computed with the heading that's in that first IMU message. However, when you do include the /imu/altitude topic, the first message ukf_localization_node receives is an altitude message, and so its first output has a different heading, because it hasn't received any heading data yet.
Two things:
ukf_localization_node. In fact, if you turn on publish_filtered_gps, you should find that the GPS data it outputs (/gps/filtered) is the same, even if the X-Y odom frame positions are different.EDIT: actually, one more thing: you should also be able to fix this (I say fix, but really nothing is broken) by setting the delay parameter in navsat_transform_node. If the value is high enough, then you will give ukf_localization_node time to receive at least one IMU message with orientation data in it.
| | 4 | No.4 Revision |
Ah, I figured our your issue from edit 1. navsat_transform_node needs ukf_localization_node to produce one message before it can compute the odom->utm transform. When you don't include your /imu/altitude topic, the first message that ukf_localization_node receives (and therefore the first filtered odometry message it produces) is an IMU message with orientation data in it. This causes the odom->utm transform to be computed with the heading that's in that first IMU message. However, when you do include the /imu/altitude topic, the first message ukf_localization_node receives is an altitude message, and so its first output has a different heading, because it hasn't received any heading data yet.
Two things:
ukf_localization_node. In fact, if you turn on publish_filtered_gps, you should find that the GPS data it outputs (/gps/filtered) is the same, even if the X-Y odom frame positions are different.EDIT: actually, one more thing: you should also be able to fix this (I say fix, but really nothing is broken) by setting the delay parameter in navsat_transform_node. If the value is high enough, then you will give ukf_localization_node time to receive at least one IMU message with orientation data in it.
EDIT 2 (to actually respond to your original questions): First, yes, if you don't fuse linear acceleration, the filter will be using only the GPS data to determine its pose. Interestingly, the filter will "create" velocities when you fuse pose only data (due to math within the EKF itself, not from anything I'm doing), though the covariances on those velocities in the filter output will be relatively high. You can try fusing the acceleration data and see what happens. It may just smooth the signal, or the integration of acceleration may start to generate velocity that causes the state estimate to run away.
Second, if your IMU measures roll and pitch and two_d_mode is false, then yes, fuse roll and pitch. To clarify, ekf_localization_node is not doing the same thing as imu_filter_madgwick. imu_filter_madgwick takes raw accelerometer, gyro, and (optionally) magnetometer data and produces an estimate of the orientation. ekf_localization_node does not use raw magnetometer data, and the sensor_msgs/Imu message doesn't contain raw mag data anyway. We use the IMU message's linear acceleration data to compute the vehicle's linear acceleration, linear velocity (integration over time), and position (double integration over time), but we do not use it to compute roll and pitch. Likewise, we use the IMU message's angular velocity data to compute the vehicle's angular velocity and orientation (integration over time).
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.