fix(hardware): minimum movement displacement of 0.05mm

[fsinapi]

Overview

Protocols kept failing with collision errors on release 0.13.0, and logs would show a noticeable drift in the encoder position over time. Release 0.9.0 seemed completely fine with the same exact protocols.

One difference between those releases has been changing the units for acceleration to use µm instead of mm. When we move the pipette down to aspirate/dispense/pick up a tip/etc, there are usually small displacements in the X and Y axes that are due to precision loss on the stepper motor accumulator. With the new, more precise acceleration, we seem to actually commanding some gantry movements that are affecting the error buildup over time.

By clamping the minimum displacement to 0.05mm, this error seems gone. A protocol that transfers liquid from a reservoir into an entire 96-well plate used to fail after the first column, and can now finish successfully.

Test Plan

Ran a failing protocol and now it works. There used to be noticeable encoder drift if you disabled stall detection, now the pipettes look fine.

Changelog

• Added a minimum displacement of 0.05mm in each axis of movement

Review requests

Any reason to make the minimum displacement smaller? Do we ever actually need to move 0.05mm?

Risk assessment

[codecov]

Codecov Report

Merging #13052 (12cabd0) into internal-release_0.13.0 (37609fd) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@                     Coverage Diff                     @@
##           internal-release_0.13.0   #13052      +/-   ##
===========================================================
+ Coverage                    72.81%   72.82%   +0.01%     
===========================================================
  Files                         2364     2364              
  Lines                        64474    64526      +52     
  Branches                      7191     7191              
===========================================================
+ Hits                         46948    46994      +46     
- Misses                       15847    15853       +6     
  Partials                      1679     1679              

Flag	Coverage Δ
g-code-testing	96.44% <ø> (ø)
hardware	59.21% <100.00%> (+0.21%)	⬆️
notify-server	89.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...are/hardware_control/motion_planning/move_utils.py	91.70% <100.00%> (+0.16%)	⬆️

... and 5 files with indirect coverage changes

[sfoster1]

This looks good to me because we update our position cache back based on the actual outcomes of moves, but we should be generally very careful that nothing caches the positions it commands before this call.