HomeScope : an open microscope with an XY stage

Transcription

1 2018 年 1 月 5 日 1 HomeScope : an open microscope with an XY stage A hacker guide for the DIY biologist 2 The HomeScope is a homemade RaspiCam-based microscope system capable of recording video and/or image capture (time-lapse microscopy) while robotically scanning an area of 70 x 70 mm 2. We thinkered with the Cambridge s OpenLabTools 3 microscope and the open source drawing 4 micro-robot PlotterBot and came up with the HomeScope; a DIY biologist solution for developing robotic spatial-scanning capabilities for the home laboratory. The robotic OpenStage (XY axes) is capable of scanning space by using two, very low cost and widely available, micro servos. This servos have a range of angles that goes from 0 to 180 and which translates to 70 mm of linear displacement as shown in the figure. A Nema17 stepper motor is used for focusing (Z axis) as with the OpenLabTools design as well as with the 5 Open FIESTA microscope. To keep our design modular we use two Arduino controllers. One to process XY movements and the other to independently control Z movements. This approach allows for the parallel evolution of the OpenStage software and hardware independently of those needed to control the focus of the optical system common to other open microscopy projects elsewhere. Although, this has the drawback of needing two Arduinos, it keeps the code and hardware development efforts modular. It also force us to think on a more network-based design for the overall electronic ecosystem making up the HomeScope. This way, the OpenStage development is independent of the development of other hardware components such as focusing, optical, illumination, and frame system. For detailed information about these subsystems we refer the reader to consult the Open FIESTA microscope step-by-step by Alfredo L Homme, Janneke Noorlag & Juan Keymer for Tecno X 2018 & DIY-BIO@FCB-UC /28

2 6 7 guide and installation manual. Indeed for this version of HomeScope (v.1.0), we use the same illumination and optics as in the Open FIESTA microscope. The frame is made of OpenBeam beams instead of V-slot beams and it is bigger than previous constructions (OpenLabToos and Open FIESTA variants) to accommodate a larger stage hosting the XY plotter robot. Another advantage of this modular approach is that the code which is developed for the Arduino controlling the Z-movements (OpenScope) can be also used to control focus on these alternative designs where no XY stage is present. A major innovation of the HomeScope is it s OpenStage derived from a design from the PlotterBot. Materials We used OpenBeam for beams and brackets. The main frame of the microscope can be decomposed into three different horizontal components that are stack together in a vertical fashion by four 300mm beams holding a Top frame and a Bottom frame. These two frames generate a Z axis where displacement of the Stage up and down the axis. This is controlled by a linear translation mechanism which moves along a couple of smooth rods, acting as linear rails. The Stage is pushed/pulled by a lead screw and a flexible shaft coupler and powered by a stepper motor. OpenBeam 8 Beams 300 mm 270 mm 210 mm 150mm 135 mm Vertical 4x Frame Top 5x 2x 1x Horizontal Bottom 5x 4x Stage 5x TOTAL 10x 4x 5x 6x 1x This one is the only openbeam of non-standard length. It can be made from cutting a 150mm one. 2/28

3 To hold all the beams together we use Openbeam brackets on each of the three horizontal components: Top frame, Bottom frame, and Stage. The Stage, controls XY movement via two micro servos and a 3D printed gear mechanism from the PlotterBot. Brackets Nema-17 bracket T-bracket L-bracket Shaft clamps Top Frame 8x 8x 4x Bottom Frame 1x 12x 6x 4x Stage 1x 2x 8x TOTAL 2x 22x 22x 8x Beside beams and brackets from OpenBeam, we need lots of nuts & bolts as well as some custom made components for mechanical support which are not provided by OpenBeam. Other mechanical components Linear platform bearings: 2x (Stage) Shaft coupler: 1x Adaptor for lead screw to nema bracket on stage (custom made) Acrylic for (laser cutted) stage board (custom made) Rods Smooth rod: 2x Motors Nema steps: 1x (Z axis) Lead screw + nut: 1x Micro Servos 9g: 2x (X,Y axes) 3D printed pieces 9 PlotterBot pieces : 6x (use the OLD version of the Plotterbot with 2 instead of 3 servos) Cambridge OpenLabTools optical clamp: 1x Cambridge OpenLabTools RaspiCAM holder: 1x Optical tube (instead of the Edmund Optics metal tubes) Optical components Edmund C-mount-DIN optical system (tubes in case of not printing them) Comar Optics Focal lens Objectives from CNScopes (4x,10x) 9 Ideally the plotter-like design, as well as the stage base evolve into a more scope oriented design. 3/28

4 Electronic components Arduino UNO: 2x Easy Driver: 1x Raspberry Pi 3B: 1x RaspiCAM: 1x Logical convertor: 3x Joystick: 1x i2c 16x2 LCD: 1x Breadboards: 3x + 3x Cobbler Pi PIN cable: 1x Push button: 2x resistors (for LEDs and for pull down the push buttons) Illumination components White LED: 1x Potentiometer: 1x Illumination system For this version of the HomeScope we implement the most basic illumination set up possible. We use a single white LED which is placed under the sample and where a single potentiometer is used to regulate light intensity directly from hardware. The source of power connected to the potentiometer comes from the 10 Raspberry Pi 3B s only PWM capable pin which we use to control voltage. The average voltage from this pin ranges from 0 to 3.3 Volts. Controlling this pin from software allows HomeScope to automatize light conditions on 11 the sample. Note we chose focal lens with a coating filtering light. Thus we can protect the RaspiCAM from UV and blue LED damage. Once the camera is protected by the optical system, 12 the HomeScope is ready for fluorescent microscopy. HomeScope s Aluminium Frame The HomeScope main frame is made up assembling the OpenBeam beams from the list described in the section above. As indicated, there are three critical mechanical components which are horizontal. One corresponds to the Stage itself which is where the XY translation system is mounted and where the sample is located. This Stage, is itself located inside a volume defined by aligning Top frame and Bottom frame components and joining them 10 Pulse Width Modulation (PWM) See FluoPi: 4/28

