Hardware design

Although our first prototype robot operated along a single axis (S4 Movie), our final implementation of the robot had three axes of motion for x-y-z positioning and a fourth linear actuator for syringe plunger actuation (Fig 1A, S1 and S2 Movies). This final design is described here (and in the Supplementary Materials) in detail.

Our positioning mechanism consists of an x-z gantry to position the syringe in two axes of motion and a y-axis motion stage to position samples in the remaining axis of motion (Fig 1A). We wished to design the robot to enable repeated disassembly and reassembly, with all parts joined by either snap-fit tab-hole joints or press-fit holes (Fig 2A). Our design objectives were to prioritize structural rigidity and stability, followed by modularity, and low parts count. The robot’s mechanical structure consists almost entirely of laser-cut acrylic pieces and hand-cut Delrin rods, with the exception of a few small 3D printed ABS plastic parts; all raw materials are available from McMaster-Carr and thus accessible to hobbyists and non-specialists (Supplementary Materials).

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 2. Close up of various parts of the robot.

A) The laser-cut parts. i. Examples of the laser cutting patterns for parts found on the sheets (see Supplemental Information for all laser-cut sheets). ii. The laser-cut parts have tabs which can be snapped into rectangular holes. iii. The tabs can be seen partially inserted into holes. The relative sizes of the tabs and holes need to be adjusted for each laser cutter to be able to fit well. B) i. The motors are held in place with the laser-cut parts and wired to the Arduino board. ii. The Arduino board is mounted onto the left side of the robot and controls the motors. C) i. The consumables: Standard 1 cm cuvette, a syringe with a disposable tip, and a 96-well plate. ii. The standard plasticware can be slotted into place.

https://doi.org/10.1371/journal.pone.0275688.g002

For position control of the robot’s four linear actuators, we use low-cost brushed DC motors with rack-and-pinion mechanisms and position sensors (Fig 2B(i)). For position sensing, we use linear potentiometers when the motion range requirements were sufficiently small, and we use magnetic angle sensors when we required large motion ranges (Supplementary Materials). Position control of the robot’s linear actuators is implemented on an Arduino microcontroller board (Fig 2B(ii)), which is connected to the motors and position sensors via an Adafruit motor shield. With the exception of the magnetic angle sensors, all components are available from hobbyist-oriented vendors (Adafruit, Sparkfun, Pololu, and Jameco). The magnetic angle sensors require a few parts from a business-oriented vendor (Digikey), integrated into two custom printed circuit boards.

In total, the robot has 4 degrees of motion (Fig 1A, Supplementary Movies). The y-axis motor shifts the entire stage towards or away from the user and has an arbitrarily extensible range of motion. This allows for the modular design of the stage, which enables users to add various platforms for their experimental needs. The x-axis motor moves the pipette holder (Fig 2C) left or right, while the z-axis motor raises and lowers the pipette away from or towards the sample, respectively. This allows the pipette tip to be positioned into and out of well plates, cuvettes, petri dishes, and other types of containers used in experimental protocols. Finally, the pipettor axis motor raises and lowers the syringe pump thus regulating the intake and dispensing of the liquid (S1 Movie). The x-axis motor has a 14 cm range of motion while both the z-axis motor and the pipettor axis motor have a 5.2 cm range of motion. Thus, the syringe can intake up to approximately 0.9 mL of liquid. The x-y stage as well as the pipette tip can travel 5 mm with greater than 10% accuracy (Fig 3A and 3B). The robot can also dispense liquid down to 50 μL with greater than 20% accuracy (Fig 3C and 3D).

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 3. The LHR is accurate down to 5 mm of motion with a standard deviation of 0.5 mm and can dispense as little as 50 μL with a standard deviation of 10 μL.

A) Motor accuracy for x-y motion. The x-axis is the programmed distance for the motor to move, and the y-axis is the actual distance moved by the motor. N = 20, 46, 62, 80, 103, 204, and 359 for the programmed move distances of 100 mm, 50 mm, 10 mm, 5 mm, 2 mm, 1 mm, and 0.5 mm, respectively. B) Motor accuracy for z motion. The x-axis is the programmed distance for the motor to move, and the y-axis is the actual distance moved by the motor. N = 20, 20, 40, 100, and 194 for programmed move distances of 50 mm, 10 mm, 5 mm, 1 mm, and 0.5 mm, respectively. C) Motor accuracy for liquid dispensing volume. The x-axis is the programmed volume for the robot to dispense, and the y-axis is the actual volume of liquid dispensed. N = 71, 50, and 43 for programmed dispense volumes of 0.1 mL, 0.05 mL, and 0.02 mL, respectively. D) Image of droplet sizes over multiple dispense commands of various droplet volumes at various locations along a line. At every other cm mark, the robot dispenses (from left to right) 0.1 mL, 50 μL, 25 μL, 10 μL, and 5 μL. Note that the 5 μL droplet appears to be the same size or perhaps even larger than the 10 μL droplet, indicating that the robot is not accurate down to this volume. For A)-C), the plots contain the box plot summarizing the data to the left of each set of individual data points. For the box plots, the whiskers denote the range between the outlier boundaries (± 1.5 times the interquartile range), the box boundaries denote the 25^th and 75^th percentile, and the central square data point in the box plot denotes the mean.

