Based on the main lesson link at https://hackmd.io/@Oggo2XIlRZ6wwlsXi_vc8Q/r14-DBZsh/%2FHh04T29ET7ivwDvT4S596Q

# Project
**Title:**
**Inoculation Robot**

**Description:**
Many biology experiments use cells. Many times the cells are cultured in Petri dishes. The cultures start by inoculating - adding a tiny amount of cells on the top of the media inside the Petri dishes. A precise inoculation to a certain position makes possible testing multiple colonies. That can also be coupled with a monitoring system for better control.

**Objectives:**
Be able to deposit a standard Petri dish of about 85 mm diameter with samples from multiple locations like for instance a 96 well plate or other standard labware.
Create a usable system for about 200$.
Use medium complexity tooling to keep the build accessible for users.
Test the system with cells for instance.
Reuse existing projects when possible
Document the system.

**Scope:**
Create one system
Use a COTS device for the motion in order to simplify availability, lower complexity, increase standardization and reduce build time
Optionally try to install some image analysis hhh

**Resources and Materials:**
Use a 200$ 18x40 cm CNC router
Adapt and use an existing inoculation loop

**Expected Deliverables:**
One functional system that includes hardware and software
BOM
Editable CAD design
Test results
Documentation

**Mentorship and Support:**
TBD

**Prerequisites:**
Acquire materials
Basic coding knowledge

**Benefits of Participation:**
TBD

**Location and Availability:**
Unless the team composition will change most of the development will take place in Ottawa, Canada.
At this point I can put in about 1-2 days a week however that availability will change during holidays and in case I'll travel.

# Week 2
Exercise 1: Start sharing your documentation
This project is about creating cell cultures.
The project will connect an existing CNC machine and an existing inoculating loop. The CNC machine is off the shelf for speed and cost purposes. However we will need to create an attachment for the loop and a customized bed that takes standard size labware like all pipetting robots.
Exercise 2: See how others do it
There are several pipetting robots on the market and one Opentrons in the open source. The older version of Opentrons sells for more than 8000$ while the newer one sells for 27000$. The new version has a 'gripper' that in principle could be used to take an inoculating loop but an adapter would still have to be designed. No known pipetting robots support inoculation directly.

Exercise 3: Make a plan for the future
* Bill Of Materials
TODO host the lab robot _bom file

* Written build instructions
Affix the sample tray to the CNC
* Images of build instructions
* Instructions to verify correct functionality
Position several Petri dishes with test images on the tray
Upload the smokeTest GCode file on the CNC
Start the smokeTest
* Example uses of the product:
Example 1: Let's say we are trying to compare the best strain of a bacteria that produces a black pigment. We grow Petri dishes with let's say 96 strains. We compare the results to determine the best strain.

* Optional: Video of build instructions.

Project documentation

Current state of the project
Project in final phase.
Design of deck and frame try finalized.
Design and test of the loop holder finalized.
Design and test of custom Petri dish holder finalized.
Design of additional labware finalized.
Software to program the robot finalized
Testing the robot with live cells finalized
Future plan of the project
Enhance the existing simulator to allow zoom, add camera to the robot head
How to contribute
Contact the project team with information about interest, skills and availability
Where to find what or ask for help
Read the FAQ. Should the answer not be there please contact the author directly using the form in the about link at specyal.com

# Week 3
# Framing Open Hardware projects

**We use Moore’s original 6-step value proposition formula:**
For researchers, primarily in molecular biology
Who want to create multiple cultures in an automated way

**Priority Features/ target specs**
Must be able to create at least 400 individual colonies and have a price lower than 300$
could have a camera attached
Could have triggers and alarms

**Frame your next iteration**
We will start with the 3D machine and determine the exact version, variant and BOM

# Week 4

Name of the person reviewing

[Adrian]
Name of the project being reviewed

