opentrons/opentrons

Software for writing protocols and running them on the Opentrons Flex and Opentrons OT-2

Opentrons Platform

Overview

Opentrons makes robots for biologists.

Our mission is to provide the scientific community with a common platform to easily share protocols and reproduce each other's work. Our robots automate experiments that would otherwise be done by hand, allowing our users to spend more time pursuing answers to the 21st century’s most important questions, and less time pipetting.

This repository contains the source code for the Opentrons API and OT App. We'd love for you to to explore, hack, and build upon them!

Opentrons API

The Opentrons API is a simple framework designed to make writing automated biology lab protocols easy.

We've designed it in a way we hope is accessible to anyone with basic computer and wetlab skills. As a bench scientist, you should be able to code your automated protocols in a way that reads like a lab notebook.

pipette.aspirate(location=trough['A1'], volume=30)
pipette.dispense(location=well_plate['A1'], volume=30)

This example tells the Opentrons OT-2 to pipette 30 µL of liquid from a trough to well plate. Learn more here:

• Documentation
• Source code

Opentrons App

Easily upload a protocol, calibrate positions, and run your experiment from your computer.

• Download Here
• Documentation
• Source code

Opentrons Protocol Designer

Easily create a protocol to run on your robot with this graphical tool.

• Access Here
• Documentation
• Source code

Contributing

We love contributors! Here is the best way to work with us:

1. Filing a bug report. We will fix these as quickly as we can, and appreciate your help uncovering bugs in our code.

2. Submit a pull request with any new features you've added to a branch of the API or App. We will reach out to talk with you about integration testing and launching it into our product!

For more information and development setup instructions, please read the contributing guide.

Enjoy!

opentrons's Issues

Pipette.dispense(0) will dispense entire contents of pipette

The expected action for a call to .dispense(0) would be for the pipette to dispense 0uL, not for it to dispense all remaining volume inside the pipette.

add new tube rack custom container

add in tube-rack-80well to main containers file
new container.json.zip

Error in Documentation

"See the 15-50ml tuberack for an example of this functionality being used"

The link for the 15-50ml tuberack no longer is valid.

Container not showing up for calibration

If the only function applied to a container in the entire protocol is move_to, it will not show up for calibrations in the app.

dispense command going to blowout?

Dispense command goes to blowout to pickup, not bottom - is that supposed to happen? It ends up picking up more volume than it should

add custom containers back in

add custom containers from 1.2 back into app

Question regarding fail safes

Hi,

This is a very interesting project. I have been studying the API code and trying to figure out how everything fits together - I am getting there :-)

My question is does the machine wait for one action to be completed as "expected" before proceeding with the next? I saw this:

    def wait_for_arrival(self, tolerance=0.1):

        arrived = False

        coords = self.get_position()

        while not arrived:

            coords = self.get_position()

            diff = {}

            for axis in coords.get('target', {}):

                diff[axis] = coords['current'][axis] - coords['target'][axis]



            dist = pow(diff['x'], 2) + pow(diff['y'], 2) + pow(diff['z'], 2)

            dist_head = math.sqrt(dist)



            """

            smoothie not guaranteed to be EXACTLY where it's target is

            but seems to be about +-0.05 mm from the target coordinate

            the robot's physical resolution is found with:

            1mm / config_steps_per_mm

            """

            if dist_head < tolerance:

                if abs(diff['a']) < tolerance and abs(diff['b']) < tolerance:

                    arrived = True

            else:

                arrived = False

        return arrived

which is a case in point. If arrived = False then obviously the while loop would be exited. I could not see where this method was called at the higher level, what happens if the position never can be reached? I presume there is a "try a number of times" parameter and the main "instruction queue" is exited and the user notified?

Many Thanks.
Regards,
Tom

Does not jog on connect

Should move up and down on connect (like 1.2) to signal that it has connected

APP window size

The app reacts weirdly to trying to adjust the window size. Also, if it loads and thinks it is a hood robot, the window is smaller, and doesn't readjust when you connect to an OT-One PRO (maybe it should default to a larger size in case it is a PRO?

In `pick_up_tip()` add support for multi-channel pipette tip tracking

Packaged Windows electron app does not have server exe

When the app is packaged for windows, the opentrons-server-exe is not included in final binary.

Pick-Up-Tip within UI collides with containers after 2nd click

Seems like the calibrated position is not being considered during a robot arc movement only some of the time when being called from the flask server.

Steps to reproduce:

1. Load protocol with trough-12row and tiprack-200uL
2. Calibrate trough-12row so that it's is higher up on the Z axis than the tiprack-200uL
3. Press Move-To button on the trough-12row (should well well, moving up to safe height)
4. Press Pick-Up-Tip button on the tiprack-200uL (should well well, moving up to safe height)
5. Press Move-To button on the trough-12row (should well well, moving up to safe height)
6. Press Pick-Up-Tip button on the tiprack-200uL, and the pipette should move DOWNWARDS, colliding with the trough

Squirrel not found on windows when app is started in dev mode

The app logs Update error: can not find Squirrel when the app is started in development mode with make dev on Windows 10

This needs investigation..

drop tip movement extra

Drop tip moves to the rack, drops tip, and then sends the plunger all the way and then back down to the bottom position - it doesn't need to move back to bottom at the end

add trash container with depth

Need to add special trash container that has depth - using "point" doesn't allow you to eject liquid in that location

Mix function

currently pipette.mix(num_mixes) only takes one argument, the number of mixes desired, and defaults to the tip's full volume.

It would be good to add an optional second argument, the volume of liquid to mix:

pipette.mix(vol, num_mixes)

App 2.5.0 won't install on Linux

Attempting to install the OT App using the ubuntu software installer fails. When you click on the install button, nothing happens.

When I attempt to install the app dpkg I get an error:

Left/Center labels needed on container list

Need to add Left/Center or B/A labels to container lists for clarification, also pipette type?

eg B: p200 S, and Center: p10 or A: p10 M

pulling wrong pipette name into app

both p200s are being called p10 in the description

docs for the virtual smoothie

need to let people know they can prototype with the virtual smoothie, dont need to plug into the robot to get started

Pause/Play Button

The protocol ran, was paused and then cancelled. When the protocol ran again, the pause button did not reset and became the play button.

On OS X 10.11 app seems to require git installed in production builds

The app shows a modal dialog saying The "git" commands requires the command line developer tools... on OS X 10.11. Seems like this is caused by some part of Python API calling opentrons.__version__ which, in turn, when _version.py is missing is trying to call git

Make labware names not case sensitive

Can we make labware names not case sensitive? Eg: 96-pcr-flat can be used in addition to 96-PCR-flat?

app save max volume needs reaction

need a "max volume saved" type reaction to pop up (like other saved buttons)

add vial rack custom container

add container to containers.json

App fails to start on windows due to winston module not being located

On windows, App fails during installation due to winston logger not finding module ./transports/file. This seems like a packaging issue.

Front-end tests mysteriously log assertion errors without any failures

Since repo refactor The front end tests seem have a strange error message that doesn't result in a test failure.

https://travis-ci.org/OpenTrons/opentrons/jobs/250194221#L3745

Doc tests fail randomly

Running the make docs fails randomly on my local machine (and I suspect CI as well). Sometimes doc tests fail and hit 20-23 failures which involve virtual smoothie hitting a limit switch.

Rerunning protocol freezes

After running the protocol, when clicking to rerun the protocol, the app freezes. It will home the robot very slowly then stop. The app says in progress at 0% but nothing is happening. When clicked to cancel job, the bar stays the same (attached is the mentioned bar). While frozen, I am unable to re-upload the protocol and am forced to close out of the window to open a new one.

Closing electron app does not turn off backend server

When I close my app I see the following log,

backend process successfully shutdown
info: Electron App window closed, quitting App
Not rewriting GET /exit because the client did not send an HTTP accept header.

And my backend server process is still running although the Electron process was terminated.

Robot.home(enqueue=True)

Command causes app to freeze and disconnect machine, does not actually home within protocol

`containers.load` should check if slot is valid

When user tries to use a slot that's out of range it gives an unhelpful error. Should be improved. It does not link to the correct line in the python file.

Delay does not work

Delay command does not actually delay

[windows] Cannot connect robot after connect/disconnect sequence

[Reported by @HenryOpentrons ]

On Windows, when you connect to a robot, disconnect, and reconnect again the following error occurs:

The error goes away when you restart the app.

wait_for_arrival error