https://doi.org/10.1371/journal.pone.0275688.g003

The stage has several modules which were designed to fit standard wet lab plasticware (Figs 1A and 2C, Supplementary Materials). For example, one module holds 16 standard cuvettes while another holds a 96-well plate. The plasticware fits with <1 mm tolerance to ensure minimal shifting during stage movement, which would affect the calibration. The travel distance of the z-axis motor is large enough to insert and completely remove the pipette tip from the standard plasticware so that liquid can be taken in and dispensed directly into the container or well. This platform can handle glass or plasticware with the height of the container up to 5 cm.

Hardware reproducibility

We wished to determine if an easily assembled, reproducible, and modifiable DIY robot could be built. To that end, once the design was finalized, we built five replicas of the prototype robot. The replication process was straightforward, with a typical assembly and building time of about 1 day for each additional robot for research personnel already familiar with the design. From this process, we learned that one of the key challenges to replicating the robot was that the motor encoders needed to be tuned for each individual robot. The five LHRs resulting from this process were used for educational user studies, the first of which we published previously [21].

To assess ease of future replication and determine how difficult it would be for a non-specialist to assemble the LHR, we gave the parts list and design plans to another researcher who had not been involved in the original design. This researcher ordered parts and recreated the robot over the course of about 3 working days (i.e., 24 hours). While most of the assembly proceeded as expected the researcher encountered two challenges: (1) Different vendors have slightly different plastic sheet thicknesses, and laser cutters can have variable cutting parameters (e.g., laser kerf), which can both lead to sub-optimal fittings. Thus, parameters such as hole and tab sizes should be tested and adjusted on a subset of parts before cutting the full set. Even with the additional tuning, laser cutting still results in some variation in tab/hole sizes, and additional gluing was necessary to maintain the structure of the robot. (2) The motor encoders need to be tuned for each robot which takes extra time and skill. We originally designed these encoders ourselves in the DIY spirit of building from the ground up and using inexpensive parts, but this came at the cost of having increased development time and greater challenges of reproduction. Future iterations of the LHR design should therefore instead use motors that already have built-in rotary encoders. Overall, we conclude that the reproduction of our robot design requires some skill and DIY experience. This is in contrast–unsurprisingly–to the previously published Lego liquid handling robots that could be assembled by advanced elementary school students [3].

Control software

The robot control software (Fig 1B) has two independent modules, one running on the Arduino and one on a control computer. The Arduino’s software implements a position feedback control loop (PID controller) on each axis and exposes a serial communication interface to the control computer. The control computer software handles user interaction and sends higher-level movement commands to the Arduino.

For user interactions, we developed a traditional programming interface (a Python API) as well as a visual block-based programming interface (Figs 1B, 4, 5 and 6A) to enable programming by novices, similar to what was implemented in OpenLH [8]. The block-based interface was implemented in Snap4Arduino. Upon startup of the interface, a calibration routine is necessary to align the sensors. The base application includes commands for moving the stage forward and backward, moving the pipette tip left, right, up, and down, and intaking and dispensing liquid. These commands can be executed either by clicking on the program block with a mouse or by an associated key press. For example, pressing the left arrow will move the pipette tip left by an amount set by the user (the default is 0.4 cm). Users can also specify the distance of motion for each of the motion commands. The program also includes preprogrammed locations to which the pipette tip can be moved, corresponding with the initial layout of 16 cuvettes and a 96-well plate (Figs 1B, 4 and 6A).

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 4. The programming interface.

Red outline: Users can choose from basic programming constructs such as for-loops and move commands and drag them to the right to construct their own program. Green outline: The native set of commands for the LHR includes moving the pipette tip to specific locations on the stage, raising and lowering the pipette tip, and intaking and dispensing liquid. Blue outline: The beginning of the serial dilution command. Yellow outlines: Different markers indicate the location and state of the syringe. The red arrow on the left and the scale indicate how much liquid is contained in the syringe. The syringe image on the right indicates the current height of the syringe tip, and the blue dot indicates where on the stage the syringe is.