5 vertically with four 270 mm beams at the corners; thus making up the main frame of the microscope. Stage The Stage corresponds to the platform where the XY CNC PlotterBot micro robot is placed and modified (hacked) a bit so it can hold a sample in a petri dish instead of its originally intended pencil. The Stage is itself a platform that can move up and down along a linear translation axis (Z axis). This movement dimension is what makes possible for the HomeScope to focus the Raspberry Pi camera on the sample held by the PlotterBot. The Stage component is made of five 210mm beams which hold to each other by two T-brackets and eight L-brackets. Four of these L-brackets hold four of the 210 mm beams into a rectangle shaped area. Four other L-brackets attached to the sides of the Stage are used to hold the linear platforms which travel along the smooth rods on each side in order to implement Z axis translation. A Nema 17 stepper motor bracket (with no motor attached) is used here as a hack to interface the stage with the linear translation axis (lead screw). This bracket is aligned (but rotated 90 degrees) with another Nema 17 bracket located on the Bottom frame component which is the bracket that actually holds the stepper motor powering Z axis translation. Top frame The Top frame is made of five 300mm beams in addition to two 150mm beams used to hold two pairs of shaft clamps (i.e. four shaft clamps) holding up the linear rails (smooth rods). These rails are used by a lead screw, located at the center, to guide the Stage up and down the Z-axis. A custom length 125mm beam (cutted of a 150 mm piece) is used to hold the 3D printed optical clamp from the OpenLabTools microscope which is used to set the optical tube in place. Beams are joined together using eight T-brackets on the inside joints and eight L-brackets on the outer corners. Notice that each of the elements (on the Top frame) that need to be alight with elements on the Bottom frame (left pair clamp, right pair of clamps, and optical system) all can 5/28

6 be locally adjusted in the XY directions. These flexibility is needed for an easy assembly of the hole structure when aligning Top frame with Bottom frame and Stage. Bottom frame The Bottom frame is similar to the Top frame in that it is also made of five 300mm beams. The Bottom frame, however uses an extra pair of 150mm beams which are used to hold the lower end of the smooth rods with a pair of shaft clamp pairs. These extra beams are used to attach a Nema 17 motor bracket (this one indeed host a motor). This bracket, which is located on the Bottom frame, needs to align with the Nema 17 bracket located on of the Stage. These extra beams also need four more T-brackets for their attachment to the group on top of the eight it needs just like its Top counterpart. The union to the vertical beams aligning Top and Bottom frames is done with six L-brackets. Notice that, as before, all attachment points that are needed to align (left pair clamp, right pair of clamps, center lead screw, and Nema bracket); can all move locally in XY directions. Such design consideration is critical for achieving a good frame architecture. Electronic system The HomeScope is made of a collection of electronic systems that need to communicate with one another. The figure shows the connectivity pattern among different boards, computer, and other electronic components of the microscope. Actuation (movement in the X,Y,Z axes) is powered by two Arduino controllers listening to a Raspberry Pi computer controlling a Raspberry Pi camera (RaspiCAM) which is 6/28

7 attached to an optical system (optical tubes, focal lens, objective). Each of these Arduinos is a two-state machine that can switch from a listening to an actuating state depending on sensory input. To refer to these two Arduinos on this guide, we label them: Arduino XY and Arduino Z. The Raspberry Pi also controls the LED that is used to illuminate the sample via its PWM pin. When in the actuating state, these Arduinos actuate XY and Z movements respectively. Arduino XY displays XY coordinates on an LCD as well as listening to the Joystick and the Raspberry wishes; Arduino Z listens to a couple of push buttons as well the Z wishes of the Raspberry. Movements in XY are implemented using two micro servos while movement in Z is done with a stepper motor. The Arduinos also communicate their state ( listening or actuating ) over PIN 12 through a one-bit representation. Currently, the Raspberry Pi ignores such signals (dotted lines in the figure) but these are needed to implement further functionality such as autofocus and spatial tracking. Note that there are multiple pin notations in the Raspberry Pi community; here we use the WiringPi notation. We port the dualism of having two Arduinos into the Raspberry Pi code design by splitting software functionality into two different applications ( OpenScope and OpenStage ) as explained further on this guide. We first describe the Arduino side of the system, as they define the space of movements and thus create an actuation space for the Raspberry Pi. Thus, the Arduinos define the messaging system that applications running on the Raspberry Pi can use to control the HomeScope. Different pieces of code ( *.ino ) run on each of the Arduinos and each one of these talks to one of the applications running on the Raspberry Pi: Arduino XY code listens to OpenStage and Arduino Z code listens to OpenScope. In the next Sections of this guide, we describe each of these Arduino codes in detail. After that, we describe the C codes ( *.c ) implementing the GUIs (OpenScope and OpenStage) communicating with each one of the Arduinos. These Apps are also responsible of controlling illumination (LED) and image/video capture (RaspiCAM) respectively. Arduino XY Sensory inputs : (i) Raspberry message and (ii) Joystick position. i.- Raspberry message For communication with a Raspberry Pi we use four-bit messages carried over 4 input pins. For each axis of motion we need two bits and therefore we need two digital pins. To move the X axis up (to higher angle values) or down (to lower angle values), we use PIN 2 and PIN 3. On these digital input pins, we 13 can send in the following possible messages: a (0,0) message corresponds to stay-put while moving up and moving down messages corresponds to (1,0) and (0,1) respectively. Similarly for the Y axis we use PIN 4 and PIN 5 to transmite similar messanges: stay put (0,0), moving up (1,0) and moving down (0,1). 13 Meaning (LOW, LOW). Note on the Arduino side, a HIGH corresponds to 5V while a HIGH on the Pi corresponds to 3.3 Volts. For this reason, Voltage conversion is needed on all the message lines. 7/28

