First Robot - Rubbish odom & Laser_scan_matcher architecture

edit

Hi All

I have been playing with ROS1 for 6 weeks or so.

I have a robot built - 2 motors and a caster - differential drive, pi 4 (no arduinio etc), motor controllers, 2 x wheel encoders, ld19 lidar, ICM20948 IMU.

I have Ubuntu 20.04 on the Pi and on a virtual machine on the laptop, ROS Noetic installed on both, a driver node and odom node written, ld19 and imu drivers working into ROS.

My (I say my, mostly used from various tutorials) code is all here: https://github.com/KevWal/ROS-Bot-Wor...

My odometry quality seems to be rubbish, displaying my odometry transform in rviz is not bad in a straight line, but in a turn is totally unreliable - often being 90 deg out in either direction in a 360 deg turn. I have tried with Yellow 'tt' motors - but they are a bit fast and because the encoders are on the same shaft as the wheels you get very few encoder ticks per ROS spin. I have also tried with Micro Metal Gear motors, with magnetic encoders directly on the moto shafts - allows a driver node frequency of 10hz with plenty of encoder ticks per ROS spin, but was still very unreliable in rviz for me.
Q1) Any thoughts on should it be better, am I doing anything wrong, etc?

I have tried robot_pose_ekf setups to improve the odometry (robot_pose), but didnt manage to get anything better.

With the TT motors limited to their minimum speed, or with the much higher geared Micro Metal motors I have successfully created a map with Hector (hector_mapping.launch called from bringup.launch) - launch files.

I wondered if amcl would deal with my poor odometry when combined with the laser scanner, but even with very high odom_alpha settings it didn't give a good result, didn't manage to keep the map aligned with reality. Old Launch Files

Lots of research later I do think I have got my head around the frames used and the transformations between them. I wrote out my understanding:

world
  |
  | - static tf
  |
 map - Origin = Where mapping 0,0 is
  |
  |  - Can jump, can have only occasional updates, but shouldn't drift over time
  |  - Typically done with amcl, gmapping, laser_scan_matcher
  |
odom - Origin = Where robot initialised
  |
  |  - Can drift over time, but should be frequent updates
  |  - Typically done direct from odom node or via robot_pose_ekf etc
  |
base_footprint
  |
  |  - With no large roll or pitch changes can be a static tf
  |
base_link
  /\
  | | - static tf 
  | |
imu laser

Q2) Is my understanding above reasonably correct? I am particularly unsure about what normally generates the map to odom and odom to base_footprint (or base link) transforms?

Q3) Do the irregular map -> odom transformation typically override drift / issues in the the frequent odom -> base_footprint transformation? I can't get my head around how that works, how the two different transforms link join together - as just applying them both would create a mess effectively doubling the distance / rotation moved :)

What I have got working quite nicely ... (more)