[ MRI Compatible Treadmill for Mice]
[https://hackmd.io/@Oggo2XIlRZ6wwlsXi_vc8Q/r14-DBZsh/https%3A%2F%2Fhackmd.io%2FS7PtZkiLRKefOFux3Snekw]

Provide feedback in the form of recommendations, observations, suggestions, or questions

For each feedback session:
- Write a minimum of 5 points where you think there is room for improvement
Try to find more papers on the subject
Find the current industry solution
Understand the critical issues
Contact the author of the referenced paper and ask if his device is used in practice
try small steps - like printing samples early
find other devices that work under MRI
- Write a minimum of 3 aspects you like about the project
It's clear
already has a similar implementation
Gul is familiar with the area and could use this in practice

Give feedback on your hardware documentation

Look for the following:

Is the project find-able or accessible?
Check if the read-me contains an introduction with a clear value proposition?
Check if you can figure out easy to navigate is the project via the folders
Check if assembly instructions are published;
Check if the bill of materials is published;
There is some contribution guidance is published;
published files are shared in original format (for example Gerber files or cad files)
use of versioning control system
use of issue management system
all this information is published under a license allowing commercial reuse.

Give feedback on your project

The main goal is to see if you have set up a systematic plan to realize your project vision and if it’s realistic in terms of time and scope.
Instructions:

Is there a list of priorities or hypothesis
- This could be in the form of a roadmap
- or a progress board with a list of features
- or GitHub issues
- (Some kind of project documentation that reflects your thinking)
Is there consistency between ideas and expectations, and ongoing prototyping activities
Do you think these prioritized tasks are feasible during the academy or the next 3 months
- Or would you recommend breaking down the project into smaller iterations

* Week 5

* Exercise 1
Create progress board on GitHub
* https://github.com/users/AdrianMolecule/projects/1/views/1

* Exercise 2

template

## Test name (this can be the name of the GitHub issue)
duration, deadline (these metadata can be added in GitHub issues)

Step 1: hypothesis
- We believe that a 40x18 cnc machine is usable
- Hypothesis importance (score from 1 to 3)
- Score 3

Step 2: Test
- To verify that, we will..test hand written gcode to verify that the loop can be moved to apropriate locations,
you can also use sketches and images>
- Test cost (from 1 to 3) 2
- Data reliability (score from 1 to 3) 2

Step3: Metric
- And measure..that the positioning is sufficient to safely target the wells... <what is your core >
- Time required 2+ weeks

Step 4: Criteria
We are right if...loop safely target the wells within 1 mm of the center... <here goes the criteria that need to be
met for this test to be positive>

Learning documentation

Step 5: Observation
- We observed that ..... at this point there is another OS (https://docs.pylabrobot.org) that aims at creating UI for pipetting robots. We could maybe use that

Step 6: Learning and insights
- From what we learned that .... While the OS software still seems to have a lots of limitations and bugs it does have a decent coordinate management that we might be able to use

Step 7:
- Therefore, we will ... <what you will do after capturing this insight, perhaps new prototypes or different types of tests>

# Week 6 Testing

Exercise 1: Include verification tests in your testing plan

If you have gone through the previous lesson: hardware design and prototyping lesson then you have alrady created a testing progress board containing your tests/experiments.
Testing process and board summary

Instructions

Revisit your testing board
Add sanity checks or tests that aim to verify target features and/or specifications considering the steps above explained
Do a testing board with your testing overview for verification tests (if you haven’t)

Exercise 2: Design a test to check the sanity of the primary behavior of your project

Instructions

Use the template below to describe a test case
(Consider adding this as a task on your project board)

Test Case Design

Test Case Name:

Test description:
The description of the test case you are going to test.

Revision history:
Adrian 11/5/2023
Each test case has to have its revision history in order to know when and by whom it is created or modified.

Function to be tested:
The name of the function to be tested.
Unit test the third party software

Environment:
It tells in which environment you are testing.
Just the 3d machine with no custom bed or attachment

Test Setup:
Anything you need to set up outside of your application for example printers, network, and so on.
After assembling the inoculating robot inoculate at least 100 colonies.
Test Execution:
It is a detailed description of every step of execution.
Produce the points where colonies will be placed. Create the software to take the cells from source wells and inoculate them on Petri dishes.

Expected Results:
The description of what you expect the function to do.
The colonies are deposited at the proper places. The surface of the media is not stabbed or just superficially stabbed by the loop. The loop should carry 1 micro-liter of inoculum or less. The colonies should be well defines and should be placed less than 3 mm apart without contamination

Actual Results:
pass / failed

If pass - What actually happens when you run the test?

If failed - put in the description of what you've observed.

Exercise 3 (optional): Design a test bench for those tests that you think you need to perform several times

Instructions

Make a bill of materials for your testing environment
Design your testing environment (make a sketch or a draft)
(Consider adding this as a task on your project board)

# Week 7 Licensing

Exercise 1

What kind of license do you want to use for your project?

The goal here is for you to think about how you see your project being used by others and what you would like to see/not see happen to it. Which is exactly what licensing is about. Explore some of the documentation associated with the licenses discussed in the lesson. Pick a license that suits your goals and explain why that is the case.

I choose:
Apache 2.0 for Software. Why? because I used libraries developed under it in the past despite that it allows patenting by beneficiaries. Also modifications should be made known which protects the original author for liability in case the modifications introduce security issues for example.

CERN Open Hardware Licence Version 2 - Strongly Reciprocal for Hardware. Why? because I like to keep the hardware part open

Creative Commons Attribution 4.0 - for Docs. Why, because of popularity

Exercise 2:

Investigate an open source hardware project and the license used.

The goal here is to check to see if open hardware projects are properly licensed. Check to see if all the relevant parts are shared and have an appropriate license. Compare the project you have chosen with a project that has been certified as open by the OSHWA. Here is the list of certified projects https://certification.oshwa.org/list.html

For instance https://gitlab.com/open-bioeconomy-lab/open-lab-hardware/bioreactor/opensourcebioreactor
Has only MIT license thus only software license permissions which probably means it cannot be built by anybody else.

https://edinburgh-genome-foundry.github.io/DnaChisel/ has MIT for software and none for documentation.
Benchling https://www.benchling.com/ a commercial product is using it.

OpenFlexure https://github.com/rwb27/openflexure_microscope/blob/master/License has CERN but does not have contain software.
Software is a https://gitlab.com/openflexure/openflexure-connect/-/blob/master/LICENSE?ref_type=heads
OpenFlexure is not in the https://certification.oshwa.org/list.html

# Week 8 Versioning and Releasing

Exercise 1: Define what kind of release you are working towards

Instructions:

Specify what is the scope of your content to be released
Consider this scoping for the next section on planning a release.

Scope
An experiment/hack/build
An alpha prototype meant to get feedback from early adopters
A beta prototype to get feedback from the public
A fully maintained and supported open hardware project
Lifecycle and continuity
Project is a one-time release
Project is being maintained and in continuous development
Project is seeking user feedback
Project is looking for contributors
Exercise 2: Make a release checklist that you can easily incorporate as tasks in a project board

:information_source: This template is based on the [open hardware canvas provided by open makers](https://curriculum.openhardware.space/articles/01-welcome-to-ohm/canvas/)

Instructions

Fill in the template fields with checkpoints, todos, and considerations to make your release plan and notes more clear.
If you have a project board or you are using issues consider adding the different tasks to your board
If you are approaching your project progressively you can design a release sprint where you add these tasks to your release sprint backlog.
Share your release planning notes to get feedback

# Release planning notes
## Release notes
- What is the status of the project?
- What features were implemented?
- Add your semantic versioning if applicable
-

## License(s) for different modules of the project
CERN, Apache 2, CC
...

## Bill of materials
...

## Assembly instructions
...

## Source files
...

## Resources and materials needed to re-use and or work in the project

## Contributor Channels
...

## Contributor Docs
...

## User channels
...

## User Docs
- Select documentation medium
- Your documentation package in a shareable format
...

## Similar projects (Optional)

## Metadata (added if applicable)

Exercise 1: Define what kind of release you are working towards

Instructions:

My Scope for PortablePipette: Project is being maintained and in continuous development

Specify what is the scope of your content to be released
Consider this scoping for the next section on planning a release.

Scope
An experiment/hack/build
An alpha prototype meant to get feedback from early adopters
A beta prototype to get feedback from the public
A fully maintained and supported open hardware project
Lifecycle and continuity
Project is a one-time release
Project is being maintained and in continuous development
Project is seeking user feedback
Project is looking for contributors
Exercise 2: Make a release checklist that you can easily incorporate as tasks in a project board

:information_source: This template is based on the [open hardware canvas provided by open makers](https://curriculum.openhardware.space/articles/01-welcome-to-ohm/canvas/)

I used https://github.com/AdrianMolecule/pipetteholder/blob/master/PipetteHolderCanvas.odp

Instructions

Fill in the template fields with checkpoints, todos, and considerations to make your release plan and notes more clear.
If you have a project board or you are using issues consider adding the different tasks to your board
If you are approaching your project progressively you can design a release sprint where you add these tasks to your release sprint backlog.
Share your release planning notes to get feedback

# Release planning notes
## Release notes
- What is the status of the project?

Project is finalized. New features would be developed only on request or based on concrete needs.

- What features were implemented?

- Add your semantic versioning if applicable
1.1

## License(s) for different modules of the project

...

## Bill of materials
...

## Assembly instructions
...

## Source files
...

## Resources and materials needed to re-use and or work in the project

## Contributor Channels
...

## Contributor Docs
...

## User channels
...

## User Docs
- Select documentation medium
- Your documentation package in a shareable format
...

## Similar projects (Optional)

## Metadata (added if applicable)

# week 9 Sustainability

Exercise 1 (Optional) - Assess the sustainability of your current project cycle

Instructions: Fill in this test card to incorporate in your project board (This doesn’t have to be public as these are personal internal aspects of a project. You can talk about it with your peers and mentors)

## Test name (this can be the name of the GitHub issue)
duration, deadline (these metadata can be added in GitHub issues)

Step 1: Sustainability hypothesis
- Example 1: I believe that I can deliver this project in 1 months while I am doing also my master studies or PhD because I can do it relatively easy and I know exactly how to do it.
- Example 2: I believe I can learn new things in this project and will also complement my studies.
- Hypothesis importance (score from 1 to 3)
Adrian: I believe I can finalize the build and the tray in April.
Step 2: Test
- Example: To verify that, I will plan a sprint of 3 months where I will focus on a set of tasks....
I believe I can use the spindle signal off the CNC card to start the focusing and picture taking process. I have a full time job and also another open source project that was financially pledged however I don't think financing for it will be done before mid February so it should not interfere. The most important is that I personally am the first consummer of the project and that is a big factor to increase sustainability
Step3: Metric
- Example: And measure..... how much time it takes me, how capable I am actually of performing the tasks
- Example: How many hours I spend
- I will spend at least 2 hours pretty much every day. Fortunately I have done similar things in the past.

Step 4: Criteria
Example: I am right if I can deliver most of the tasks I planned in my sprint.

Learning documentation

Step 5: Observation
- Example 1: I observed that ..... The problem was a bit more complex than expected
- Example 2: I observed that some people replicated the hardware successfully.
I observed many people including me use the existing CNC hardware.

Step 6: Learning and insights
- Example 1: From what I learned that project needs more time and expertise in hardware electronics
- Example 2: Someone with coding expertise would be needed if I want to make a more robust solution.
- Example 3: From what I learned that other potential contributors found similar projects that are more mature
I found that most people that volunterr to help usually don't put sufficient time and usually become unavailable shortly after volunteering. I found that only people with some forms of vested interest will become significant contribuitors. I found that understanding the motivation and availability of potential contributors is very important.
I will try to contact people that changed the software in the 'open' CNC card.for short term help and potentially for longer collaboration.

Step 7:
- Example 1: Therefore, I will ... stall the project for now
- Example 2: I will continue the project if I find someone that wants to co-develop with me the coding aspect of it.
- Example 3: I will continue to a next cycle if the acceptance tests are successful and early adopters are willing to use my hardware product.
I will continue the project towards the simplest possible prototype. I will ask for help from people that did similar projects especially if hitting roadblocks

Exercise 2 (Optional) - Assess the sustainability of your project after your next release

Instructions: Fill in this test card to incorporate in your project board.

## Test name (this can be the name of the GitHub issue)
duration, deadline (these metadata can be added in GitHub issues)

Step 1: Sustainability hypothesis
- Example 1: I believe that after I finish this cycle and I release my content I will not need to maintain the project further.
I believe that any project needs to be significantly redesigned about three times to become very stabile.
- Example 2: I believe the feedback I will get on my alpha testing will allow me to show evidence to attract funders and new developers.
I believe users of alpha testing will provide details that I can use to iron out the kinks.
I believe that a video will help with dissemination of information
- Example 3: I will provide budget for contributors to replicate the hardware and perform acceptance testings...
- Hypothesis importance (score from 1 to 3)

Step 2: Test
- Example: To verify that, I will release my project and deliver a couple of seminars to engage with potential community members.

Step3: Metric
- Example 1: And measure..... How many capable contributors get engaged in the community calls
- Example 2: How many people replicate the hardware, do acceptance testing and provide feedback

Step 4: Criteria
Example: I am right I find contributors to run acceptance tests.

Learning documentation

Step 5: Observation
- We observed that .....

Step 6: Learning and insights
- From what we learned that ....

Step 7:
- Therefore, we will ... <what you will do after capturing this insight, perhaps new prototypes or different types of tests>

# week 9

[Final presentation](https://hackmd.io/td1XHJQVQiGMaEu0eFAAFA)