8 ii.- Joystick position To read the Joystick, we use two analog input pins, PIN 0 (A0 ) and PIN 1 (A1); these pins can have values ranging from 0 to At the center position, for each degree of freedom (XY) the stick is resting vertically at 90 degrees and the Joystick analog value is around 512. We use a threshold value of 64 to detect a meaningful deflection and trigger actuation. Actuation outputs : (i) XY stage movement (servo control), (ii) signal back to the Raspberry Pi (one bit), and (iii) LCD display of angle coordinates (using the i2c protocol). i.- XY stage movement For actuation, the Arduino controls XY movement via two servos. For this, we use the Servo library and define two PWM capable pins as servo output pins. We use PIN 9 and PIN 10 for X and Y servos respectively. ii.- Signal back to Raspberry In order for the Raspberry Pi to know if the Arduino is listening (to Joystick or Raspberry 4-bit messages) or bussy actuating a servo movement, we mirror the Arduino two-state machine state of execution to PIN 12 ( signal_pin ) to inform the Raspberry Pi the Arduino is busy moving servos. iii.- LCD display of angle coordinates For user info, the Arduino uses the i2c protocol (2 pins) to control a 16x2 LCD where it displays the angle coordinates of the servos. For i2c communication with the LCD, we use PIN A4 for SDA and PIN A5 for SCL as well as the Wire and LiquidCrystal_I2C libraries. The code in the file Arduino_XY.ino controls the XY OpenStage via two servo motors while listening to a Joystick and a Raspberry Pi 4-bit message acting as descriptor of XY movement wishes. This Arduino also displays servo motor coordinates (from 0 to 180 degrees) in a 16x2 LCD controlled via i2c. The Arduino_XY.ino code shown here coordinates sensing input and actuating output as a two-state automata. The code, listens for a message (either from the Joystick or the Raspberry) and then upon its detection actuates stage movement. We first include the Servo, Wire, and LiquidCrystal_I2C libraries, #include < Servo.h > #include < Wire.h > #include < LiquidCrystal_I2C.h > Then we define the input pin variables needed, to listen to the Raspberry s movement wishes (PINS 2,3,4,5), and to write servo angles to the motors over PINS 9 and 10. We also set up the signal_pin (PIN 12) needed so the Arduino can send out a signal back to the Raspberry Pi communicating that actuation is taken place. // declare pins for digital input from the RASPBERRY PI int x_up_pin = 2 ; int x_down_pin = 3 ; int y_up_pin = 4 ; 8/28

9 int y_down_pin = 5 ; // declare pins for servo output int servo_x_pin = 9 ; int servo_y_pin = 10 ; // declare flag pin to send digital output to the RASPBERRY PI int signal_pin = 12 ; We create two servo objects using the Servo.h library // declare 2 servos to control the degrees of freedom of the XY Stage Servo servo_x ; Servo servo_y ; We also create a LCD controller lcd using the LiquidCrystal_I2C.h library, //declare an i2c LCD to display the servo coordinated LiquidCrystal_I2C lcd ( 0x27, 16, 2 ) ; Then we define variables servo_x_angle and servo_y_angle to keep track of coordinates in the microscope s viewing area. As servos have a range between 0 and 180, we set our starting position (at start up) in the middle of their range. // set up the default position of the servos: in the middle int servo_x_angle = 90 ; int servo_y_angle = 90 ; We initialize the two-state machine not actuating but listening. // actuation flag: not moving int actuating = false ; int moving_x = 0 ; int moving_y = 0 ; Finally, we set up some variables to later define analog pin identities JoyStick_X and JoyStick_Y needed to read the Joystick state and also set up the Joystick sensitivity by setting up a threshold value where to consider a movement has to be actuated in the direction the Joystick has bend. // Joystick sensitivity int threshold = 64 ; // Analog input pins for Joystick XY values int JoyStick_X = 0 ; // pin number for x int JoyStick_Y = 1 ; // pin number for y After setting all these definitions in the global declarations section of the code we proceed with coding the setup and the loop functions. First, in the setup function we define the signal_pin needed to communicate to the Raspberry that the Arduino two-state machine is in the listening or actuating state; then we set the mode of signal_pin (PIN 12) as an output pin and write LOW state to it. Next we proceed to attach the servo controllers servo_x and servo_x to the corresponding pins servo_x_pin and servo_x_pin (PIN 9 and PIN 10), 9/28

10 initialize the LCD library (and print OpenStage to the display), center the stage (writing the default angle to the servos), and setting up the 4 bit digital input pins (2,3,4,5) to code for the Raspberry Pi stage-movement wishes. Finally, a small delay is introduced and the function exits leaving the Arduino ready to execute the loop function ad infinitum (provided with power). void setup () // communicate to RASPBERRY if actuating a stage move or listening pinmode ( signal_pin, OUTPUT ) ; // to send 1 bit message to pi digitalwrite ( signal_pin, LOW ) ; // not actuating // prepare the servos Serial. begin ( 9600 ) ; // 9600 bps servo_x. attach ( servo_x_pin ) ; servo_y. attach ( servo_y_pin ) ; // prepare the LCD lcd. begin () ; // Turn on the blacklight and print a message. lcd. backlight () ; lcd. setcursor ( 0, 0 ) ; lcd. print ( " OpenStage " ) ; // position at the center of the scanning area (x,y)=(90,90) servo_x. write ( servo_x_angle ) ; servo_y. write ( servo_y_angle ) ; // RASPBERRY communication pins (4 bits) pinmode ( x_up_pin, INPUT ) ; // GUI button x.step-up pinmode ( x_down_pin, INPUT ) ; // GUI button x.step-down pinmode ( y_up_pin, INPUT ) ; // GUI button y.step-up pinmode ( y_down_pin, INPUT ) ; // GUI button y.step-down delay ( 50 ) ; After initiating the LCD, we write the servos with the default XY position; that is located at the center of the viewing area at the coordinate value = (90, 90). Finally we set up four input pins to hear for the Raspberry Pi messages. To finish up, we need to specify the loop function. The loop executes for as long as power is provided to the Arduino. These function is divided into two parts: (a) listens to inputs and (b) executes output. While listening to inputs, the loop looks for up or down movement instructions for each degree of freedom (X and Y). These instructions might come from the Joystick or the four-bit Raspberry Pi input message. First, we evaluate if there is a request to actuate a x.down movement, then x.up, y.down, y.up respectively. On each of these four if statements actuation can be trigger by either the Joystick bending beyond the threshold towards one particular direction or by the Raspberry Pi four bit input message. If any of the conditions above is met, the loop decides a stage move must be executed in a particular degree of freedom (X or Y) and in a particular direction (up or down). After the input is detected, a new movement angle is communicated to the corresponding servo and the Raspberry Pi is notified that a movement has occurred via the signal bit PIN 12. Thus, loop consist of four if statements; two per degree of freedom checking for movement messages. The other four nested if statements present take care of the exceptions needed to deal with the endpoints of the range (servos only go from 0 to 180 degrees). 10/28

