MUVMI Regen-Brake Software & Ergonomics Hardware Integration

Two Tracks, One Vehicle

The same MUVMI tuk-tuk had two separate problems, so the team ran two engineering tracks in parallel. As team lead I focused on the software side, also worked hands-on on the hardware build, and pulled both tracks together into one weekly deliverable. The project followed a four-phase design process: Define Problem, Conceptual Design, Detail Design, Result.

MUVMI's Two Problems

Information was gathered from MUVMI staff, MUVMI drivers, and literature research, working directly with the company's engineers on a vehicle in service. Two problems surfaced.

Joint	Current angle	Preferred angle	Gap
Knee	100°	110°	+10°
Ankle	75°	85°	+10°

Concept & Sensor Choice

Ergonomics concept: the pedal is too steep, so redesign the brake lever to reduce the pedal angle, and add a rest pedal so the foot has a resting position while waiting.

Regen concept: change the sensor to an analog output (so regeneration responds continuously to how hard the driver brakes), design a mounting for it, and design the regenerative function. The sensor choice was made on a clear trade-off against the 200 ฿ budget:

Sensor option	Measures	Price	Integration	Decision
Angular position sensor	Angle of brake lever	Lower (105 ฿)	Needs a mounting solution	✓ Chosen
Pressure sensor	Pressure of brake cylinder	Higher	Easy to adapt to previous sensor	Not chosen

Hardware · Final Designs

Each hardware part went through pass/fail screening of four alternatives in Fusion 360 before the final design. My teammates led the design; I worked the build and installation with them.

Design screening picked alternative 4 in every case (the fourth iteration resolved earlier fail reasons):

Part	Alternatives	Final	Why it passed
Brake lever	4 screened · 3 fail	design 4	Added pivot range, clears the frame and front body
Rest pedal	4 screened · 3 fail	design 4	Compact, easy to install, small adjustable angle
Sensor mount	4 screened · 3 fail	design 4	Enough travel for sensor resolution, lower cost

Software · Regen Control Logic

With an analog signal available, the regenerative function could be shaped properly. The braking case of interest is Partial and Full braking (the team excluded the slow "small brake" case), and regeneration is allowed only when battery state of charge is below 90%.

Brake type	Brake duration	Use case	In scope
Small brake	10 – 15 s	Remove hand accelerator only	Out of scope
Partial brake	5 – 10 s	Normal urban driving	✓
Full brake	3 – 5 s	Emergency	✓

Serial vs Parallel regeneration. A Parallel scheme was chosen via an evaluation table: it is simpler, brakes for a shorter duration, adapts to the current design, and is cheaper, at the cost of slightly lower peak efficiency.

Criterion	Serial regeneration	Parallel regeneration
Efficiency (of input power)	0.15 – 0.30	0.09 – 0.18
Mechanism	Complex	Simple
Braking duration	Longer	Shorter
Modify time	New design required	Adapts to current design
Cost	Expensive	Cheap
	✗	✓ Chosen

The regenerative response is then banded by speed, and each band has a Comfort and an Efficiency mode (Comfort caps regen at 90% of max, Efficiency at 100%). These are the control functions I designed and plotted in MATLAB:

Safety was checked with a vehicle-dynamics model and a braking-ratio / wheel-lock analysis. The front/rear split was fixed at K_bf = 0.25 so the required braking force never crosses the wheel-lock limit, and the maximum regenerative force (2,850 N) is sufficient at every operating point.

Full braking-dynamics derivation · equations of motion

The full set of equations behind the load transfer, wheel-lock limits and braking-ratio graph, transcribed from the team's MATLAB derivation. Symbols: M_t total mass, ℓ wheelbase, h CG height, x₁/x₂ CG-to-front/rear axle, x₃ aero height, μ tyre friction, V speed. a_x is the signed acceleration (negative while braking); the deceleration magnitude is D_x = −a_x = U/t_brake.

A · Load transfer (normal forces)

Moments about the front contact (ΣM_f = 0) and the rear contact (ΣM_r = 0):

N_r = ( F_R,Air·x₃ + M_t·g·x₁ + M_t·a_x·h ) / ℓ
N_f = ( M_t·g·x₂ − F_R,Air·x₃ − M_t·a_x·h ) / ℓ
⇒ N_f = W_fs + W_d ,   N_r = W_rs − W_d
W_d = M_t·D_x·h/ℓ − F_R,Air·x₃/ℓ   (forward load transfer)

While braking D_x > 0, so W_d > 0: load shifts to the front, N_f rises and N_r falls, which is physically correct.

B · Longitudinal equation (total brake force)

F_b + F_Roll + F_R,Air = M_t·D_x ,   D_x = U / t_brake
⇒ F_b = M_t·D_x − C_roll·M_t·g − ½·ρ_air·C_w·A_f·V²

C · Wheel-lock limits (max tyre force = μN)

Front lock: F_xm,f = μ( W_fs + (h/ℓ)F_Roll + ((h−x₃)/ℓ)F_R,Air + (h/ℓ)F_xr ) / ( 1 − μh/ℓ )
Rear lock:   F_xm,r = μ( W_rs − (h/ℓ)F_Roll + ((x₃−h)/ℓ)F_R,Air − (h/ℓ)F_xf ) / ( 1 + μh/ℓ )

D · Braking ratio

D_x = ( F_xf + F_xr ) / M_t   (aero & rolling neglected for the graph)
F_xf / F_xr = k_bf / (1−k_bf) = 1/3   ⇒ k_bf = 0.25, k_br = 0.75 checked