https://doi.org/10.1371/journal.pone.0275688.g004

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 5. Examples of protocols featuring loops and iterative liquid handling operations.

A) Serial dilution program for cuvettes. B) Serial dilution program for four rows of a 96-well plate. C) Zoom in of the first for-loop of the serial dilution program for cuvettes, which encapsulates the second for-loop. Note that the variables are marked in orange, the robot commands are marked in blue, and the for-loop visually encapsulates the entirety of its body. D) Third for-loop which encapsulates the fourth for-loop of the serial dilution program for cuvettes.

https://doi.org/10.1371/journal.pone.0275688.g005

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 6. The robot was programmed to perform a serial dilution along a row of cuvettes, and to dispense 20 uL droplets of fluorescently-labeled E. coli onto an agar plate.

A) The program for serial dilution was implemented through the Snap4Arduino interface. Inset is a top-down still image of the pipetting robot. B) The resulting cuvettes from the serial dilution. Each dilution decreased the dye concentration by about a factor of 3. The cuvette on the left was used to initialize the serial dilution. C) The fluorescent bacterial colonies after 1 hour of incubation.

https://doi.org/10.1371/journal.pone.0275688.g006

In this interface, the tip location in the x-y plane is marked by a blue dot while the tip position in the z-axis is marked by the syringe picture to the right of the 96-well-plate diagram (Figs 1B, 4 and 6A). The amount of liquid contained within the syringe is marked by the pointer to the left of the 96-well plate diagram (Figs 1B, 4 and 6A, S1 and S3 Movies).

The Snap4Arduino interface allows users to drag and drop commands to create programs of their own (Figs 1B, 4 and 5, S3 Movie). Loops are indicated with visual brackets, which makes it easier for novice programmers to quickly understand their code. Variables and motion commands are represented in blocks of different colors.

Applications: Liquid handling and biology experiments

Liquid intake and dispensing are handled by the 1 mL syringe, which can be purchased from Amazon (Plastic Syringe, Luer Slip, 1 mL, Amazon B00BQLJFYE). The syringe takes plastic pipette tips (Dispensing Needle, Plastic Tapered Pink 20 ga 0.024id x 1.25”, Amazon B001QQ9QH0). Both can be snapped into place and replaced as needed (Fig 2C). Our initial platform includes space for up to 16 standard cuvettes and standard 96-well plates (Fig 1A, Supplementary Information). For our experiments, we use Standard Polystyrene Cuvettes (3.5 mL, Amazon B00T5A64PQ) and Nest Scientific Polystyrene 96 Well Cell Culture Plate (Amazon B001QVE7C).

For the serial dilution demonstrations, food coloring was used (AmeriColor Beginner Soft Gel Paste Food Color 4 Pack Kit, Amazon B002L3RV9C) (Fig 6B, S1, S2 and S4 Movies). We also created agar plates and seeded fluorescent E. coli cell lines presenting mRuby and sfGFP (Null control strains from [22]) (Fig 6C).

Demonstration 1: Serial dilution

We automated a routine for serial dilution in Snap4Arduino (Figs 5A and 6A, S1 Movie). The routine assumes that cuvette A8 is filled with the food coloring and the cuvettes in the second row (B1-B7) are filled with water. The routine dispenses an equal amount of water (1.6 mL) amongst the remainder of the cuvettes in row A. Then the pipette intakes 0.9 mL of the food coloring from cuvette A8 and dispenses it into A7. It mixes the liquid by passing it in and out of the syringe three times, then intakes 0.9 mL of the current cuvette, dispenses into the next cuvette in the row, and repeats this process for each subsequent cuvette. The result is a noticeable dye gradient (Fig 6B, S1 Movie).

This program demonstrates the possibility of using loops and establishing routines within the Snap4Arduino interface. The visual programming environment makes it relatively easy to understand the organization of the tasks and the loops (Figs 5 and 6A).

Demonstration 2: Cell seeding on an agar plate

Fluorescent strains of E. coli (mRuby or sfGFP-tagged) were inoculated overnight for 10 hours. A fresh sterilized syringe and tip were used to withdraw 0.6 mL of the culture. The LHR then dispensed 0.02 mL droplets onto an agar plate in the configuration shown Fig 6D. To avoid contamination, a fresh pipette was used to dispense each strain of E. coli. To minimize pipette changes, all the mRuby-labeled E. coli droplets were dispensed before the sfGFP-labeled E. coli droplets.

Teacher interest assessment, co-design, educational deployment with middle-school students

