Is gyro used for odom data on Turtlebot 2

[Wouter Lammens]

I am a little bit puzzled about the odometry on the Turtlebot :

- When I read IMU data, I can see angular rates about the three axes, or the angular position about the z-axis.
- The joint states topic gives the wheel velocities and the position of the wheel encoders

Now I am wondering how the data on the odometry topic is composed. Are IMU and encoder data combined and how? Since there are only angular rates available, how can they be used in odom? Is IMU only used in turns perhaps? At which rate does this happen?

Kind regards,
Wouter

[Daniel Stonier]

If you are using the ros driver, you can see in the code here what is going on. It will generate heading values from the wheel odometry itself unless the `imu_angular_velocity` is flagged, in which case it will just defer to the internal gyro for yaw calculations (which is far better than wheel odometry).

Daniel

[Daniel Stonier]

On Fri, May 6, 2016 at 4:00 PM, Wouter Lammens <wouter....@student.kuleuven.be> wrote:

>
> I am a little bit puzzled about the odometry on the Turtlebot :
>
> - When I read IMU data, I can see angular rates about the three axes, or the angular position about the z-axis.
> - The joint states topic gives the wheel velocities and the position of the wheel encoders
>
> Now I am wondering how the data on the odometry topic is composed. Are IMU and encoder data combined and how? Since there are only angular rates available, how can they be used in odom? Is IMU only used in turns perhaps? At which rate does this happen?

>
> Kind regards,
> Wouter
>
>
> If you are using the ros driver, you can see in the code here what is going on. It will generate heading values from the wheel odometry itself unless the `imu_angular_velocity` is flagged,

So I can assume it normally just uses wheel encoders for both linear and angular position and velocities?

It's parameterised. By default the turtlebot uses the gyro for orientation data. If users want to do something more complicated with sensor fusion, they can disable it and do the fusion outside with something like robot_pose_ekf. 

>in which case it will just defer to the internal gyro for yaw calculations (which is far better than wheel odometry).

If I understand the code correctly, there is not really sensor fusion, but only a replacement of angular values by the ones provided by gyro?

It is still fusion, but yes, it is in effect replacement. 

Lastly, in many other robots they use IMU data to estimate the pose of a device, without using wheel encoders. Since the Turtlebot 2 Kobuki base only uses gyro, is this then possible?

IMU data is not very reliable for translational quantities. And although it's a 3D gyro, only 1D is effectively filtered. There is a raw topic that people can use to do their own filtering.

.

Wouter
>
>
> Daniel