Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(api): return location sequences from commands (#17435)
By adding all the locations of a labware used in a command that establishes or changes the position of a labware, we can free the client from having to accumulate all previous such commands to display a single such command. These locations are shown as location sequences. These are lists of heterogenous unions keyed by `kind`. The kinds mostly correspond to the kinds of locations that the engine already uses - they're different types because they have the `kind` key so you can tell them apart when serialized instead of just via python isinstance checks. All these sequences end in either an `OnCutoutFixtureLocation` which lists a cutout id and possible cutout fixtures; or a `NotOnDeckLocation` that specifies `OFF_DECK` or system. Different robots have different kinds of sequences; on the OT-2, modules are loaded on deck slots, and so a labware on a module would have `[OnModule, OnAddressableArea, OnCutoutFixture]` while on the Flex, modules are loaded on cutout fixtures and a labware on a module would have `[OnAdressableArea, OnModule, OnCutoutFixture]` (having the `OnModule` there lets us have the module ID; it is not technically necessary). There are some command implementations that are straightforward, and some that are charmingly quirky. - `loadLabware`, `reloadLabware`, `loadLid` all just return the location of the newly added labware. Simple, clean, wondrous - `loadLidStack` creates a lid stack object and returns its location, and also creates N lid objects and returns all of _their_ locations, which is done in its own array that is guaranteed to have the same ordering as all the lid ids so we can keep the types of the locations consistent across commands and also avoid altering already-existing result elements - `moveLabware` needs an origin and a destination location, so it has them. In fact, one destination location isn't enough. When we move labware to a trash location, we need to encode both (1) which trash location it was and (2) that it is a trash location. After the command, the position of the labware is `OFF_DECK` (because it went into the trash), after all. So we get both `immediateDestinationLocationSequence` (which in this scenario would be the addressable area of the trash) and `eventualDestinationLocationSequence` (which in this scenario would be off deck). If the two are the same, then the two are the same - the stacker `store` and `retrieve` commands have info that isn't really actually useful right now, but it will be soon, so let's carve out some space for them. For now the labware just bounces back and forth between the module/off deck and the module/stacker staging slot. ## to come out of draft - [x] ts bindings - [x] stacker store and retrieve - ~[ ] add "what is the old and new state of the locations named in the command" to these values~ not going to do that ^ in this pr just so we can get it merged --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: sfoster1 <[email protected]>
- Loading branch information