Starting new thread since this isn’t directly odometry, but was spurred by that thread.
I built a little jig to make sure my GoPiGo3 was square to the near wall of my “roboland”. Ran the lidar and wrote a little program to capture 100 scan messages and then write the distances to a CSV file so I could look at it easily.
Things I learned:
The lidar captures 720 values per spin, but inconsistently. On any given pass there are empty values - it’s non-random in the sense that certain angles seem to be missing values for several spins, and then the next half angle will be missing them. Here’s a slice of my spreadsheet to illustrate - top row is the position of values in the list, the rest are distances (in M)
First surprise was that my zero point was straight back rather than straight ahead. Although as I thought about it that’s not so different from some examples I’ve seen with, say, a 180 scan where 0 was far left and 180 far right, so dead ahead was 90. I need to look around the different drivers and config files to see how the navigation stack is supposed to figure that out.
I took the average of all the non-zero distances at each point so I could generate a graph (converting the distance and angle into cartesian coordinates). First time I tried it my graph was reversed from what it should be. Then I remember positive spin in ROS is counter-clockwise, so maybe that has something to do with it, even though the lidar itself spins clockwise. I reversed the direction of the sequence of degrees and was actually able to generate a decent map from the points in excel.
Distances to the center of the lidar checked out with a tape measure. So I was happy enough about that. Still need to verify repeatability and check the distances with different initial poses.