In order to assess interest, needs, and potential applications in educational settings, we invited teachers to visit our lab and provide feedback on the single-axis robot prototype (see S1 Movie). The purpose of this qualitative study was to provide feedback from relevant stakeholders and potential future users that could then be used to improve the final hardware and software design as detailed in this paper. Teachers were recruited by advertising via email to participants of a summer internship program for teachers at our institution. Anyone who was interested was then invited to meet. This study was performed according to Stanford IRB-18344.

We met with a total of 6 high school-level STEM teachers, all from the San Francisco Bay Area (specifically the Peninsula and the East Bay). One of the teachers taught biology and engineering; one taught only biology; two taught chemistry; one taught conceptual physics and computer science; and one taught computer science. Teachers met with us individually or in pairs. There were always at least two researchers present. Each meeting lasted approximately 1 hour. The meetings were structured as open interviews, where we demonstrated different functionalities of a single-axis prototype robot, and where we asked the teachers multiple questions regarding their teaching needs and what other ideas or comments they might have. We took notes on the teachers’ responses, either by typing directly into a computer or by writing on paper. Data was then qualitatively analyzed jointly by two researchers to identify points raised by multiple teachers, as well as to identify more unique perspectives. Overall, we believe that these teachers provided their honest opinion as we did not see any incentive for them to do otherwise, and we did not identify and conflicts of interest. We summarize the findings as follows:

Some examples of specific experiment activities and use cases that the teachers proposed include: titration experiments; growing organisms (e.g., algae, sea anemones); running experiments overnight or outside of classroom hours; quantifying the accuracy of pipette volume dispensing vs. humans with micropipettes (i.e., having students compare their pipetting technique to the robot); teaching students about measurements and tools in general; performing photosynthesis experiments comparing light/no-light conditions; color mixing; and testing for the presence of specific macromolecules (e.g., lipids). In general, activities proposed by the teachers tended to be ones that they already did in their classrooms, and they considered how a robot could make these experiments more feasible or more convenient to execute. Teachers with more curricular flexibility had greater interest in deploying the robot in their classes in comparison to teachers with less curricular flexibility.

Deploying the LHR into a classroom curriculum appealed to the teachers for the following reasons: (1) the ability to teach and foster programming at different levels based on student proficiency. The high-level interface and block-based programming environment (e.g., commands like “go to the well in row B of column 1 and lower the pipette by 0.25 cm”, or “intake 0.05 mL”) were appealing to teachers for whom programming was not the primary emphasis of the class, as it is simple enough for students without much programming experience. In contrast, the computer science teachers stated that their students could work with lower-level commands as well as the Python programming interface. (2) Engineering courses could have students design modifications to the robot, introducing fabrication technologies such as 3D printing, providing an entryway into the design process. Furthermore, teachers generally appreciated the “open” design of the robot, which keeps its structure and mechanisms exposed for students to see–thereby likely leading to a deeper understanding on how robots work. (3) Teachers saw significant potential for multidisciplinary teaching aligned with NGSS, as the robot could tie programming, engineering, and biology concepts together. It was specifically noted that for engineering students this type of LHR could serve as an introduction to life science applications.

In terms of limitations, the main concerns that teachers had were related to cost and robot precision: Even if students worked in teams with a robot, a single class would need about 10–15 LHRs, which likely represents a significant investment for schools. To justify this type of a purchase, the robots would have to be suitable for many different teachers and subject areas; and arranging courses to allow for that might take significant coordination. Teachers also commented on the limitations on positioning and volume dispensing accuracy, but they felt that such limitations could teach students about taking accuracy/reliability of tools in general into consideration; overall these limitations were not seen as a significant challenge for deployment.

Teachers had several suggestions for the robot design. While the biology/chemistry teachers wanted a ready-made robot citing a lack of time in the science class curricula for the LHR assembly process, the CS/engineering teachers believed that student assembly of the robot could be beneficial. Teachers also noted that for long-term or overnight experiments, it would be necessary to have the robot run on a Raspberry Pi (or similar) system, so that the robot could be run independently of the school computers, which may have time-specific shutdowns. Teachers also felt that ready-made lesson plans could make the LHR and other similar systems to be easier to adopt. These plans would ideally fit naturally into their curricula. All teachers wanted a robot with 3 positioning axes.

We also deployed the final LHR design inside of an educational setting and performed a use-case study with 6^th grade students; the results were published previously [21]. In summary, it was found that over a five-session curriculum these students were able to program the LHR to conduct a science experiment while also engaging into computational thinking (CT). Students identified increased precision in experimental procedures, time-efficiency, and easier debugging as the key advantages of this educational approach. This study provides a proof-of-concept curriculum on how such LHRs can bring CT and robotics to science classrooms, especially for chemistry and biology.