## 6 Discussion
### Open-Source Hardware
Basically, this allows a user to order the parts ready to assemble (laser cut parts, 3D printed parts and custom  
Figure 10: A pH module developed by a student. The module was designed by modifying the dispensing module. electronics). However, this does not solve the entire problem as there are still a few relatively complex operations for a lay person: machining some parts (countersinking), add threaded inserts, prepare electric connectors or general troubleshooting in case that something does not work. The skills and technologies required to build EvoBot are similar to the ones required to build a 3D printer. Therefore, interested persons without the necessary skills can employ a lot of resources that are available online. Another drawback of open-source hardware is that it usually needs to be calibrated to guarantee that the performance meets the requirements of the application. Specifically, liquid handling performance can be tested, if the volumes to test are large, by using an accurate scale. For small volumes, the gravimetrical method is complex as it needs analytical scales to measure the weight with enough precision, special procedures to avoid vibrations and to take into account the evaporation. Thus, other techniques, like photometry, are more suitable for small volumes. Finally, lack of support is another important issue in open source hardware. Commercial robots have troubleshooting guides and customer support, whereas forums provide an effective way to give support between users in large open source communities. However, support is very limited in small open source communities. EvoBot has only a small wiki addressing the most common problems, but we provided support for our partners during the Evolbiss project. In our case, the main problem was that it is required to program the robot to be able to use it (we offer a simple GUI to control EvoBot manually, but it is slow compared to manual pipetting). As only few biologists and chemists can program proficiently, we provided basic templates for their experiments. Even with these templates, some of our partners struggled to adjust the parameters of the programs (like the position and height of the vessels) or to make basic modifications to these programs. Finding the coordinates for each vessel is time consuming and recalibration of the vessels' heights is required every time that the actuation or experiment layer is moved up or down. Another issue is that they usually need to integrate specific hardware for their experiments, which was not supported by our API. For example, we had to integrate in our API voltage data loggers for the MFC experiment. In addition, the setup of experiments carried out in physical machines is time consuming. If there is an error in the middle of an experiment, the user needs to stop the robot and restart the program. Sometimes, it can be possible to continue the experiment from where it failed, but the program has to be prepared for that, or the user should be able to implement the needed changes in the code. Therefore, users often start the program from the beginning and setup the robot again (clean or replace vessels and containers, refill liquids, etc.) In the droplet experiment, the robot saved the fitness of each recipe in a text file, so we could resume the program easily. Regarding mechanical issues, the syringe modules can get stuck if the plunger pushes the bottom of the syringe. This deforms the 3D printed part that holds the plain bearings, which increases the friction force. In most of the cases, the error came from reusing the code of a 1 mL syringe with a 5 mL syringe, which has a shorter stroke for the plunger.