11 void loop () // X movement (signal detection) // x.up if (( analogread ( JoyStick_X ) > ( threshold ) && actuating == false ) ( digitalread ( x_up_pin ) == HIGH && actuating == false )) if ( servo_x_angle < 180 ) servo_x_angle ++ ; actuating = true ; //x.down if (( analogread ( JoyStick_X ) < ( threshold ) && actuating == false ) ( digitalread ( x_down_pin ) == HIGH && actuating == false )) if ( servo_x_angle > 0 ) servo_x_angle -- ; actuating = true ; // Y movement (signal detection) //y.up if (( analogread ( JoyStick_Y ) > ( threshold ) && actuating == false ) ( digitalread ( y_up_pin ) == HIGH && actuating == false )) if ( servo_y_angle < 180 ) servo_y_angle ++ ; actuating = true ; //y.down if (( analogread ( JoyStick_Y ) < ( threshold ) && actuating == false ) ( digitalread ( y_down_pin ) == HIGH && actuating == false )) if ( servo_y_angle > 0 ) servo_y_angle -- ; actuating = true ; // Move if ( actuating == true ) digitalwrite ( signal_pin, HIGH ) ; // actuating servo_x. write ( servo_x_angle ) ; //delay(50); servo_y. write ( servo_y_angle ) ; delay ( 500 ) ; actuating = false ; digitalwrite ( signal_pin, LOW ) ; // not actuating // display pos info lcd. setcursor ( 0, 1 ) ; lcd. print ( " position: " ) ; lcd. print ( servo_x_angle ) ; lcd. print ( ", " ) ; lcd. print ( servo_y_angle ) ; lcd. print ( " " ) ; delay ( 50 ) ; Arduino Z This Arduino is a two-state machine just like the previous one. It listens to two push buttons (PIN 2 and PIN 3) and a two bit message (via PIN 4 and PIN 5) from the Raspberry Pi. Either the push buttons or the Raspberry Pi message can trigger movement up or down the Z axis. 11/28

12 Sensory inputs : (i) Raspberry message and (ii) push (up/down) buttons i.- Raspberry message As with XY, the Z axis can be controlled from the output pins of the Raspberry Pi by using two-bit messages (i.e. two pins). The ground state of the system is not moving. A state-put message can be represented as (0,0) while the moving up and moving down messages are represented as (1,0) and (0,1) respectively. To listen to these messages we set PIN 4 and PIN 5 as digital input pis; to have a two-bit word to listen to the Raspberry Pi wishes for the Z axis. ii.- Push (up/down) buttons HomeScope has two push-down buttons for direct user interaction. These buttons have external pull-up resistors so when clicked, the buttons are transiently connected to ground and trigger a signal the Arduino code detects as a pushed button event. This signal is a transient LOW voltage on PIN 2 or PIN 3 which code for up and down signals. As soon as any of these situations is detected while on listening mode, the Arduino program enters into actuating mode and stops listening. In the actuating state, the code instruct the motor to move up or down as defined during listening mode. Actuation outputs : (i) Z stage movement (stepper control), (ii) Signal back to the Raspberry. i.- Z stage movement Stage movement is achieved by using two digital output pins (PIN 14 8 and PIN 9) to send the direction and step signals to the EasyDriver controlling the stepper. ii.- Signal back to Raspberry For the Raspberry Pi to know if the Arduino is listening or bussy actuating a stepper movement, we mirror the machine state to output PIN 12. This way we can inform the Raspberry Pi that the Arduino is busy moving the stepper. The code in the Arduino_Z.ino file controls the Z axis movement. We start defining a single variable DISTANCE to represent a unitary step size; this is to achieve the maximum possible resolution consisting on a single step per actuation cycle. #define DISTANCE 1 int StepCounter = 0 ; int Stepping = false ; We also define a signal_pin (PIN 12) that Arduino uses to signal back to the Raspberry Pi what state it is in ( actuation or listening). // declare flag pin to send digital output to the RASPBERRY PI int signal_pin = 12 ; /28

13 In the setup function we define output (8,9) and input (2,3,4,5) pins as well as writting the default value (0,0) message to be sent to the EasyDriver over PINS 8 and 9. void setup () pinmode ( 8, OUTPUT ) ; // to ctrl direction pinmode ( 9, OUTPUT ) ; // to step one step digitalwrite ( 8, LOW ) ; // no-step digitalwrite ( 9, LOW ) ; // direction pinmode ( 2, INPUT ) ; // physical button step-up pinmode ( 4, INPUT ) ; // GUI button step-up pinmode ( 3, INPUT ) ; // physical button step-down pinmode ( 5, INPUT ) ; // GUI button step-down Finally, the loop function has two if statements checking for move up or move down messages coming from the push buttons (PINS 2 and 3) or from the Raspberry Pi (PINS 4 and 5). In case one of such movement requests is detected, the machine switches from listening to actuating. Then, a third and fourth (nested) if statements take care of actuation. void loop () if (( digitalread (2) == LOW digitalread ( 4 ) == HIGH ) && Stepping == false ) digitalwrite ( 8, LOW ) ; Stepping = true ; if (( digitalread (3) == LOW digitalread ( 5 ) == HIGH ) && Stepping == false ) digitalwrite ( 8, HIGH ) ; Stepping = true ; if ( Stepping == true ) digitalwrite ( signal_pin, HIGH ) ; digitalwrite ( 9, HIGH ) ; delay ( 1 ) ; digitalwrite ( 9, LOW ) ; delay ( 500 ) ; StepCounter = StepCounter + 1 ; if ( StepCounter == DISTANCE ) StepCounter = 0 ; Stepping = false ; digitalwrite ( signal_pin, LOW ) ; // actuating // not actuating The code running on this Arduino controls a single stepper motor and provides a single degree of freedom which HomeScope uses to focus the RaspiCAM sensor at the sample plane. This 13/28

14 focus movement (Z axis) is powered by a Nema 17 stepper motor of 200 steps which is controlled by an EasyDriver which receives two-bit instructions from the Arduino via PIN 8 (direction) and PIN 9 (step). Controlling the HomeScope The HomeScope can be controlled by physical interaction with hardware located directly on the microscope or by software accessing the computer GPIOs. Applications running on the Raspberry Pi can access them via the gpio utility. Direct user interaction The user can communicate directly with the Arduinos; via a Joystick for XY movements and via two push-down buttons for Z movement. The user can also adjust the light level by controlling the voltage provided to the LED light directly via a potentiometer. Notice that image and video captured can only be done from a computer since the microscope only has a camera to see the sample. Computer control with Gtk and gpio Using GPIOs and a six-bit message protocol the Raspberry Pi can transmit information to the Arduinos so we can control the HomeScope from the Linux computer by using gpio, raspivid, and raspistill directly from the Linux shell. Although in previous guides we focused on shell scripting for timelapses, in this guide we explore the power of the Gtk GUIs and the Linux API have when developing algorithms for open microscopy. It is in this sense that this guide is more of a hacker guide centered around writing software to control open hardware based microscopes. The code running on the Arduinos provide the Raspberry Pi with a rudimentary messaging protocol to communicate movement wishes to the motors so they would move in some of the allowed directions. It consist 14/28

