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-Workspace/

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 robotposeekf 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 is laserscanmatcher, after lots of odom issues that was a woohoo moment :) With a static odom to basefootprint transformation, with laserscan_matcher using key frames it is quite jerky, but at least it stays aligned! This is my all combined bringup.launch.

<!-- Localisaion and Navigation -->
<group if="$(arg move_base)">
  <!-- Map Server -->
  <!-- Publishes /map and /map_metadata with frame_id map -->
  <node name="map_server" pkg="map_server" type="map_server" args="$(find edukit_bot)/map/loft_map_2.yaml"/>

  <!-- Laser Scan Matcher -->
  <!-- Subscribes to /scan (sensor_msgs/LaserScan), /imu/data (sensor_msgs/IMU) and /odom -->
  <!-- Publishes TF for odom to base_footprint frames and /pose2D (geometry_msgs/Pose2D)-->
-  <node pkg="laser_scan_matcher" type="laser_scan_matcher_node" name="laser_scan_matcher_node" output="screen">
    <param name="fixed_frame" value="odom"/>
    <param name="base_frame" value="base_footprint"/>

    <param name="use_imu" value = "true" />
    <param name="use_odom" value = "true" />
    <param name="use_vel" value = "false" />

<!--Can use every frame not just key frames to remove jerk, but will get drift -->
<!--    <param name="kf_dist_linear" value = "0" /> -->
<!--    <param name="kf_dist_angular" value = "0" /> -->

    <param name="publish_tf" value = "true" />
  </node>

  <node pkg ="tf" type="static_transform_publisher" name="static_odom_to_base_footprint" args="0.0 0.0 0.0 0.0 0.0 0.0 /odom /base_footprint 50"/>

Q4) What I dont understand here is that with a fixed frame of odom, and a base frame of basefootprint, I thought is should generate transformations from odom to basefootprint, but it doesnt, the transformation is from map to odom as show by rosrun tf view_frames.

Q5) In this setup mapping doesn't seem to work as I thought it should - sometimes it shows the map my map server is publishing, sometimes it shows a map that seems to be generated live - I am not sure what from or why?

What my map should look like (ie the saved map file):

How my map actually looks:

Q6) Finally, I seem to have got myself a bit lost in the overall ROS software architecture I should be using. I think my goal is to show my robot (in the right place) on a map as i move it by a joystick, but also be able to navigate from a start point to a Nav Goal. I can add movebase to do the navigation and pretty sure I can get that running ok (already have had it running with AMCL launch and my very poor odom), Q6a) but what should I use for frequent odom to base transformation (I was thinking I could use laserscan_matcher agains with a zero kf_dist setting?) Q6b) how do I tie my position together with my map served by map server - I think AMCL should do this, so do I need AMCL for odom to base tf, but using what inputs? my poor odom?

Sorry for the long post, but I wanted to try and be helpful to others by including my understanding of transformation frames and cover the journey I have been on.

Thanks very much Kevin