I am getting this error when I do a move_to on a smoothie (mine is not connected to a robot but that shouldn't make a difference for jogging). I also get it occasionally on the Virtual Smoothie when doing a move_to.

Traceback (most recent call last): File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1820, in wsgi_app response = self.make_response(self.handle_exception(e)) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask_cors/extension.py", line 161, in wrapped_function return cors_after_request(app.make_response(f(*args, **kwargs))) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1403, in handle_exception reraise(exc_type, exc_value, tb) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/_compat.py", line 33, in reraise raise value File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1817, in wsgi_app response = self.full_dispatch_request() File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1477, in full_dispatch_request rv = self.handle_user_exception(e) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask_cors/extension.py", line 161, in wrapped_function return cors_after_request(app.make_response(f(*args, **kwargs))) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1381, in handle_user_exception reraise(exc_type, exc_value, tb) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/_compat.py", line 33, in reraise raise value File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1475, in full_dispatch_request rv = self.dispatch_request() File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/flask/app.py", line 1461, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/Users/levkravinsky/Desktop/ot/v2/server/main.py", line 258, in jog result = robot.move_head(mode="relative", **coords) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/opentrons_sdk/robot/robot.py", line 209, in move_head self._driver.move_head(*args, **kwargs) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/opentrons_sdk/drivers/motor.py", line 315, in move_head return self.consume_move_commands(args_list, increment) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/opentrons_sdk/drivers/motor.py", line 330, in consume_move_commands self.wait_for_arrival(tolerance) File "/Users/levkravinsky/Desktop/ot/v2/server/env/lib/python3.4/site-packages/opentrons_sdk/drivers/motor.py", line 354, in wait_for_arrival dist = pow(diff['x'], 2) + pow(diff['y'], 2) + pow(diff['z'], 2) KeyError: 'x'

Move to action is incorrect

When calibrating a container and selecting "move to container", the robot moves the z axis DOWN first, and then moves XY. This does not take into account other containers on the deck. All move to buttons should move UP the Z axis first, then make XY movements.

Can't cancel a protocol when it is simulating

When I press cancel when a protocol run is started and it is at the simulating stage, it does not work.

Cancelling job freezes app

When I press cancel on a running protocol job the app freezes. I can't close the run screen, press run job, press pause, etc. I have to restart the app.

Container File Errors don't show error

When the container file has an issue, it just stops the app from opening. It should pop up an error that says there's a problem with the containers file instead of just being unresponsive.

Z height bug

calibrating the XYZ of tiprack using old app, pipette goes to correct XY, but not far enough down the Z

Webpack build warning: (Emitted value instead of an instance of Error) ⚠️ JSON Loader

A possible false-positive Warning currently in CI:

WARNING in ./~/vue-resource/~/got/package.json
(Emitted value instead of an instance of Error) ⚠️  JSON Loader

It seems you're using webpack >= v2.0.0, which includes native support for JSON.
Please remove this loader from webpack.config.js as it isn't needed anymore and
is deprecated. See the v1.0.0 -> v2.0.0 migration guide for more information
(https://webpack.js.org/guides/migrating/#json-loader-is-not-required-anymore)

 @ ./~/vue-resource/~/got/index.js 22:12-32
 @ ./~/vue-resource/dist/vue-resource.es2015.js
 @ ./ui/main.js
 @ multi ./ui/main.js webpack-dev-server/client?http://localhost:8090/

Thread to watch: webpack-contrib/json-loader#57

Robot can't go over certain containers

... cant go high enough in the Z to go over the 15-50 ml it is just traveling lower when the protocol is running (i.e. if I manually move it it will go over the 15 mL tubes)

aspirate command inactive

Aspirate command does nothing

15ml / 50ml tube rack container file fix

from OT user Magnus: 'I think there is a bug in the containers file for the tube-rack-15_50mL for positions C1 and C2. The x position should be 64, not 54. (Compare to the 32 of the B1 and B2)'

When running cancel, RuntimeException raised by API is displayed to user

When the user presses the cancel protocol, a RuntimeException raised by the API is show as a toast message

Noticeable delay takes place before protocol is run.

There is a pause of around ~10 sec (for dinosaur protocol). This pause is caused by the fact that the protocol is simulating (running against virtual smoothie to determine final command sequence) before running on robot. The final command sequence is needed in order to determine progress bar length.

Firmware Compatibility

Update firmware to most recent compatible version

Run log command is displayed after command is executed by the robot, not before

App run log commands are displayed after the command is executed by the robot. This delay occurs because of the refactor that removed protocol commands being closures. When protocol commands where closures, the app displayed the description property of the command and then executed the closure. What happens instead now is that the commands are displayed after the robot has made the movements.

Pick up tip does not work

Pick up tip calls wait_for_arrival on the instrument motor, which does not have the wait_for_arrival method any more. This makes picking up a tip impossible - the reason we did not detect this in tests is that the pick_up_tip method is not tested.

Containers disappear from step list

Both Nusrat & I experienced containers disappearing at random from the calibration step list when one is using the app. The disappearing sometimes takes place after running a protocol and interacting with the 'move to' buttons on a container.

I have not found a reliable way to replicate this bug.