15 of a two-bit word per degree of freedom meant to communicate the movement the Raspberry Pi wishes via it GPIOs. Using two output pins (i, j ) for each of the three degrees of freedom X,Y,Z, we need six output pins on the Pi side (1, 2, 3, 4, 24, 29). We show here in the figure above such a simple messaging protocol. The Raspberry Pi can talk to Arduino XY (via a Logic converter) using four input pins (2, 3, 4, 5) on the Arduino XY side coding messages for two degrees of freedom (XY). Similarly the Raspberry Pi can talk to the Arduino Z using two input pins (4, 5) on the Arduino Z side to transmit messages and control focus (Z). Each degree of movement freedom has the following structure of pin states: (0,0) stationary state, communicate the stay-put message telling the Arduinos to stay in the current position; (1,0) move up, telling the Arduinos to increase the current microscope position; and (0,1) move down, telling the Arduinos to decrease the current position. The Raspberry Pi can monitor if the Arduino (both XY and Z) is in the listening or actuating state by monitoring a pin on the Pi side which reflects the Arduino s signal_pin state. We use PIN 12 on the Arduinos to send this one-bit message to the Raspberry Pi. Currently however, the code on the Pi ignores this information Using the gpio utility provided by the WiringPi library together with the Gtk library we build a couple of GUI based applications to control the HomeScope from a Linux based computer. Two pieces of code written in the C language are used to produce the Apps needed to control the microscope: OpenScope and OpenStage. OpenScope This is the program controlling movement in the Z axis (Z stage control), as well as responsible of implementing video and image capture (RaspiCAM control). An executable file open_scope, is made from a main code file written in C and compiled with gcc from the following four files: 1. open_scope.c 2. build_z.ui 3. kimero_lab.tiff 4. microscope.tiff The open_scope.c file is the main C code. It uses the Gtk library for implementing GUI code and its constructed using Geany as development environment. We also use Glade as graphical development environment and therefore we use a secondary file; build_z.ui, 19 which contains code that GtkBuilder uses to create the GUI. This Glade-generated XML file /28

16 contains all the graphical information needed by GtkBuilder to generate the Gtk code needed to link up all the GUI components with the rest of the code and libraries used. The kimero_lab.tiff and microscope.jpg files correspond to our lab logo and an application image icon. The OpenScope application, shown in the figure, runs on the Raspberry Pi and controls the Raspberry Pi camera (RaspiCAM). This application is also responsible of generating the messages to talk to the Arduino Z. These messages leave the Raspberry Pi from output PINS 24 and 29 and must arrive to the Arduino input pins PINS 4 and PIN 5. These messages consist of two-bit words (0,0), (1,0), (0,1) communicating the movement wishes of the Raspberry Pi: stay-put, move up, move down. On the Raspberry Pi side, the code sets up PIN 24 and PIN 29 to be output pins and use them to communicate with the input pins on the Arduino 20 Z side via a logic converter and using the gpio utility from the WiringPi library. Another important aspect of the App s GUI is that it allows to call rapistil from a Gtk button via the linux system call; here a shell is temporarelly forked while the pic is taken. For video streaming we use raspivid connected to the GUI via a Gtk switch but using 21 function g_spawn_async from the Glib library to do the forking. The file open_scope.c contains the C code implemented the application engine. First we include the libraries, gtk, stdlib, signal, unistd, stdio, and string which we need, #include < gtk/gtk.h > #include < stdlib.h > #include < signal.h > #include < unistd.h > #include < stdio.h > #include < string.h > Now we define an important global variable we need to keep track of the process id ( pid ) of any raspivid session we spawn from our application when a user switches on the video Gtk switch on the GUI; we will need this pid to kill such process when the Gtk switch is switched off or the program exits. 20 Note Raspberry uses 3.3V logic while the Arduino uses 5V logic /28

17 // This is a global variable holding the PID of a child to be created when accessing // the camera with raspivid program used in the start_video call back GPid pid ; The first function we need to implement is set_gpio_modes which sets up the pin structure and the pin values the App needs to know by default at launch time. void set_gpio_modes ( void ) //We use 2 PINS to communicate Z axis changes to the Arduino // // PIN, wirpi n. 24 system ( " gpio mode 24 OUT " ) ; system ( " gpio write 24 0 " ) ; // SET LOW by Default // PIN, wirpi n. 29 system ( " gpio mode 29 OUT " ) ; system ( " gpio write 29 0 " ) ; // SET LOW by Default // done with setting pins g_print ( " Finished setting up the GPIO PINs with gpio utility \n " ) ; system ( " gpio readall " ) ; We use set_gpio_modes to write the (0,0) message to a listening Arduino Z to communicate that we are stationary and do not wish to move in the Z direction. We also display the pin structure calling gpio readall via the system call. Next, we define the functions to deal with all the signals that could come from a user interacting with the Gtk Widgets. First, we define a standard Gtk function which handles user curiosity. A show_about function which is responsible of giving information to the interested user. // HERE GOES THE ABOUT DIALOG BOX For info at a website static void show_about ( GtkWidget * widget, gpointer data ) GdkPixbuf * pixbuf = gdk_pixbuf_new_from_file ( " kimero_lab.tiff ", NULL ) ; GtkWidget * dialog = gtk_about_dialog_new () ; gtk_about_dialog_set_program_name ( GTK_ABOUT_DIALOG ( dialog ), " Open Microscope Controller " ) ; gtk_about_dialog_set_version ( GTK_ABOUT_DIALOG ( dialog ), " version 1, January 2017 " ) ; gtk_about_dialog_set_copyright ( GTK_ABOUT_DIALOG ( dialog ), " Open Source Code, The Keymer Lab " ) ; gtk_about_dialog_set_comments ( GTK_ABOUT_DIALOG ( dialog ), " The Open Micro-Scope, an open source tool for DIY Biology. Thanks to Fondecyt " ) ; gtk_about_dialog_set_website ( GTK_ABOUT_DIALOG ( dialog ), " " ) ; gtk_about_dialog_set_logo ( GTK_ABOUT_DIALOG ( dialog ), pixbuf ) ; g_object_unref ( pixbuf ), pixbuf = NULL ; gtk_dialog_run ( GTK_DIALOG ( dialog )) ; gtk_widget_destroy ( dialog ) ; When the About button is clicked, this function (an event handler) triggers the opening of a standard Gtk about dialog box shown here. 17/28

