<!-- :::danger
❗Copy the contents of this HackMD page and make your own HackMD page for the person you are writing the feedback. ❗
::: -->
# Alexander: Project Notes & Exercises

# Educational Water Pump

Inspired by the competition [Aqualibrium](https://www.aqualibriumcompetition.net/joomla/) on designing a simple water distribution system. I thought about including a simple pump for the students to play with it. This addition aims on expanding the exposure of the students to an important component in the networks and also to facilitate the gameplay.

In Aqualibrium, the participants decide which set of pipes would transport the water from the elevated container to the three small beakers in the most equilibrated way as possible. The perfect scenario would be to have all 3 little containers completely filling up at the same time. If there's difference between the contents of the three beakers, there's a penalty.

I've seen how entertaining this is for students (and professionals!). And it gives a practical feeling for the underlying systems that transports water to our houses every day.

However, the system is lacking some important components, for example, a pump.

This is how an Aqualibrium setup looks like.

[Video explanation of Aqualibrium](https://www.youtube.com/watch?v=C9Z7qE8plec)

I found some designs of micro-pumps

---
# Week 0
## Exercise 1: Choose your project

My favorite challenge is: Educational water pump (Personal project)

A backup option would be: [SONY-Spresense Open Hardware Challenge](https://docs.google.com/document/d/1nt5LLvU_BePQEVG-Zkp5u8ke0oQyU4XcrDo-a8XQBrs/edit)

# Week 1

## Exercise 1: Go through the OSHWA definition
- Read the definitions and principles: [OSHWA definitions](https://www.oshwa.org/definition/) ✅
- Share in the chat which principles you find useful in this document that you think can improve your current practices and why.

## Exercise 2: Learn from open source projects
- Pick at least one of the many influential projects in open source hardware and get familiar with its history. (There is a list bellow, for example you can pick one software project and one hardware project to compare similarities and differences.)
- Think about the concepts and ideas we provided in this lessons, were you able to spot some of these characteristics in the project you selected?
- Share in the chat what captured your atention about the project
- What did you find different in their approach compared to your idea of how hardware is developed and distributed?
- What did you find familiar to your own practice?

**Some interesting open source projects and initiatives you can google:**

**Hardware**
- Arduino
- RepRap and Prusa 3D printers
- Adafruits company
- Precious plastic
- others...

**Software**
- Python
- Linux and git
- FreeCAD
- OpenSCAD
- others...

## Exercise 3 (Optional): Find an open source project related to your domain
Find out if there are open source projects out there related to your project. You can start with the [open hardware observatory](https://en.oho.wiki/index.php?title=Special%3ARunQuery%2FprojectSearch&pfRunQueryFormName=projectSearch&ProjektSearch%5Bcontains_pdf_drawings%5D=yes&ProjektSearch%5Bsubcat%5D=Bending+machine) where there are lots of open hardware projects.

I found an [Open-source Hardware water pump](https://en.oho.wiki/wiki/Hydraulic_Ram_for_Pumping_Water) that can be useful as a guide to construct the pump. Nevertheless, I want to use a different physical principle for pumping the water.


# Week 2
## ~~Exercise 1: Start sharing your documentation~~
- Write a simple introduction to your project assuming that the audience is new to the topic and not familiarized with it.
- Make it in a format that can be easily edited, presented, and shared online.
- If you are just getting started, we recommend starting with Markdown and hackmd as a platform to present, share and get feedback.
- This will make it easy for the mentors to comment and help you out)
- Alternatively, if you have already a git repository or documentation published in a platform of your preference feel free to reuse that and avoid repeating yourself.
## Exercise 2: See how others do it
- Find an open source project, this can be one that you found last week, and see how they did their documentation, it can be handy to make an overview or to write down what you liked and what you did not like.
- You can do the following:
- Reflect on how open it is and how easy it is to get started with it.
- Reflect back on your documentation to see if you can improve it based on looking at other projects.

**Alex:** Hydraulic Ram for Pumping Water

Why? It is the closest to the idea I have in mind, and it is in the Open Hardware observatory, which gives me some confidence about the quality of the documentation.

👍 Liked:
- Video with the assembly and parts.
- It has some pictures
- It has CAD files
- It has PDF blueprints

👎 Could be improved:
- There are no assembly instructions.
- There is no picture of a real piece. That gives me the feeling that they never built it. Without it, there is no practical experience of what can go wrong in the installation or tips to bear in mind.
- There is no community around it or questions posted.
- I did not find any contact email or similar.

Overall, it is a good starting point, and it gives me an idea of what CAD files and PDF plans could be expected.

## Exercise 3: Make a plan for the future
- Make a checklist of what your documentation should look like by the end of the program.
- Assess if it is too much for your current status or is a good match.

Checklist:
When the hardware is tested and finalised the documentation should contain
- [ ] Core documents
- [ ] Getting_started.md
- [ ] Introduction
- [ ] Project at a glance
- [ ] Assembly instructions
- [ ] Design sketch
- [ ] Tutorial.md
- [ ] Images
- [ ] Assembly parts
- [ ] Finished product
- [ ] Bill_of_Materials.excel
- [ ] Name
- [ ] Dimensions
- [ ] Where to find it
- [ ] Cost

I think for now, this is sufficient to break down the project in a very early stage. With feedback and new information I gather, I will expand the documentation.

# Week 3
## Exercise 1: Create a first value proposition
The goal of this exercise is to frame explicitily your project by writing down the theory behind it. Remember the idea is that once you generate these hypothesis the next step is to design experiments that allow you validate them.
- Generate some hypothesis and ideas about your project using the value proposition canvas.

:::success
**Some tips and considerations**
- Consider that a starting point can be a product you want to improve, simply open source, or create a new version of your project (v.2.1)
- Think of the value proposition canvas as a specific type of camera to take pictures of the thinking and assumptions behind your project.
- This is a hypothesis generation tool (one of many) the point is to help you structure your hypothesis and organize them according to certain concepts that are common in product development.
- You can start from the square (left to right) or from the circle (starting from needs)
- Your customer or user can be yourself (this is quite common with hobbyist and DYI projects, even for the linux kernel and git this was the case)
- Substitute the "products and services" part of the canvas with your target features and specifications (performance, materials, costs).

:::

<!--
- Here are two templates for you to reuse. Feel free to extend your notes if needed. -->

**Template 1**

Here’s Moore’s original 6-step value proposition formula:
For (target customer)
Who (statement of need or opportunity)
The (product name) is a (product category)
That (statement of key benefit - that is, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)

**For** students of water distribution systems
**Who** are trying to understand how these systems work
**The** EdWaP is an analog micro-pump
**That** is cheap to create and allows the student to directly interact with the component
**Unlike** electrical water pumps focused on functioning
**Our product** uses mechanical energy to move the water

<!-- **Template 2**

# My awesome value proposition
## Jobs
(This might be unknown for some projects)
-
-
## Pains
-
-
## Gains
-
-
## Product features and specs (Products and services)
(This might be unknown for some projects)
This is like the core concept of your solution, key features and spects.
-
-
## Pain relievers
-
-
## Gain creators
-
-

## Other things you want to include in your frame?
(You can extend your framing with whatever you find relevant to make your project theory more complete)
- Deadlines??
- Desired outcomes???

## Exercise 2: Prioritize your target specs and features
This exercise is meant to help you specify what attributes of your product idea is essential. Which are those target specifications, features and functional driven goals that if met are going to make your project or next release relevant?

Here is template to help you get started:
|Priority| Features/ target specs|
|--------|-------|
|Must have| |
|Should have|
|Could have|
|Won't have|

## Exercise 3: Frame your next iteration
Now that you have captured hypothesis and ideas about your project. Pick an aspect, target specification or spec you think is critical, and frame an iteration of your project where you focus solely on these aspects.
::: success
**Tips**
- Set a goal or intent for this iteration (Is it going to be documentation focused? Focused on refinement? Testing and debugging something you have made? Or getting feedback from potential users?)
- Think of an iteration or sprint as a period of 1-3 months where you end up with a deliverable that includes what you build, why you build it, the results and the learnings.
- It may well be that your project is already functioning and yu simply need to focus on documenting it in the best possible way you can for the "customers" or target audience you are prioritizing.
- You might want to focus on a core component of your project (software, electronics)
- Or you want to test options of materials and find suppliers that allow you to lower the cost of the project.
- It can be a know-how building iteration where you focus on learning through different builds of setups to understand better the problem.
:::

## Exercise 4 (Optional): Generate an assignment
- Use your framing knowledge to generate an assignment or design challenge.
# Week 4
**Goal:** The goal of these exercises is to help you set up a simple testing framework with a free, simple and available tool that is widely used by open source communities in software and hardware development.

**Hopefully these exercises will help you work further in your project using an agile-like project management approach.**

## Exercise 1: Create a progress board
We are going to rely mostly on GitHub and markdown to do these exercises. Consider doing all the documentation using markdown in your own notes and then transfer them in github issues and the board so that you keep also those notes reusable.

:::warning
:hand: Before getting started you need to have a GitHub
:::
**Instructions:**
- Create a GitHub project if you haven't for your project (remember you can use github as one of the different distribution channels for your open hardware documentation)
- Use GitHub project boards to create a progress board. Make an example that people can copy

## Exercise 2: Pick up a hypothesis that is core to your project and design several experiments using the test cards
:::warning
:hammer_and_wrench: Here we provide a template that already combines a test card and a learning card. This
:::
**Instructions**
- Document your experiments in a local hackmd so that you can reuse it later using the template we are providing below.
- Open an issue and name it based on a test design.
[Read more about how to open an issue in GitHub](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue).
- Add the issue to your project board. [Read more about how to do this step](https://docs.github.com/en/issues/tracking-your-work-with-issues/creating-an-issue)

### 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 .... <here goes your hypothesis>
- Hypothesis importance (score from 1 to 3)

Step 2: Test
- To verify that, we will.... <here goes your experiment design, 
you can also use sketches and images>
- Test cost (from 1 to 3)
- Data reliability (score from 1 to 3)

Step3: Metric
- And measure..... <what is your core >
- Time required 

Step 4: Criteria
We are right if...... <here goes the criteria that need to be 
met for this test to be positive>

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>

## Example: 3D printable hand-powered centrifuge
This exercise uses the [3D -Fuge: A New Hand Powered Centrifuge](https://www.labonthecheap.com/3d-fuge-a-new-hand-powered-centrifuge/) as an inspiration to demonstrate how you can design a test card and they haven't been tested, therefore the learning part is just an example for the purpose of this lesson.

:::spoiler ### Test 1 focused on target specifications hypotheses (verification)

**Step 1:** We believe that a portable hand-powered centrifuge of less than 20 EUR can be used to analyze diseases like meningitis and aids in extreme situations where there is no electricity.
(This hypotheses has an importance score of 3)

**Step 2:** To verify that we will build a 3D printable prototype with a rotational mechanism that delivers the force needed to achieve the target spec of 2000 CFR and build a test setup with a sensor to test the speed of the centrifuge.

:warning: Notice in this step that the prototype involves designing the testing setup, otherwise the target spec cannot be measured accurately.

**Step 3:** We will measure the Centrifugal Relative Force that separates the sample matter (2000 CFR)

**Step 4:** We are right we can deliver the CFR at a certain time (2 mins, and we can separate the samples, and it is doable by a person X times per hour. This is an example of a target spec that allows to translation of the hypothesis into a testable idea.

**Step 5** We observed that the centrifuge can rotate up to 30000 RPM.

**Step 6** We learned that is possible to build a centrifuge of this kind with recycled PLA for much less than 20 EUR of costs.

**Step 7** Therefore we will develop new experiments and prototypes focused on testing the robustness usability and lifecycle of such a centrifuge in actual usage environments.

:::

---

:::spoiler ### Test 2 focused on testing contributor and user channels (validation)
**Step 1:** We believe that many people around the world will be interested in testing and replicating this prototype and provide useful feedback on how relevant it is for the target usage context.

**Step 2:** In order to test this, we will generate clear building guides with the STL files to print and clear documentation of how to separate a sample with coffee. We will also provide a simple form with some questions and fields to provide feedback. The form will be a clear contribution request.

**Step 3:** We will measure likes in GitHub, we will measure

**Step 4:** We are right if someone doing a diagnosis of these diseases in these difficult contexts confirms that this is a useful

**Step 5**
- We observed that most enthusiasm came from teachers and educators in high schools and primary schools that have local maker spaces.
- There were a variety of hobbyists and enthusiasts
- Few but relevant responses from physicians doing service in rural areas.

**Step 6** The audience that is more interested in the project is not the one we expected.

**Step 7**
Therefore we will:
- Keep reaching our target audience and learn more from contexts in which this tool could be used.
- Think of a different low-cost design that is battery-powered or even solar-powered.
- Refine the design based on user feedback.
- Document an assignment for a mechanical engineer to optimize the design for 3D printing and injection molding.
:::

# Week 5
## Exercise 1: Include verification tests in your testing plan
:::warning
If you have gone through the previous lesson: [hardware design and prototyping lesson](https://hackmd.io/1kONu5gwSS6knAGnwcO5KQ) then you have alrady created a testing progress board containing your tests/experiments.
:::

:::spoiler Testing process and board summary

:point_up_2: Image retrieved from the book: "Value proposition design: How to create products and services that customers want"

**Progress board**
This tool simply aims to structure your testing process by starting from left to right with your core ideas broken down into prioritized hypotheses (concepts, ideas, sub-problems, sub-solutions). Then we have a backlog of tests that can also be prioritized using the prototyping criteria we have shared in previous sections and ends up with learnings and knowledge that are captured in better design specifications and choices.


:point_up_2:  Image retrieved from the book: "Value proposition design: How to create products and services that customers want"

:::

___

**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:
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.

Environment:
It tells in which environment you are testing.

Test Setup:
Anything you need to set up outside of your application for example printers, network, and so on.

Test Execution:
It is a detailed description of every step of execution.

Expected Results:
The description of what you expect the function to do.

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 6
:::danger
Copy the contents of this HackMD page and make your own HackMD page for the person you are writing the feedback.
:::

## Name of the person reviewing
[Miguel F. Marrero Tarrau]
## Name of the project being reviewed
[ FAIR-Battery]
[https://github.com/SanliFaez/FAIR-Battery#the-fair-battery-project]

**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
    - Write a minimum of 3 aspects you like about the project

### Give feedback on your hardware documentation

**Look for the following:**
- Is the project findable or accessible?
- Check if the readme 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

<!-- ### Give feedback about project openness
- Is the project findable or accessible?
- Is it clear what is the status of the project? (early stage, mature stage focused on documentation)
- Does the README provides the following:
    - Clear, straightforward, and to the point value proposition
    - Is there a bill of materials or a draft of a bill of materials
    - design files are published

* assembly instructions are published
* a bill of materials is published
* a contribution guide is published
* published files are shared in original format
* use of versioning control system
* use of issue management system
* All this information is published under a license allowing commercial reuse. -->