Hello again, and welcome to this week’s update on our project Hydrawlics!
This week, we focused on solidifying the foundation of our project. While most of the work was done collaboratively rather than individually, we’ve made important progress on planning, requirements, and starting the development of our MVP.
Roles
This week we distributed team roles to clarify responsibilities and ownership within the project. The table below shows an overview:
| Name | Roles |
| Fredrik | Mechanical Engineer, Lead |
| Erling | Mechanical Engineer |
| Emory | Software Engineer |
| Lisa | Software Engineer, Blogmaster |
| Syver | Software Engineer, Developer Coordinator |
Defining MVP
The Minimal Viable Product (MVP) should give us a clear and achievable milestone that ties together both mechanical and software elements. This is how we defined our Minimum Viable Product (MVP):
A hydraulic-driven single joint (1 DoF) mechanical arm controlled by a syringe system. The syringe is actuated by a servo and Arduino, and at the end of the arm we attach a marker. Movement is demonstrated through a repeated back-and-fourth motion. Alongside this, a proto-GUI is under development, showcasing an early version of image processing.
We have divided the main MVP system components into individual responsibilities;
- Fredrik – Make the actuator system, and a prototype end effector
- Erling – Design a simple joint mechanism using syringe hydraulics
- Emory – Research and put together a proof-of-concept image edge detection algorithm in Python.
- Lisa – Source parts and code together the C++ Arduino firmware demonstrating the motion of the hydraulic arm.
- Syver – Implement a baseline Python Flask webserver for collecting and serving user content, serving as the system interface.
This kickstarts a more individual workflow. A more detailed post from each contributor will be posted next week!
Project planning – Gantt chart
We created a Gantt chart that shows the timeline with sprints and milestones for the different tasks in the project.
Requirements & user stories
We have put a lot of effort into making user stories and requirements for our project this week. This is to ensure we are all on the same page of what is important in our development process, and why it’s important. These are organized in Notion, making it easy for us to see which user stories are attached to which requirements, and vice versa. The user stories clearly show the correlating requirements, giving the requirement context. The user stories also include individual acceptance criteria, meant to be used as a sanity check at the later stages of the project. All the requirements have been prioritized based on their significance to our project success.
High level design
This is an preliminary high level design showing our components!
That’s all for now, see you next week!