18 Another very important function is the function handling video capture. When a user, switches on the Gtk switch on the video capture part of the GUI, it triggers Glib and Gtk to spawn a new process. This forked child process is needed to host the raspivid session responsible for the video streaming. The traditional system call approach (used with gpio and with raspistill ) does not work here since the GUI cannot afford to freeze while waiting for the end of a video streaming that might never end. For this fanzy task we use the function g_spawn_async within our start_video handler. // the call back needs this casting or it doesn't work properly static void start_video ( GObject * switcher, GParamSpec * pspec, gpointer user_data ) if ( gtk_switch_get_active ( GTK_SWITCH ( switcher ))) // here goes the code when the video swich is set ON g_print ( " Video streaming started... \n " ) ; // here is the argument vector to run as child process. gchar * child_argv [] = " /usr/bin/raspivid ", " -t ", " 0 ", " -ex ", " off ", " -p ", " 0,20,400,400 ", " -v ", " -awb ", " sun ", NULL ; gint stdout ; GError * error = NULL ; // here we spawn the child process to be handle PID pid g_spawn_async ( NULL, child_argv, NULL, G_SPAWN_DEFAULT, NULL, NULL, & pid, & error ) ; g_print ( " We have spawn a child process who's pid is %i, and we did from process %i which was in turn made from parent %i (the running shell) \n ", pid, getpid (), getppid ()) ; else // here goes the code for when video switch is OFF g_print ( " Video streaming stopped... \n " ) ; // the line bellow doesnt close the child // but is useful IF ever porting to windows. g_spawn_close_pid ( pid ) ; // this is the kill way in UNIX kill ( pid, 9 ) ; 18/28

19 Most of the job is done by the call to function g_spawn_async from the GLib and by constructing the argument vector, child_argv, which is then used as launching command for the newly spawned child process. This is the key line of code within the function start_video. It is the construction of a string representing the unix argument vector of the child process. This is done by the following expression present in the code above, gchar * child_argv [] = " /usr/bin/raspivid ", " -t ", " 0 ", " -ex ", " off ", " -p ", " 0,20,400,400 ", " -v ", " -awb ", " sun ", NULL ; This vector child_argv is passed onto g_spawn_async which is executed when start_video is called; which is when the Gtk switch is switched on. It is here where the argument vector is created so a child raspivid process which is spawned by OpenScope can have the standard parameters of the Linux API. When the user is done with video streaming she will switch the Gtk switch back to the off position; at this moment the same handler ( start_video ) will terminate the child process with ID matching to the PID value returned by g_spawn_async when it was called to create the child. The PID is a global variable we declared in the initial section of the code file. Of course We need a function to clean up the mess in case we quit the main application without switching the video capture off. For this cases we write clean_up_b4_go to make sure all is clean before exit. // not working properly...cannot recognize the switch... need to quit and kill raspivid if on static void clean_up_b4_go ( GtkWidget * widget, gpointer data ) if ( gtk_switch_get_state ( GTK_SWITCH ( data ))) kill ( pid, 9 ) ; As with the case of video streaming, another important function microscope users are usually interested in is image capture. As you can imagine, we use a system call to call raspistill within the event handler responsible of handling the clicked signal coming out the Capture Gtk button. We implement this action in function take_picture, the handler responding to the click of the image capture Gtk button. static void take_picture ( GtkWidget * widget, gpointer data ) if ( gtk_switch_get_state ( GTK_SWITCH ( data ))) gtk_switch_set_state ( GTK_SWITCH ( data ), FALSE ) ; system ( " raspistill -o open_scope_capture_picture.jpg -p 10,20,400,400 -v " ) ; gtk_switch_set_state ( GTK_SWITCH ( data ), TRUE ) ; else 19/28

20 system ( " raspistill -o open_scope_capture_picture.jpg -p 10,20,400,400 -v " ) ; The only tricky part in the code above is that before shooting the picture, we need to check for the status of video streaming. This is because RaspiCAM would not let us take a pic if the camera is busy streaming video. The hack is to be polite and first ask, then act! So we first check the status of the Gtk switch and if it is on, we first turn it off, then take the pic, and finally we turn it back on; else we just go ahead and shoot the pic. The final three functions to be defined correspond to handlers meant to respond to the clicking of each one of the three Gtk buttons controlling the Z movement: Up, Stop, Down. We first define a function called move_up to handle clicks of the Up Gtk button ; triggering the Raspberry Pi to send from output pins 24 and 29 the (1,0) message to the Arduino. static void move_up ( GtkWidget * widget, gpointer data ) g_print ( " Hello Open Scope: we are going up! \n " ) ; system ( " gpio write 24 1 " ) ; system ( " gpio write 29 0 " ) ; For moving down we define move_down to write the message (0,1) to be send from output pins 24 and 29 to the Arduino Z when the Gtk button with the Down label is clicked. static void move_down ( GtkWidget * widget, gpointer data ) g_print ( " Hello Open Scope: we are going down! \n " ) ; system ( " gpio write 24 0 " ) ; system ( " gpio write 29 1 " ) ; For stopping actuation and stay put in a fix location we use a function called stop. This handler is responsible of sending the (0,0) message to the Arduino Z from output pins 24 and 29. When the Stop Gtk button is clicked, the stage stops moving. static void stop ( GtkWidget * widget, gpointer data ) g_print ( " Hello Open Scope: we stop moving! \n " ) ; system ( " gpio write 24 0 " ) ; system ( " gpio write 29 0 " ) ; Finally, in the main block we use GtkBuilder to extract all the GObjects we need to draw the GUI (window, buttons, separators, and labels, and a switch). These are defined in the XML file builder_z.ui that we generate with Glade. We connect each Gtk button and Gtk switch to their respective handlers. Such connection is done using g_signal_connect. Here we also call the function set_gpio_modes setting up the gpio modes for the first time. 20/28

