Wheel alignment and headlight aiming at end of line
- Sector
- Automotive manufacturing
- Period
- 2011–2012
- Role
- Developer, measurement and control software
- Stack
- C++ · Siemens PLC · Machine vision · Sensor acquisition · ASAM · Linux
Situation
At the end of a vehicle assembly line, two things must be set correctly on every single unit before it leaves. The wheels have to sit at the right geometry — toe, camber, caster, steering axis inclination — or the vehicle pulls, wears its tyres unevenly and fails inspection. And the headlights have to be aimed within tolerance, or it is not road legal.
Both are physical adjustments made by a person turning something. The software's job is to measure accurately, tell the operator which way to turn and how far, and recognise the moment the value comes inside tolerance — while the line keeps moving and each vehicle is a different variant with different target values.
What I built
Measurement and control software for two end-of-line stations, on a line building a pickup model.
Identify the vehicle first. The stand reads the vehicle's identity from its barcode as it arrives and looks up the target values for that specific variant. Nothing is measured against a generic tolerance; every reading is judged against what that vehicle is supposed to be.
Measure the wheel geometry. Toe, camber, caster and steering axis inclination come from a set of sensors and camera-based targets on the stand, with ride height measured alongside. The readings are corrected into a consistent vehicle coordinate frame — the geometry maths is the part where being casually wrong is easy and invisible.
Guide the adjustment live. As the operator turns the track rod, the displayed value moves with them and shows tolerance in real time. That feedback loop is the actual product: a measurement that arrives after the adjustment is useless.
Aim the headlights. The second station measures the beam pattern with a camera, works out where the cut-off line actually falls against where it should, and guides the correction the same way.
Fit into the plant. A PLC sequences the stand and interlocks it with the conveyor. Results are printed for the vehicle, logged, and exported in the industry-standard measurement format the plant's quality systems already consume, so the data lands where quality engineering is already looking.
Internally this is around twenty cooperating processes, one per device or responsibility — PLC comms, barcode, framegrabber, each sensor family, printing, logging — rather than one program that talks to everything. On a stand where any individual device can be swapped, be down, or be replaced by a different vendor's unit, that separation is what makes the system maintainable over a production run's lifetime.
Outcome
Every vehicle leaves with geometry and headlight aim measured against its own specification, recorded, and traceable.
This is the work that taught me where the value of software actually sits in a plant. The measurement is arithmetic. The difficulty is cycle time, tolerances that are real, hardware that is heterogeneous by nature, and an operator who needs the answer now, not after a round trip to a server.