T. BHAIJI
Index SHEET 01 / 06

Overhead EV charging, cable retraction control

Suspending the charging dispenser on a gantry above the truck instead of beside it reclaims about 18.5% of the footprint per bay. That only works if the cable stows itself. I led the team that made it, and designed the control system: a 10 m, 33.6 kg liquid-cooled cable retracted in under 30 seconds, held in place when the power fails.

TRUCK · CHARGING BAYCONTROLESP322 × RS-485, isolated24 V, battery-backed 10 m cable · 3.36 kg/m self-locking worm gearbox dispenser r 50 mm retracts in 30 s 33.6 kgcable mass330 Nholding force16.5 N·mtorque at drum34 N·mmotor · 2× margin60 rpmoutput speed19 Acurrent limit
Elevation of the retraction system, with the drive sizing chain.
Sheet
01 of 06
Title
Overhead EV charging, cable retraction control
Client
Milence
Pan-European high-power truck charging network
Drawn
Feb 2026 – Jul 2026
Work done
System architecture · Control electronics · Drive sizing
Project type
Group project, 7 people, 3 disciplines
My role
Team Lead, control electronics, power, interfaces
Status
FOR REVIEWdesign and simulation, no prototype built
ESP32 · RS-485 · Modbus RTU · MATLAB · Simulink · Stateflow · EasyEDA

Nobody coils 34 kg of liquid-cooled cable by hand

At the indicative rating, around 400 kW and 500 A DC, the cable is liquid-cooled, stiff, and weighs 3.36 kg per metre. Over a 10 m run that is nearly 34 kg of awkward, expensive cable to retrieve after every session.

So in practice it does not get retrieved. Drivers leave cables hanging, which risks damaging both the charging equipment and vehicle roofs, and leaves an obstruction in a working truck bay.

Milence had already fixed the mechanical concept: a garage-door arrangement running the cable through rollers in an overhead track, kept electrically continuous with no high-voltage joints in the moving section. What did not exist was the layer that makes it a system: the drive, the interlock guaranteeing the cable cannot move during a live charging session, the state a driver can read, and the interface the network operator controls it through.

Sized from a model I had to build myself

  1. The mechanical team could not deliver drum geometry, cable mass or track friction in time, so I derived them. A MATLAB model gave a 50 mm drum radius, about 330 N of cable load, therefore 16.5 N·m of holding torque at the drum and roughly 60 rpm to move 10 m within 30 seconds. Every drive decision downstream rests on those four numbers.
  2. Hold on power loss is the requirement that shaped the design. A plain geared motor needs either a continuously powered brake or a mechanical one, which costs more and adds another failure mode on a suspended load. A self-locking worm gearbox holds by geometry, with no power at all. That single requirement eliminated the BLDC and stepper branches outright: BLDC needs a brake or holding current, a stepper holds only on detent torque.
  3. I specified an off-the-shelf programmable DC controller rather than a discrete H-bridge. One qualified module gives bidirectional control, soft start and stop, adjustable current limiting and dynamic braking over RS-485 Modbus RTU, and it hands the firmware current and temperature feedback I would otherwise have had to build. Running current works out at 10.5 A, with the limit set to 19 A: above worst-case acceleration, below the driver's 20 A ceiling.
  4. The end-of-travel stop does not depend on firmware. Two normally-closed limit switches are read by the controller, but they are also wired in a series loop straight into the driver's emergency-stop input. If the firmware hangs, the switches still stop the drive.
  5. The backend link is an isolated RS-485 Modbus channel with the controller as slave: a command register the operator writes retract, deploy or stop into, and a status register it reads. Charging state needs no separate input, because the controller reads the charger directly, which is also what lets the status light show charging-locked.
  6. When the physical build was cancelled mid-project, I re-scoped the deliverable with my assessor from a bench-tested board to a completed PCB design verified by simulation, and built a MATLAB and Simulink model (motor, gearbox, drum, cable load, and a Stateflow chart for the deploy, hold and retract sequence) to check the behaviour that does not need hardware.
Drive topology, four branches compared
TopologyHolds on power lossVerdict
DC geared motor, worm gearboxSelf-locking by geometrySelected. Direct match for a 24 V, 10.5 A retraction drive
BLDC with FOC driverNeeds a brake or holding currentRejected. Extra failure mode, and FOC tuning is unjustified here
StepperDetent torque onlyRejected. Resonance and stall risk under variable load
AC induction with VFDNeeds a brakeRejected. Oversized for 24 V at this power
Drive sizing, derived from the MATLAB model
Cable mass33.6 kg3.36 kg/m over 10 m
Holding force330 Ncable weight
Drum radius50 mmfrom the model, later confirmed
Holding torque at drum16.5 N·mforce × radius
Output speed60 rpm10 m within 30 s
Motor rated output34 N·m2× margin against a 20% requirement
Running current10.5 Aat 24 V
Current limit19 Abelow the 20 A driver maximum

Every must-have met, in design and simulation

Outcome
2×torque margin. 34 N·m against 16.5 N·m, where 20% was required
30 sretraction for a 10 m cable, confirmed in the Simulink model
7people led across electrical, mechanical and industrial design
2open client questions closed: status-light scope, backend protocol

Simulation confirmed the control behaviour across a full cycle: the cable deploys, holds stationary while a charging session is active with the interlock preventing motion, then retracts once the session ends. Armature current stayed inside the trip limits, with the expected higher draw during acceleration. Hold-on-power-loss is met by selection rather than simulation, because the worm gearbox is self-locking.

Two client questions that had been open for weeks closed once I documented them formally instead of chasing them informally. The status light now reflects charger state directly, and the backend interface became RS-485 Modbus rather than dry contacts.

SCOPE AND LIMITATIONSThe prototype build was cancelled partway through when the mechanical and industrial-design teams could not deliver an integratable assembly in time. Verification is a completed PCB design plus simulation, so there is no bench-tested board. The model also ran on indicative motor constants from a generic 24 V motor, not the datasheet values of the gearmotor I finally selected, so it validates the shape of the response and the control behaviour, not the exact numbers of the final drive. Re-running it against the real datasheet and the configured 19 A trip is the first recommendation in my report.

Book a call

Happy to talk about a graduation internship, a vacancy, or a project you want a second opinion on. Twenty minutes is usually enough to work out whether it is worth a longer conversation.

Typical length
20 to 30 minutes
Time zone
Central European Time, Arnhem
Languages
English, Hindi
Usually free
Weekday evenings and most of the weekend

Looking for a graduation internship from February 2027.

Power electronics, embedded hardware, renewable energy or power systems. I am equally happy writing the firmware and tooling around them. Based in Arnhem, open to relocating in the Netherlands.

Based in
Arnhem, Netherlands
Available
Graduation internship from Feb 2027

© 2026 Tanishq Bhaiji · Arnhem tanishqbhaiji42@gmail.com LinkedIn CV (PDF)