21 int main ( int argc, char * argv []) GtkBuilder * builder ; // Notice here we use builder (GLADE) to generate the interface GObject * window ; GObject * button ; GObject * switcher ; gtk_init (& argc, & argv ) ; /* Construct a GtkBuilder instance and load our UI description */ builder = gtk_builder_new () ; gtk_builder_add_from_file ( builder, " builder_z.ui ", NULL ) ; /* Connect signal handlers to the constructed widgets. */ window = gtk_builder_get_object ( builder, " window " ) ; g_signal_connect ( window, " destroy ", G_CALLBACK ( gtk_main_quit ), NULL ) ; button = gtk_builder_get_object ( builder, " button_up " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_up ), NULL ) ; button = gtk_builder_get_object ( builder, " button_down " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_down ), NULL ) ; button = gtk_builder_get_object ( builder, " button_stop " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( stop ), NULL ) ; button = gtk_builder_get_object ( builder, " button_about " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( show_about ), GTK_WINDOW ( window )) ; // Here we play with the switcher switcher = gtk_builder_get_object ( builder, " switch_video " ) ; gtk_switch_set_active ( GTK_SWITCH ( switcher ), FALSE ) ; g_signal_connect ( GTK_SWITCH ( switcher ), " notify::active ", G_CALLBACK ( start_video ), switcher ) ; button = gtk_builder_get_object ( builder, " button_take_photo " ) ; q_signal_connect ( button, " clicked ", G_CALLBACK ( take_picture ), switcher ) ; button = gtk_builder_get_object ( builder, " quit " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( clean_up_b4_go ), switcher ) ; g_signal_connect_swapped ( button, " clicked ", G_CALLBACK ( gtk_main_quit ), NULL ) ; /*Here we configure the modes of the GPIO PINs and launch*/ set_gpio_modes () ; gtk_main () ; return 0 ; 21/28

22 OpenStage The OpenStage is the application controlling the XY movements of the HomeScope. It is also written in C, and also uses Gtk and it is made from the following five files: 1. open_stage.c 2. build_xy.ui 3. kimero_lab.tiff 4. compass_rose.tiff 5. open_stage_view_area.jpg As before, the code file open_stage.c implements the message protocol so the Raspberry Pi can talk to Arduino XY via Arduino input pins PIN 2, PIN 3 for the X messages and PIN 4, PIN 5 for Y messages. These messages consists of to two two-bit words (one for each of the two degrees of freedom), corresponding to messages: (00), stay-put ; (10), up ; (01), down. On the Raspberry Pi side; we set the communication output PIN 1 and PIN 2 for X messages, and PIN 3 and PIN 4 for Y messages. In the C code, we set these pins using the Linux system call and the gpio utility from WiringPi. That way we set the four Raspberry pins PIN 1, PIN 2, PIN 3, PIN 4; all to a LOW. The GUI translate Gtk button event signals to a couple of two-bit words coordinating the stage movements. Again, as before, we use Glade as graphical development environment and within the C code, we call GtkBuilder to extract all the data needed from the file builder_xy.ui which contains all the XML code needed to generate all the GUI s Gtk Objects. Just as before the kimero_lab.tiff and compass_rose.tiff files correspond to our lab logo and and an application image icon. The file open_stage_view_area.jpg correspond to the image used to display the coordinates of the scanning area. It is shown when calling the About dialog. As with the other application, we start by including two needed libraries: the Gtk and stdlib #include < gtk/gtk.h > #include < stdlib.h > // value to use to generate LED light via PWM We define the function set_gpio_modes to set up the default pin values and structure void set_gpio_modes ( void ) // set pins to 00,00 state meaning no movement system ( " gpio mode 1 OUT " ) ; system ( " gpio write 1 0 " ) ; system ( " gpio mode 2 OUT " ) ; system ( " gpio write 2 0 " ) ; system ( " gpio mode 3 OUT " ) ; 22/28

23 system ( " gpio write 3 0 " ) ; system ( " gpio mode 4 OUT " ) ; system ( " gpio write 4 0 " ) ; //set the PWM pin and set it to zero system ( " gpio mode 23 pwm " ) ; system ( " gpio pwm 23 0 " ) ; This App controls the HomeScope illumination system; this corresponds to a single white LED placed under the Stage and aimed at the sample. Computer regulation of the light intensity is accomplished by linking a Gtk scale bar on the GUI to the PWM PIN 23 of the Raspberry Pi to power the LED with a variable voltage; ranging from zero to 3.3V. Thus, we define a handler pwm_scale_moved which responds to a user sliding the Gtk scale on the GUI; this triggers gpio to write a new value to the PWM pin via system call. static void pwm_scale_moved ( GtkRange * range, gpointer user_data ) gdouble pos = gtk_range_get_value ( GTK_RANGE ( range )) ; gint pwm_value ; pwm_value = ( gint ) pos ; gchar * str = g_strdup_printf ( " gpio pwm 23 %d ", pwm_value ) ; system ( str ) ; Now we need to link the four Gtk button objects on the GUI that we use for each of the movement directions available. We also need to code a stop button, and all the event handlers. These five handlers then generate and transmit the messages from the Raspberry Pi to the Arduino XY so it can actuate them. The first one of these handlers, move_x_up, handles up movements on the X axis by sending a (1,0) message from output PINS 1 and 2 on the Raspberry Pi side. static void move_x_up ( GtkWidget * widget, gpointer g_print ( " Hello x axis: we are going up! \n " ) ; system ( " gpio write 1 1 " ) ; system ( " gpio write 2 0 " ) ; data ) Similarly, for handling down movements on the same axis with define the function move_x_down. This handler sends the (0,1) message from output PINS 1 and 2 on the Raspberry Pi side. static void move_x_down ( GtkWidget * widget, gpointer g_print ( " Hello x axis: we are going down! \n " ) ; system ( " gpio write 1 0 " ) ; system ( " gpio write 2 1 " ) ; data ) For the analogous pair of movements on the Y axis; we move up with move_y_up which sends a (1,0) message from output PINS 3 and 4 on the Raspberry Pi side. 23/28