E · The six plotted braking lines (F_xf vs F_xr, N)

1 F_xf = −F_xr + 2,000.16   max D_x · partial brake
2 F_xf = −F_xr + 3,333.60   max D_x · full brake
3 F_xf = −F_xr + 2,856.96   general case
4 F_xm,f = 0.1427·F_xr + 1,687.5   front wheel lock
5 F_xf = −7.01·F_xm,r + 21,055   rear wheel lock
6 F_xf = (1/3)·F_xr   current ratio · k_bf 0.25

F · Decelerations at 50 km/h verified

U = 50 km/h = 50·5/18 = 13.889 m/s ,   D_x = U / t
Partial: t ≈ 5 s ⇒ D_x = 2.778 m/s²
Full:     t ≈ 3 s ⇒ D_x = 4.63 m/s²
General: t ≈ 4 s ⇒ D_x = 3.472 m/s²
Comfort time: 24 = (U/2)·t ⇒ t = 3.456 s

G · Max regenerative force verified

F_max,regen = (Gear Ratio · T_max,regen) / R_r = (10.26 × 75) / 0.270 = 2,850 N
sufficient at every operating point

My verification

I re-derived and confirmed the kinematic results: the decelerations D_x = U/t (2.778 / 4.63 / 3.472 m/s²), the comfort brake time (3.456 s), the split k_bf = 0.25 / k_br = 0.75 from the 1:3 ratio, the max regen force 2,850 N, and the geometry x₁ + x₂ = ℓ (1.95 + 1.5 = 3.45 m). The load-transfer and wheel-lock equations are physically consistent: braking shifts load forward, N_f up and N_r down.

The specific intercepts and slopes of the six plotted lines (2,000.16 ; 0.1427 ; −7.01 ; …) come from substituting the full parameter set into the coupled equations in MATLAB, so I transcribed them as computed rather than re-deriving each constant by hand. Share the MATLAB script and I can reproduce every line value step by step.

MATLAB Simulink · Simulation Results

The braking-ratio analysis and the regenerative-torque sizing were built and plotted in MATLAB Simulink. These outputs set the front/rear split, sized the regenerative force, and confirmed the wheel-lock margins across speeds before the on-vehicle test.

On-Vehicle Test & Calibration

We built the prototype, mounted the angular sensor, and tested live on the vehicle at the I'm Park underground lot (Suan Luang), logging battery voltage from real regeneration at 10 and 20 km/h, with regen open (90%) and closed (5%). From the logged data I derived a calibration function mapping the raw sensor reading to brake angle:

Regen Result · Energy Recovered

With the analog sensor and the speed-banded functions, the recovered regenerative energy rose sharply, averaged over 3 tests at each speed:

Speed	Before (avg)	After (avg)	Change
10 km/h	522.23 J	1,674.90 J	+220.72%
20 km/h	4,085.24 J	5,452.77 J	+33.48%

Field Test · Regen Energy by Braking Style

We then ran a structured on-vehicle study varying speed, regen level, brake rate, and braking style (with 2 and 3 passengers), logging the energy, the recovered regenerative energy, and the brake distance for each run. Representative runs (3 passengers):

Speed	Braking style	Regen energy (Ws)	Brake distance (m)
25 km/h	Release accelerator (no brake pedal)	13,682	29.8
25 km/h	Brake + 60% regen	3,879	5.9
25 km/h	Full-force brake (no regen)	2,059	6.0
50 km/h	Release accelerator (no brake pedal)	64,683	48.6
50 km/h	Brake + 90% regen	36,644	33.2
50 km/h	Brake + 60% regen · rate 0.5	14,484	17.6
50 km/h	Brake + 60% regen · rate 1.5	8,716	16.7

Ws = watt-seconds (joules) of recovered energy. Higher numbers recover more energy.

Ergonomics Result · Validated On the Road

The new lever and rest pedal were installed and driven for two weeks by a real MUVMI driver. The measured angles landed on target:

Joint	Current	Preferred (target)	New
Knee angle	100°	110°	108°
Ankle angle	75°	85°	86°

Cost & Value

The standout of the project is how little the hardware cost. Both upgrades were delivered with cheap, off-the-shelf parts rather than expensive proprietary EV modules, and the sensor came in under the 200 ฿ objective.

Summary of Improvement

Aspect	Before	After
Regen efficiency	Only on release of hand accelerator	On release of accelerator and brake pedal
Sensor signal	Digital output	Analog output
Driving position	Not optimized	Optimized ergonomics

Tooling · Software Stack

Future Work

Business Model Canvas

Beyond the engineering, the team framed the work as a venture: a consult, design, and maintenance startup for automobile solutions.

Project Workflow & Schedule

How the eight months (August 2020 to March 2021) were organised so the software and hardware tracks could run in parallel, while I kept a dedicated lane every week to consolidate both tracks into one deliverable and own the weekly submission.

Team Lead & My Contribution

Skills & Tools

MUVMI, in Motion

Eight months, two engineering tracks, one in-service electric tuk-tuk. This closing film walks through the whole project: the regenerative-brake software I co-led (analog angular sensor, speed-banded regen functions, MATLAB Simulink), the driver-ergonomics hardware the team built and installed, and the live on-vehicle testing at I'm Park that logged the voltage and proved the energy recovery. A roughly 660 THB build, delivered by a five-person team I led, and mentor-voted Top 3 of 16+ mechanical-design projects.