The Overbot suffers from terrible sensor myopia. We can't see more than about 10-12 meters ahead. It's not that the LIDAR can't see further than that; we can usually get range information out to 20-25 meters. But small amounts of vibration in the vehicle, especially in the pitch axis, result in large range errors, as the scan hits the ground in the wrong place. This causes the detection of false obstacles.
Our original approach, as described in Note #8, works by comparing successive scan lines, rather than trying to extract absolute elevation from range information. Because the LIDAR is on shock mounts, vibration above some frequency (supposedly 20Hz, but we need to check this) is filtered out. The LIDAR scans at 75Hz. This provides some noise immunity, enough to get us to where we are today. But it's not good enough.
Here's a new approach - using the LIDAR range data itself to correct for vibration.
For the first version of this, we have the following assumptions:
Given those assumptions, a typical scan, profiling the ground from an angle above the ground, looks like this.
As the scanner moves in the pitch axis, the range line moves relative to the vehicle. We know the approximate pitch of the scanner from an encoder in the tilt head. But because the scanner is on shock mounts and the vehicle frame has some flexibility, a few degrees of error are introduced into the pitch measurement as the vehicle bounces around. It is that error which we need to remove.
Our best source of information about where the scanner is pointed is the scanner range data itself. We could mount an extra tilt sensor on the scanner frame, but that introduces additional problems.
For each incoming scan line
Scan line filtering
We need to extract the C, L and Ls values from logged scanner data and see what they look like. We have a Python script which attempts to load scanner data into Blender to build a 3D model, but it's not working correctly for data taken from the moving vehicle. This needs to be fixed and augmented with the correction algorithms shown here, so that we can debug the algorithms off-line.
Scan line reordering
The scan lines from the previous step may need to be reordered for proper map updating. As the scanner pitches up and down and move forward, some sequential scan line pairs may be unsuitable for pairwise updating.
Previously, elevation values for individual cells weren't very accurate, and we were basing our driving decisions strictly on difference information between successive scan line pairs. With this new adjustment system, we should have good elevation information.
Geometry of tilt correction
General formula for perimeter: K=ab sin(c)/2
perimeter = h + L + B = h*L*sin(θ)/2
B = h*L*sin(θ)/2 - L - h
Bs = h*Ls*sin(θ + α)/2 - Ls - h
Bc = L*Ls*sin(α)/2 - Ls - L
Bs = B + Bc
h*Ls*sin(θ + α)/2 - Ls - h = h*L*sin(θ)/2 - L - h + L*Ls*sin(α)/2 - Ls - L
h*Ls*sin(θ + α)/2 = h*L*sin(θ)/2 + L*Ls*sin(α)/2- 2*L
solving for α, we get
Vehicle elevation estimation
We now need smooth elevation information for the vehicle. GPS elevation alone is not enough. We must use smoothed pitch and dead reckoning to compute a smoothed elevation value. Absolute elevation is not critical, but within the scale of the map (100m), relative elevation must be good to within 1% of the distance moved. (i.e. 20 m of movement should produce less than 20cm of elevation error.)