24 static void move_y_up ( GtkWidget * widget, gpointer g_print ( " Hello y axis: we are going up! \n " ) ; system ( " gpio write 3 1 " ) ; system ( " gpio write 4 0 " ) ; data ) Moving down is accomplished with the function move_y_down which sends a (0,1) message from output PINS 3 and 4 on the Raspberry Pi side. static void move_y_down ( GtkWidget * widget, gpointer g_print ( " Hello y axis: we are going down! \n " ) ; system ( " gpio write 3 0 " ) ; system ( " gpio write 4 1 " ) ; data ) To instruct the Arduinos to stop moving all together we define handler stop_moving, which generates and transmit a (0,0) message to all relevant output PINS (1, 2, 3, 4) on the Raspberry Pi side. static void stop_moving ( GtkWidget * widget, gpointer g_print ( " Stop moving stage now! \n " ) ; system ( " gpio write 1 0 " ) ; system ( " gpio write 2 0 " ) ; system ( " gpio write 3 0 " ) ; system ( " gpio write 4 0 " ) ; data ) As before, we also define a Gtk about dialog box to inform for the curious user with handler show_about. // HERE GOES THE ABOUT DIALOG BOX For info at a website static void show_about ( GtkWidget * widget, gpointer data ) GdkPixbuf * pixbuf = gdk_pixbuf_new_from_file ( " open_stage_viewarea.jpg ", NULL ) ; GtkWidget * dialog = gtk_about_dialog_new () ; gtk_about_dialog_set_program_name ( GTK_ABOUT_DIALOG ( dialog ), " OpenStage Controller " ) ; gtk_about_dialog_set_version ( GTK_ABOUT_DIALOG ( dialog ), " version 1, October 2017 " ) ; gtk_about_dialog_set_copyright ( GTK_ABOUT_DIALOG ( dialog ), " Open Source Code, The Keymer Lab " ) ; gtk_about_dialog_set_comments ( GTK_ABOUT_DIALOG ( dialog ), " The Open Stage, a GUI mapping Gtk buttons into Arduino microservo degrees. Thanks to Fondecyt " ) ; gtk_about_dialog_set_website ( GTK_ABOUT_DIALOG ( dialog ), " " ) ; gtk_about_dialog_set_logo ( GTK_ABOUT_DIALOG ( dialog ), pixbuf ) ; g_object_unref ( pixbuf ), pixbuf = NULL ; gtk_dialog_run ( GTK_DIALOG ( dialog )) ; 24/28

25 gtk_widget_destroy ( dialog ) ; Like in the previous application (OpenScope), clicking on the About button of the OpenStage brings up a Gtk dialog window with basic information about the application. For the case of the OpenStage, clicking on the About button shows the image stored in the file open_stage_view_area.jpg. It displays the coordinates of the spatial scanning area in both; linear mm and servo degrees. In this image, we can see a gray area with a red dot at the middle. Such red dot is at servo coordinates (90,90) corresponding to the middle of the servo s range. The view area is smaller and it is depicted here as a small white square. The size of this area depends on the magnification of the objectives used. OpenStage translates the scanning area leaving the optical and illumination systems stationary centered at the red dot corresponding to their axis of alignment with the viewing area. As with any application written in C, the main function main implements the main section of the code as well as it glues together all the functions defined above. int main ( int argc, char * argv []) GtkBuilder * builder ; GObject * window ; GObject * button ; GObject * scale ; gtk_init (& argc, & argv ) ; /* Construct a GtkBuilder instance and load our UI description */ builder = gtk_builder_new () ; gtk_builder_add_from_file ( builder, " builder_xy.ui ", NULL ) ; /* Connect signal handlers to the constructed widgets. */ window = gtk_builder_get_object ( builder, " window " ) ; g_signal_connect ( window, " destroy ", G_CALLBACK ( gtk_main_quit ), NULL ) ; button = gtk_builder_get_object ( builder, " stop_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( stop_moving ), NULL ) ; 25/28

26 button = gtk_builder_get_object ( builder, " x_up_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_x_up ), NULL ) ; button = gtk_builder_get_object ( builder, " x_down_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_x_down ), NULL ) ; button = gtk_builder_get_object ( builder, " y_up_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_y_up ), NULL ) ; button = gtk_builder_get_object ( builder, " y_down_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( move_y_down ), NULL ) ; button = gtk_builder_get_object ( builder, " about_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( show_about ), GTK_WINDOW ( window )) ; button = gtk_builder_get_object ( builder, " quit_button " ) ; g_signal_connect ( button, " clicked ", G_CALLBACK ( gtk_main_quit ), NULL ) ; scale = gtk_builder_get_object ( builder, " pwm_scale " ) ; g_signal_connect ( scale, " value-changed ", G_CALLBACK ( pwm_scale_moved ), NULL ) ; set_gpio_modes () ; gtk_main () ; return 0 ; Web Control The HomeScope can also be controlled from a web server running on the Raspberry Pi and using GPIOs to access Arduinos from a webpage. Web forms in PHP (instead of a GUI in Gtk ) interacting with Java code (instead of C) running on a JVM (instead of the Linux API); all supported by a Raspberry web server running on the HomeScope. Supporting Files Three *.tar file archives contain all the files needed: XYZ.tar open_scope.tar open_stage.tar /28

27 The first file, XYZ.tar, when expanded (using tar -xvf ), generates two sub-directories ( XY and Z ) within a directory called XYZ. These two sub-directories contain the files Arduino_XY.ino and Arduino_Z.ino respectively. The other two files, open_scope.tar and open_stage.tar, when expanded generate a directory for each of the two GUI applications. To produce OpenStage and OpenScope, just extract the directories open_stage.tar and open_scope.tar. To compile the code (assuming all dependencies are installed) type Make from each of the expanded two subdirectories Stage_code and Scope_code. 27/28

28 Acknowledgments This guide as well as the conception and creation of the HomeScope were only possible thanks to two collaborative research workshops. The first of these workshops we attended; was together with our collaborators Fernan Federici and Interspecifics at the Media Lab Prado in Madrid last year. This was the consequence of the inspiration we built together in Santiago while participating in the second Gathering for Open Science 25 Hardware (GOSH). It was here where we started researching together while having 26 Speculative Communications with microbes and started to explore the hybridization between hardware and biology. Overcoming the hardware intensive challenges of this emergent research project was only possible thanks to the lessons we learned at Shenzhen s electronic markets and hackerspaces while participating in a second workshop; this time with our collaborator Luping Xu from Open FIESTA at Tsinghua University Graduate School in Shenzhen. These two research workshops lead to the development of the HomeScope ; a platform for research, teaching, and community development made in Chile. Our participation in these fruitful development/research activities has been only possible thanks to the generous support of Chile s Conicyt research grant Fondecyt /28