My electric bicycle conversion sits at the intersection of three different projects: making a drive assembly fit, getting its electronics talking, and turning that information into a useful display.
The public build archive brings those pieces together. It contains CAD assemblies, printable parts, firmware, and photos of the assembled bike. Each describes the same build from a different angle.
The model has to meet the frame
The mechanical side includes a large rear pulley, a motor mount, and seat-tube clamps. Fusion 360 assemblies describe how the parts relate to the bicycle, while STL exports turn individual shapes into something that can be fabricated.
A model can show the whole arrangement at once: where the motor sits, where the belt runs, and how the mounts attach. The photograph of the assembled bike adds another kind of evidence. The designed parts have to share space with the actual frame, wheel, wiring, and fasteners.
This is one reason the CAD and build photos belong together. Neither tells the whole story alone.
Give the controller a readable face
The display uses an ESP32 and a TFT screen. Its C++ sketch reads telemetry from a VESC motor controller over UART and draws battery voltage, power, and speed. The code also includes addressable LED control.
The data path is small enough to describe in one line:
Motor controller → UART → ESP32 → TFT display
That line crosses the boundary between the physical build and the software. The controller has measurements; the display gives those measurements a place the rider can see.
Keep the pieces together
For a build that spans disciplines, the useful artifact is the collection. The CAD explains the geometry. The exported parts make it easier to reproduce a component. The firmware explains what the electronics do. The photos show the assembled result.
The portfolio page includes the finished bike, a CAD view, and the dashboard prototype. The repository keeps the design and code alongside them.