- Course
- ZP8 — Mechatronic System Design, Institute of Machine and Industrial Design, BUT FME
- Team
- 5 people, team no. 02
- Role
- Team leader
- Software
- InventorSolidWorksPTC MathcadExcel
- Control
- 2× ESP32 (C++)
- Stages
- PDR → CDR → FAR, spring 2026
- Result
- 1st place out of five teams
Introduction
In the ZP8 course at the Institute of Machine and Industrial Design, BUT FME, we built a scale model of a lift in five-person teams. The car weighs 2.5 kg and travels on a track longer than 130 cm; a winch pulls it on a rope at 0.2 m/s. Our task was to design what saves it if the rope snaps: an active brake, a passive brake and a buffer at the bottom of the shaft.
During the tests, the instructor cuts the rope while the car is moving. The brake has to engage no later than at a speed 30% above nominal, and stop the car with a deceleration of at most 2 g. In a power cut, the system must go to a safe state on its own. And if the car falls from a height so small that its speed doesn't reach the brake, the buffer must catch it.
The project ran like a real commission in three stages: preliminary design review (PDR), critical design review (CDR) and final acceptance review (FAR). Each ended with a technical report in which every decision had to be backed by a calculation.
Two NEMA stepper motors wind the car onto a drum through a belt drive. It's controlled with buttons for up, down, stop, power on and release brake. Control is handled by two ESP32 boards, which we bought in addition: one at the drive and one in the car, communicating via Bluetooth.
The car has an active brake on one side and a passive brake on the other. We didn't do two and two on purpose, for synchronisation and a simpler car construction. A fall is detected by an MPU-6050 accelerometer together with an ultrasonic distance sensor. The active brake is a wooden block with rubber glued on, on a lead screw: the servo turns the screw and the block is pressed against the aluminium profile.
The passive brake works the other way round. A strong pre-tensioned spring is held by a latch, and the latch is held by a solenoid as long as it's powered. As soon as the power drops, the latch releases and the spring pushes the rubberised block against the profile. So the safe state isn't a mode the system switches into, but a state it falls into by itself.
For a fall from a small height there is a block of polyurethane foam under the car, and at the bottom of the shaft a scissor-type buffer with a spring. Mathcad calculations gave brake activation at 0.26 m/s and a braking deceleration of 1.8 g, below the 2 g limit.
I led the whole project as team leader.
Gallery
01Lift structure — design and built prototype
02Car with brakes, electronics and energy chain
03Electronics in the car: ESP32, voltage converter and relays
04Active brake: the servo turns the lead screw and presses the rubberised block against the profile
05Passive brake: a solenoid holds the latch of a pre-tensioned spring; without power it releases
06Energy chain carries the cables to the car along the whole track
07Winding mechanism — two stepper motors wind the rope onto the drum and lift the car. The motors sit in printed housings and turn the drum via a toothed belt
08Scissor buffer at the bottom of the shaft with an ultrasonic sensor
09Mechatronic system schematic from the preliminary design — drive, sensing, control and both brake branches together
10Overload and rope tension during an active brake test. Left: one trace with all three phases — steady travel, hook release and brake grip with a peak of 3.09 g. Right: comparison of all braking tests against the 2 g limit
11Tuning and measuring accelerometer values
12Testing the brake functions
In motion
Result
The brakes stopped the car in all tests: a fall while moving up and down, a power loss, wet profiles, and with 2 and 4 kg of extra load. Out of five teams we finished first, and we met the limits best on the active brake, the passive brake and the buffer.
It wasn't without errors. On the morning of the tests one ESP32 burned out. We got a replacement in time, but in the rush we didn't check the calibration of the active brake. So with an empty car the deceleration jumped to 3.09 g instead of the calculated 1.8 g. With 2 kg extra the brake stopped at 1.64 g, within the limit. After the official tests we calibrated the brake, and the check measurement then matched the model.
The project taught me most about leading people. Organising even a five-person team isn't simple, even when you know each other. Each part needs clear boundaries and deadlines; you can't just give everyone free rein. A Gantt chart and milestones aren't bureaucracy, but a way for everyone to know what they have to deliver and when.
Where it’s heading
Agree on the tools at the start. At our modeller's request we worked in Inventor, although most of the team was better at SolidWorks. When something had to be finished quickly, it was made in SolidWorks and then awkwardly converted and assembled into the Inventor assembly.
Keep spare electronics and always recheck the calibration before tests. For the next iteration we recommended a flexible pad in the brake mechanism to damp the impact of clamping, and a spare ESP32.
Specifications
- place out of five teams
- g — with 2 kg extra, below the 2 g limit
- kg extra and the car still stopped
- ms — reaction to free fall
- Car
- 2.5 kg ± 0.5 kg, track over 130 cm
- Drive
- 2× NEMA stepper motor, belt drive to the drum
- Control
- 2× ESP32 on perfboard, linked via Bluetooth
- Fall detection
- MPU-6050 accelerometer + ultrasonic distance sensor
- Active brake
- Servo and M6 lead screw, rubberised block
- Passive brake
- Pre-tensioned spring, latch held by a solenoid
- Damping
- Scissor mechanism with spring at the bottom, PU foam under the car
- Nominal speed
- 0.2 m/s ± 0.05
- Brake activation
- 0.26 m/s (+30%)
- Braking deceleration (model)
- 1.8 g
- Overload limit
- 2 g
- Measurement during tests
- Load cell in the rope + three-axis accelerometer
What I learned
01
A brake that doesn't need power
The active brake is only as reliable as the electronics controlling it. So the passive one is built the other way round: the spring is permanently pre-tensioned and the solenoid holds it only while powered. When the power disappears, the brake grips by itself. In tests we verified this by cutting the power supply.
02
Burned ESP32 on test day
The morning before the tests, one of the two ESP32s died. We got a replacement and made the tests, but in the rush we forgot to check the calibration of the active brake. That very calibration was behind the 3.09 g overload on the empty car.
03
The model assumed even braking
The calculation assumed constant deceleration. Measurement showed a short sharp shock, after which the brake partly slips along the profile. On wet profiles the peak was lower, 1.78 g, but the braking distance was longer.
04
Two programs in one team
The model was made in Inventor, but most of the team was faster in SolidWorks. Parts finished at the last moment then had to be converted and assembled back into the assembly. Next time I'll agree on the tool at the very start.