/odom calculation setup inside the create 3 robot

[adnan-saood]

Hello,

Is the filtering method for calculating the odometer of the robot and fusing all the sensor data available as a paper or a code-base? I want to design my own odometer and I was wondering if the original math is available so I can compare my work to it.

Sorry for reporting this as an issue, this is not the ideal place to discuss this, but I was refereed here by the IRobot Educational support team.

[shamlian]

Hi there,

Agreed on location -- this is not a sim issue. A more appropriate place for this would be in the docs discussions forum, where there is more general conversation about the Create 3 robot.

The fused odometry algorithm in the Create 3 robot is, to my knowledge, not published.

I will try to convert this to a discussion; if I fail, I will close this and you are welcome to open a new discussion at the link above.
Edit: hooray, I did it; if there's more to talk about, or someone wants to correct me, or to suggest some other ideas, we can talk here.

[slowrunner]

I also feel the desire for deeper "theory of operation" information (although not just for the /odom topic).

In explaining the /odom topic "The Create® 3 robot fuses the reading from its various sensors in order to produce a dead reckoning estimate of its pose on the odom topic" avoids mention of the specific sensors, (I believe it is wheel encoders, optical "mouse", and IMU), and avoids the deeper sensor fusion discussion.

Yesterday as I was using the /navigate_to_position action server, my Create3 was translating roughly parallel to a 12mm thick carpet. As the Create3, with 4.5mm clearance, encroached slightly and briefly on the carpet, I wondered if the fusion was strong enough to ignore the wheel slippage or how much error the event would induce in the pose estimate.

[adnan-saood]

Thank you for converting this into a discussion, agreed on the location.

The docs clearly state that the sensors are fused for odometry, but I would have loved to see how it is happening and what sensor models were used. The fusion algorithm would typically have a set of tuning parameters that would indicate how much we trust the measurements of each sensor, knowing that would be also nice.

The problem is that there are, as I understand the theory, multiple ways to fuse these sensors.
The fusion algorithm consists of two stages, prediction, using a robot model $X_{k} = f(X_{k-1},u_k)$, and update using sensor readings. The first question that comes to my mind that the input to the state transition function $f$ can be wheel velocities or wheel displacements from the encoders.

I wrote a sensor fuser in matlab here matlab-tb4odometr that is initially intended for the turltebot4, hence it also fuses the lidar scans with the robot sensors, but we can edit a parameter in the class that would remove the fusion of the lidar scans. right now for the create3, it fuses the IMU, the wheel velocities, and the wheel ticks count. Still working on understanding how to add the mouse sensor.

The robot equations are written in the predict_ function of the class.

Using my odometer (wheel_vels + wheel_ticks + imu), the error RMS in localizing the robot when it does about 6 consecutive turns around a circle of diameter 60 cm with linear velocity of 10 cm/s would be 2~3 cm in $x$ and $y$.

The RMS error with respect to the odom topic is 3~4 cm in $x$ and $y$.

There are additional unclear things, for example, in the docs it is stated that the wheel velocities are published to /wheel_vels, but it did not mention whether this is a simple derivative of the encoder ticks count or a dedicated sensor. Also, the transformations between the sensors and the center of the robot are all written deep in the urdf files, which are not friendly for navigating.

[alsora]

Hi @adnan-saood, we currently don't plan to publish the sensor fusion algorithm used by the Create 3 robot.

Nevertheless, I can answer some of your questions and provide some advice.

The algorithm currently fuses wheel encoders, mouse and IMU readings, and also takes into account the slippage information, to compute the robot pose.
By including a LIDAR in the sensor fusion, you will achieve way better results than what the internal estimation can do.

Still working on understanding how to add the mouse sensor.

The mouse sensor can be very useful in the sensor fusion, as it won't be affected by wheel slippage.
However, there may be surfaces where it's not reliable.
See this discussion with more details about how to use the mouse sensor for pose estimation #493 (comment)

the wheel velocities are published to /wheel_vels

The wheel velocities published on this topic are measured by a dedicated tachometer sensor on the wheels motor controllers.

the transformations between the sensors and the center of the robot are all written deep in the urdf files

The transformations between the various frames of the robot are exposed via the standard ROS 2 tf2 APIs.
For details have a look at the Create 3 coordinate systems documentation and the ROS 2 documentation for tf2

[adnan-saood]

Thank you for this very helpful information. I will mark it as an answer as it provided sufficient information for my original inquiry.

I will post here a link to my ROS2 implementation of the odometer as a controller once it is finished.

Thanks again for the paper,

Sincerely,