---
# System prepended metadata

title: IWBDA2020 Lab Automation Pitch Notes

---

# IWBDA2020 Lab Automation Pitch Notes

[TOC]

## People

- Alexis Casas
- Andrey Shur
- Eric Young
- Hia Ming
- Jeremy Cahill
- Zoltan Tuza

> Note: There were two others present for the duration of the initial call on 2020-08-05 who didn't interact. I've omitted [update: one of] their names here pending a signal of interest.
> [name=Jeremy Cahill 2020-08-05 11:51 ET] [color=red]

## List of Pitches

1. [IWBDA2020 Lab Automation 1.1: Testify](https://hackmd.io/@bdathlon-lab-automation/H1K3ouOWD)
2. [IWBDA2020 Lab Automation 1.2: :cherries: CERISE :cherries:](https://hackmd.io/@bdathlon-lab-automation/HyVXVu_ZD)
3. [Project Area 4 - Automated colony picker](https://hackmd.io/6G_4F5_uS0CZGpjKo6G-ug?view)
4. [Project Area 5 - Everything OpenTrons](#Project-Area-5---Everything-OpenTrons)


## General Notes

### 2020-08-04 Unifying Project Concepts with OpenTrons - How?

> [Project Area 5 - Everything OpenTrons](#Project-Area-5---Everything-OpenTrons) aims to unify the threads of each proposal into a more cohesive and tractable whole. However, each pitch has not yet been fully reframed in terms of an OpenTrons-centric mesh. Should they all be done this way?
> hmm.
> Higher Abstractions + OpenTrons → write a wrapper for OT-2 API :/
> Automated colony picker + OpenTrons → the 2019 igem project?
> Integration of existing equipment + OpenTrons → just OpenTrons with behaviors in a repository
> I'm seeing the point of trying to shoehorn OpenTrons into this, but not how to make these specific pitches revolve around it.
> I suppose we could treat OpenTrons as something like a proving platform for innovations, in the sense that we're pegging expectations at x for future hardware based on the ability of OpenTrons to do x.
> [name=Jeremy Cahill] [color=red]

### Ad Hoc Meeting Room

- This room is reusable for whatever
- https://meet.jit.si/BDAthlonLabAutomation

### Pitch Deliverables

1. By 2020-08-05: 2 minute elevator pitch — single slide
2. 1 epic card with impact, purpose
3. N epic cards detailing different technical components of the project, N>3
4. N detailed cards detailing tasks, the more the better

### Heilmeier Catechism

- What are you trying to do? Articulate your objectives using absolutely no jargon.
- How is it done today, and what are the limits of current practice?
- What is new in your approach and why do you think it will be successful?
- Who cares? If you are successful, what difference will it make?
- What are the risks?
- How much will it cost?
- How long will it take?
- What are the mid-term and final “exams” to check for success?

### 2020-08-05 12:00 ET HackMD Team Created

- Admin blah
   - Jeremy Cahill created a HackMD team so that these notes aren't treated as his personal files.
   - He transferred the notes to the team.
   - Teams have basic administrative controls.
   - Team notes are owned by the Team.
   - There is a bulk note export button available to Team members with permissions to view Team notes. It produces a zip of markdown files.
   - ==TODO: Jeremy needs to fix the email address of the team acc.==
- Links
   - Overview page for a logged-in member of the Team:
      - https://hackmd.io/team/bdathlon-lab-automation
   - Public URL of team's published notes:
      - https://hackmd.io/@bdathlon-lab-automation
   - Account used to create team:
         - @bdathlonlabautomation 

## Project Area 1 - Higher Abstractions

**Owner/Lead**

~~Alexis Casas or Alexis Casas/Jeremy Cahill if divide-and-conquer (TBD pending discussion)~~

Alexis Casas/Jeremy Cahill

- 1.1 owner for 2020-08-05
   - responsible for making sure it's done
   - Jeremy
- 1.2 owner for 2020-08-05
   - responsible for making sure it's done
   - Alexis

**Concept**

- Sub-Area 1.1 - Specification
   - Protocol flexibility - higher level specification that can be translated to work on multiple lab automation tools and enable scaling
- Sub-Area 1.2 - Instruction Set Optimization
   - cherry-picking lists are "universal" and can be interpreted by most platforms and can be generated both manually and algorithmically 
   - Reducing instruction set from a cherry pick list

**Slides**

- [Slides - IWBDA2020 Lab Automation - Problem Area 1.1](https://hackmd.io/@bdathlon-lab-automation/H1K3ouOWD)
- [Slides - IWBDA2020 Lab Automation - Problem Area 1.2](https://hackmd.io/@bdathlon-lab-automation/HyVXVu_ZD)

<details><summary>2020-08-04 deprecated slide notes</summary>

::: info

Scratch this - I was formulating 1.1 and 1.2 as just one slide so it's irrelevant now — Jeremy.

- Definitely include
   - Drivers
   - Vocabulary derived from lab instructions
   - Attacking from above/below
- Nice to have
   - Worked / applied section
   - Analogy to compiler optimization
- Probably won't have time
   - OpenTrons specifics? no time to work out how we can cram a generic abstract instruction set into opentrons API
:::

</details>

**Links**

- https://www.transcriptic.com
- https://autoprotocol.org
- https://synthace.com
- LIMS like https://www.aquarium.bio
- echo cherry pick https://labcyte.com
- OT-2 https://www.opentrons.com

**Chat**

> 11:10-11:30 Round-Trip: An Automated Pipeline for Experimental Design, Execution, and Analysis
Daniel Bryce, Robert P. Goldman, Matthew Dehaven, Jacob Beal, Tramy Nguyen, Nicholas Walczak, Mark Weston, George Zheng, Josh Nowak,
> [name=Zoltan Tuza 2020-08-04 13:57] [color=purple]

> my thoughts on that: build a controlled vocabulary, try to get the instruction set parsimonious and MECE, test with rewrite rules on automata modelled as formal languages, semantic unification and "compiler optimization"
> [name=Jeremy Cahill 2020-08-04 14:02] [color=red]

> BBN - Intent Parser is relevant. It adds intensional semantics / NLU to protocols, combining word processor ML (semi-structured) with SBOL queries (structured).
> BBN is also discussing shared vocabulary in the Knowledge Engineering poster session. This drives at the controlled vocabulary point.
> [name=Jeremy Cahill 2020-08-04 16:24] [color=red]

### 2020-08-04 17:00 Meet

<details>

- Meeting location
   - https://meet.jit.si/BDAthlonLabAutomation
- 1.1 - Specification
   - put the word driver in the abstract
   - Define lexicon of atomical operations
   - Protocol Drivers - Drivers are programs that read the aforementioned high level protocol language/specification and translates it to the instructions for the platforms.
   - Write the protocol once, execute it many times on different platforms.
   - Slide emphasizes attack from high-level and low-level (above/below)
      - driver end of the problem is important
      - protocol level of the problem is abstruse; important long-term but not if prematurely optimizing yourself out of ever getting adopted
      - people don't read or write RFCs
      - question remains: are we targeting a human-readable controlled vocab standing in for an "instruction set" for the v1?
      - http://tadirah.dariah.eu/vocab/index.php
      - Part of speech tagging on ==some representative corpus of texts with protocols== to extract verbs, which will constitute our basis for determining actions to be done in a lab
      - PoS tagging is a "core task" in NLP that's considered essentially solved in terms of accuracy so this will be easy compared to other text analysis problems
- 1.2 - Instruction Set Optimization
   - Alexis:
      - Group instructions that minimize/maximaze certain functions (ex: distribute same reagent in one go, save time, save tips..)
      - Impliment the instructions on an open platform that is accessible by most labs: the Opentrons OT-2 platform.
   - Jeremy:
      - we need to write a dynamic programming algorithm so that the dumbass bot can learn to amortize its costs over state transitions when it knows it has n-many wells to fill rather than being an amnesiac at each state and repeating the same vignette, e.g. water-reagentx-reagenty rather than pre-filling all wells with water first.
      - dependency parsing also comes to mind. treat each target of the bot as a state etc. i'll fill this in later

</details>

### 2020-08-04 20:00 Graphical Abstract Roundup

- Jeremy
   - Let's not go overboard with soft cel-shaded biorender-looking nonsense.
   - We just need to not be constructing elaborate state diagrams in TikZ and Overleaf.

<details><summary>The Histopathology Laboratory -- good concept</summary>

- https://app.biorender.com/community/gallery/s-5ed8ead98a0c3400b40e04e7-the-histopathology-laboratory?q=lab
- ![](https://prod-illustrations.s3.amazonaws.com/shared/templates/5ed8ead8ad974300ac493df6/thumbnail/V2_1591274200305_9515df9d-cb97-4924-b376-c481ac29577f_dpi_96.png)

</details>

<details><summary>Mask manufacturing pipeline graphic</summary>

- https://app.biorender.com/community/gallery/s-5ed9e0e47de68700abc7f70e-simplification-of-the-3d-printed-face-mask-process-for-sars-?q=lab
- ![](https://prod-illustrations.s3.amazonaws.com/shared/templates/5ed9e0e3112f3400b371e40c/thumbnail/V2_1591337187504_f04cbfe8-77d4-4713-a67c-f54621076cfa_dpi_96.png)

</details>

### 2020-08-04 20:40 Return to formulating 1.1

<details>

- (Jeremy notes)
- This is Wolfram-style "natural language computing" in its essence
- That is, borrowing notions like "driver" belies the incompatibility of the core conceit with a biolab-asm product
- We are essentially positioning the specification of machine operations from the perspective of machine operators, framed in terms of
   - research activities,
   - research objects,
   - research techniques, and
   - incidental mechanical facts of those research objects responsible for implementing instruction sets.
- This amounts to specifying a controlled vocabulary plus a set of operators, forming a grammar.
- We need to demonstrate this attains sufficiency to operate as an intermediate language between prose protocols and machine code.
- This is likely possible in our case because turing completeness is ==thimkig lomg amd hard about this claim before fimishimg it==
   - brain fried for now

</details>

## Project Area 2 - Better Machines

**Meta**

Dupe of Project 4

**Owner/Lead**

Andrey Shur

**Concept**

New lab equipment suited for integrated automation

**Chat**

> great! My idea is this: small benchtop/fits in incubator colony picking robot, designed to pick colonies into liquid cultures as soon as they are visible on plates, to shorten the time from transformation to miniprep. Let me know if anyone is interested in working on this with me
> [name=Andrey Shur 2020-08-04 13:33] [color=blue]


## Project Area 3 - Integration of existing equipment

**Owner/Lead**

Eric Young

**Concept**

Existing molecular biology equipment not suited for lab automation - how can we integrate PCR, qPCR, plate readers to the bare minimum of liquid handling automation

**Chat**

> i.e.  better device drivers
> [name=Eric Young 2020-08-04 14:07] [color=orange]

> re: one machine to rule them all, i would also just add that there's a general trend in hardware toward desktopification of tools that were previously larger, e.g. mini PCRs. looking at the lab as a collection of lots of handhelds and a small number of powerhouse appliances is going to become more fruitful over time i think
> [name=Jeremy Cahill 2020-08-04 14:19] [color=red]

## Project Area 4 - Automated colony picker

**Owner/Lead**

Andrey Shur

**Concept**
![](https://i.imgur.com/euGaipa.png)
![](https://i.imgur.com/9Dv42cG.png)


Automated colony picker that watches a plate and picks as soon as ready

**Links**

- https://2019.igem.org/Team:Marburg/Colony_Picking

**Chat**

> Desired Specifications
> 1. Open Source
> 2. incubator to hold at 37 C or relevant T
> 3. automated colony identification by camera
> 4. picking into pre-prepared liquid culture rack
> 5. liquid culture rack shaking
> 6. reusable auto-sterilizing metal tip to avoid plastic waste
> 7. multiple growth dish capacity
> 8. plate flipping and lid removal to allow optimal growth
> 9. simple user interface and sample tracking (what is in well A1? etc)
> [name=Andrey Shur 2020-08-04 14:45] [color=blue]

## Project Area 5 - Synthetic Biology Middleware for Opentrons OT-2

**Owner/Lead**

Zoltan Tuza

**Concept**

"[A] **Middleware** makes it easier for software developers to implement communication and input/output, so they can focus on the specific purpose of their application" --Wikipedia

* Opentrons OT-2 is an **affordable** liquid handler, although less precise as industrial leading liquid handlers.
* There's a **low-level API** available for Opentrons 
* Build a synthetic biology specific software layer that can **translate** higher-level commands to Opentrons commands. 
(Ideally: the generated **picklist** can be exported and executed on other liquid handles)
* Higher-level tools, e.g. **SBOL3** CombinatorialDerivation can interface this. 
* Opentrons just retired its v1.0 API **invalidating** all v1.0 protocols, a middleware would hide the low-level API.

### DNA Assembly
```python=
golden_gate = GoldenGateAssembly(regeant_a=a,reagent_b=b)

dna_a=Location(source_plate.A1)
dna_b=Location(source_plate.B2)

my_assemlby = makeDNAAssemlby(first_part=dna_a,
                              second_part=dna_b,
                              method=golden_gate)

my_assembly.location
>> plate_C.E2
```
### DNA purification 
```python=
liquid_culture = LiquidCulture(location=source_plate.C2,
                               volume=20)

sample1 = DNAPurification(source=liquid_culture)
sample1.location
>> plate_D.B6
```
### Error checks
```python=
run_checks()
>> Error: Not enough 10uL tips to run the protocol

run_checks()
>> Error: Not enough plates to generate intermediate states!
>> available wells: 200, required: 250
```

* Technology stack: python, FastAPI to call it as an API

**Chat**

all in voice on 2020-08-04

## Project Area 6 - Waste Minimization

**Owner/Lead**

Eric Young?

**Concept**

Goes through protocol and optimizes for time and material usage (i.e. pipetting water and disposing pipette tips)

**Chat**

all in voice on 2020-08-04