feat(api, shared-data): make speed & distance pickUpTipConfigurations values keyed by tip count

[sanni-t]

Closes RSS-443

Overview

This PR looks big but it actually has only 2 real changes-
speed and distance properties of a pipette's pickUpTipConfigurations are now changed to speedByTipCount and distanceByTipCount. These values are now dictionaries keyed by number of tips being used for tip pickup.

Test Plan

• Run a protocol or go through a maintenance run procedure that moves the pipette around and make sure that the pipettes move the same as before.
• Test the above on both Flex and the OT-2.

Changelog

• updated pipette schema for the new speedByTipCount & distanceByTipCount properties
• updated ot2 & ot3 pipette handlers to use the updated properties
• updated the pipette definitions

Review requests

• this was a bit too easy! Probably a testament to hardware control architecture, but maybe I've also overlooked something?
• would appreciate a second set of eyes going through the updated definitions to make sure I've only updated the properties' shapes and kept the speed and distance values the same as before

Risk assessment

High if I messed up pipette definition updates.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (63a20fc) 67.77% compared to head (cec63f9) 67.77%.
Report is 6 commits behind head on edge.

Additional details and impacted files

@@           Coverage Diff           @@
##             edge   #14458   +/-   ##
=======================================
  Coverage   67.77%   67.77%           
=======================================
  Files        2518     2518           
  Lines       71968    71970    +2     
  Branches     9244     9244           
=======================================
+ Hits        48774    48778    +4     
  Misses      20990    20990           
+ Partials     2204     2202    -2     

Flag	Coverage Δ
app	64.58% <ø> (+0.01%)	⬆️
g-code-testing	92.43% <ø> (ø)
hardware-testing	∅ <ø> (∅)
protocol-designer	37.93% <ø> (ø)
shared-data	75.24% <88.88%> (-0.02%)	⬇️
step-generation	86.90% <ø> (ø)

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

Files	Coverage Δ
...n/opentrons_shared_data/pipette/model_constants.py	100.00% <ø> (ø)
...rons_shared_data/pipette/mutable_configurations.py	86.70% <100.00%> (-0.40%)	⬇️
...pentrons_shared_data/pipette/pipette_definition.py	94.21% <100.00%> (ø)
...s_shared_data/pipette/scripts/build_json_script.py	0.00% <0.00%> (ø)

... and 2 files with indirect coverage changes

[sanni-t]

Totally forgot about the schema v1 build scripts. Updating now

[sfoster1]

Code looks good, and I see you noticed the fairly cursed way we do mutable configurations, awesome.

It feels a little silly and error-prone to have three different maps with the same key rather than one map to objects with three members though. Can you either invert that (so it's like configByTipCount: { "1": { "current": 0.1, "distance": 10, "speed": 20}, }) or add some verification to the python modals, or even just to the tests, to make sure that nobody forgets an entry in one of the three?

[sanni-t]

It feels a little silly and error-prone to have three different maps with the same key rather than one map to objects with three members though. Can you either invert that (so it's like configByTipCount: { "1": { "current": 0.1, "distance": 10, "speed": 20}, }) or add some verification to the python modals, or even just to the tests, to make sure that nobody forgets an entry in one of the three?

That is certainly a good idea. Will try the first method as it seems the most robust.

[SyntaxColoring]

Notwithstanding the changes discussed above, I tested this on a Flex and didn't notice anything out of the ordinary. I used the drop-tip wizard and whatever 96-channel protocol happened to already be on the robot.

[sanni-t]

That is certainly a good idea. Will try the first method as it seems the most robust.

@sfoster1 On second thought, I'll add tests right now to validate the entries. Will refactor the shape of the properties in a follow-up. I'll fix the failing tests and merge this to make hardware testing a bit easier.

[sanni-t]

Notwithstanding the changes discussed above, I tested this on a Flex and didn't notice anything out of the ordinary. I used the drop-tip wizard and whatever 96-channel protocol happened to already be on the robot.

Awesome! Thanks @SyntaxColoring !

[sanni-t]

Tested on OT-2 and verified that:

• pickup speed & distance works just like before
• speed & distance pipette settings via app apply correctly