This course was focused on the idea to build from zero a machines which thanks to a specific mecchanism make a specific action. We conceive, design, and build an electromechanical machine that combines mechanisms, actuation, automation, and control logic.
## Week 1 — Mechanical Thinking & Early Prototyping
### Day 1 – Concept and System Definition
We started by defining the **behavioral logic** of the system before building anything.
**What we did:**
* Defined the concept: a “night creature” activated by darkness
* Identified system components (sensor → controller → actuator)
* Sketched functional diagrams
**Why:**\
This step follows a systems design principle:
> *Behavior must be defined before form.*
By deciding that light controls motion, we established:
* Input variable: light intensity
* Output: movement
* Control rule: threshold-based logic
This allowed us to design *purposefully*, not randomly.
### Day 2 – Mechanism Exploration
We explored how motion could be physically generated.
**What we did:**
* Tested different movement strategies
* Focused on gear-based transmission systems
* Evaluated rotation → oscillation → walking conversions
**Why:**\
A DC motor produces **continuous rotation**, but the robot required **expressive movement** (legs + antenna).
Gears were chosen because they:
* Transform speed and torque
* Allow synchronization of multiple parts
* Enable complex motion from a single motor
### Day 3 – Gear System Design
We designed and fabricated the internal mechanism.
**What we did:**
* Created a **gear train system**
* Combined 3D printed parts with aluminum beams
* Integrated supports inside a 3D printed hull
**Why:**\
The goal was to create a **compact mechanical architecture**:
* One motor → multiple moving parts
* Structural stability → reduced energy loss
* Modularity → easier iteration
### Day 4 – First Body Prototype
We began shaping the physical identity of the robot.
**What we did:**
* Built a basic structure (container-like body)
* Mounted internal mechanism
* Positioned legs and antenna
**Why:**\
The body is not just aesthetic—it affects:
* Center of mass
* Stability
* Motion efficiency
We needed to test how **mechanics + structure interact**.
### Day 5 – Walking Prototype (Proof of Concept)
We built a simplified walking version.
**What we did:**
* Constructed a small robot using cardboard and popsicle sticks
* Connected it to the control system
* Tested behavior:
* Light OFF → movement
* Light ON → stop
**Why:**\
This was a **rapid prototyping strategy**:
* Low-cost materials → fast iteration
* Focus on behavior, not precision
**Results:**
* Robot fell over (instability)
* Feet too small → poor support
* Movement too chaotic
**Conclusion:**\
Walking was technically possible, but not desirable for this project.
This is a critical design insight:
> Not all technically feasible solutions are conceptually appropriate.
## Week 2 — Electronics, Control & System Integration
### Day 6 – Sensor Integration
We implemented light sensing.
**What we did:**
* Connected phototransistor to Barduino
* Read analog values via Serial Monitor
**Why:**\
We needed **real-world data**, not assumptions.
Measured insight:
* Ambient light max ≈ 430
This led to defining a threshold (\~200), instead of guessing.
### Day 7 – Control Logic Implementation
We translated behavior into code.
**What we did:**
* Implemented threshold logic:
* > 200 → motor OFF
* <200 → motor ON
**Why:**\
This is a **binary control system**, simple but robust:
* No need for complex algorithms
* Easy to debug and adjust
This reflects a key engineering principle:
> Start simple, then increase complexity only if needed.
### Day 8 – First System Integration
We connected sensor → microcontroller → motor driver.
**What we did:**
* Tested full signal chain
* Observed system behavior
**Why:**\
Integration reveals problems invisible at component level.
### Day 9 – Debugging Session (Critical Learning Phase)
This was the most important technical day.
#### Issue 1 – Serial Monitor Failure
* Problem: no data output
* Fix: restart IDE
**Insight:**\
Always eliminate trivial software issues first.
#### Issue 2 – Incorrect Threshold
* Problem: threshold too high
* Fix: recalibrated using real sensor data
**Insight:**\
Design must be based on **measured reality**, not assumptions.
#### Issue 3 – Motor Not Activating
**Observed:**
* Code worked
* Driver LED responded
* Motor didn’t move
**Process:**
1. Checked wiring → correct
2. Replaced driver board → same issue
3. Tested with 5V → worked
**Conclusion:**
* Signal voltage (3.3V) was insufficient
We analyzed the MOSFET datasheet:
* Gate threshold: 2–4V
**Problem:**\
3.3V is unreliable in that range
**Solution options:**
* Use logic-level MOSFET (1–2.5V threshold)
* Or change switching strategy
We chose:\
→ **Relay module**
#### Relay Issues
* Relay clicked but didn’t stay ON
**Hypothesis:**\
Signal instability or voltage mismatch
**Tests:**
* Increased threshold → no improvement
* Switched relay → still failing
**Final discovery:**
* Most relays required 5V
* Our system outputs 3.3V
**Final solution:**\
→ Used **3.3V compatible relay (Seeed Studio Grove Relay v1.3)**
#### Key Engineering Insight
This phase demonstrates:
> Electrical compatibility is as important as logical correctness.
A system can be:
* logically correct
* mechanically functional
* but electrically incompatible
### Day 10 – Final Integration & Behavior Testing
**What we did:**
* Integrated all subsystems:
* Sensor
* Control logic
* Relay
* Motor + gears
* Tested real behavior in space
**Result:**
* Light ON → robot inactive
* Light OFF → robot activates and moves
#### System Logic (Final)
**Input:** Light intensity (phototransistor)\
**Processing:** Threshold comparison\
**Output:** Motor activation
Flow:
1. Read light value
2. Compare to threshold (200)
3. If below → activate motor
4. If above → stop motor
5. Repeat continuously
#### Mechanical System
* Single DC motor
* Gear transmission distributes motion
* Legs + antenna move simultaneously
**Design rationale:**
* One actuator → multiple expressions
* Reduced energy consumption
* Compact structure
#### Electronics
* Barduino (microcontroller)
* Phototransistor
* DC motor
* 3.3V relay
* Power bank
## Evolution & Future Improvements
From the poster and testing:
#### 1. Integrated Lighting
* Add LEDs for feedback
* Enhance interaction
#### 2. Refined Movement
* More controlled locomotion
* Possibly reduce randomness
#### 3. Structural Optimization
* Improve stability
* Better weight distribution
#### 4. Design Language
* More refined and minimal form
## Creature of the Night
*An Insomniac Robot Roaming the Fab Lab*
#### Project Overview
This project explores the design of an **autonomous electromechanical system** driven by environmental input. The robot behaves as a nocturnal creature: it activates in darkness and remains inactive in light.
The system integrates:
* **Sensing** → phototransistor (light detection)
* **Processing** → Barduino (microcontroller logic)
* **Actuation** → DC motor + gear mechanism
* **Control logic** → threshold-based decision system
The objective was to move from isolated components to a **coherent system**, where each part influences and constrains the others.
{% embed url="" %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://andrea-santis-organization.gitbook.io/andrea-santi-mdef-course/year-2/mechanics-design.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
