Measuring overhead line geometry without track possession
A European national rail network’s electrification maintenance division measured contact wire height and stagger manually under live overhead wire. Brainy Neurals built a train-mounted stereo camera system that measures five geometry parameters as the train runs. Every reading is tagged to a mast and checked against tolerance on the live feed.
Overhead line geometry is simple to define and hard to measure. The wire has to sit at the right height and the right side-to-side offset, span after span.
Getting those numbers across a route used to mean stopping trains. It does not any more.
Prasiddh Mori, Edge AI Engineer.
He built the on-train inference path and the shared memory handoff between the two cameras.
Rushabh Shah, Senior AI Research Engineer.
He led the detection work and the calibration that turns pixels into millimeters.
Technically reviewed by Mitesh Patel, NVIDIA Certified AI Architect.
Published August 2026 · Last updated August 2026 · 11 min read
geometry measurements, single pass
track possessions per run
02 — Quick answers
The engagement at a glance
- What problem did this solve?
- Contact wire height, stagger and setting distance had to be measured by hand. That needed a track possession and put linemen under live overhead wire.
- What did Brainy Neurals build?
- Brainy Neurals built a train-mounted stereo camera system that measures overhead line geometry in motion. The build matches each reading to a mast and alerts on out-of-tolerance values.
- What changed after it went live?
- Five geometry measurements are now captured in a single pass at operational train speed. No track possession is needed, and every reading carries a mast name and coordinates.
- Who else could use this?
- Any operator measuring a long fixed asset from a moving vehicle. Highways, power transmission, port crane rails, airfield lighting, and overhead crane rails inside plants.
Engagement facts
| Field | Value |
|---|---|
| Industry | Rail electrification |
| Sub-vertical | Overhead line maintenance |
| Client | National rail network |
| Engagement | Build to deployment |
| Timeline | Multi-phase build |
| Capabilities | Computer vision, edge AI |
| Delivery model | Dedicated team |
03 — The problem
Why manual wire surveys kept failing
Overhead line geometry comes down to five numbers at every mast. Height, stagger, gradient, setting distance, and the gap between two contact wires where they overlap. Each one is a distance between two things a camera can already see.
That is why Brainy Neurals treated this as a computer vision development problem and not a sensor problem.
Where it broke
- 01A team walked the track with a gauge, mast by mast, under a live 25 kV wire.
- 02Getting them there meant a possession, so the line closed and trains did not run.
- 03Nothing at all was measured in motion, so nobody knew what the wire did at line speed.
- 04Readings were written against a mast identified by eye, and a wrong mast sends a crew to the wrong span.
- 05Two contact wires overlap at a crossover, and nobody can eyeball that gap while a train is moving. Two wires, one glance, no measurement.
V1 — The manual survey, and where it breaks
Work near a live overhead contact line runs under its own electrical safety regime, set out in EN 50488:2021.[1]
04 — The alternatives
Why the usual measurement methods stop short
Four approaches come up in every one of these conversations before anyone suggests cameras on a train.
| Approach | What it gets right | Where it stops | Who it still suits |
|---|---|---|---|
| Hand gauge on possession | Accurate where you stand | Line closed, people trackside | Spot checks after faults |
| Dedicated measurement vehicle | Purpose-built, precise | Booked months ahead | Periodic network surveys |
| Laser or lidar rig | Excellent geometry, wear too | Heavy to mount, costly | New-build acceptance |
| Video recorded, reviewed later | Cheap to fit | Nothing is measured | Evidence, not measurement |
| Cameras on a service train | Measures and tags running | Optics lose to weather | Routine network geometry |
The tolerance bands are not ours but come from design standards such as EN 50119:2020 and the operator’s own limits.[2]
05 — The approach
How we designed the measurement system
Brainy Neurals built a train-mounted geometry measurement system for a European national rail network’s electrification maintenance division. A pair of stereo cameras is mounted for full overhead coverage.
A detector finds the pantograph strip, the contact point, the registration arm and the mast in each frame. Height comes from a pixel scale calibrated against a known width already in the frame. Stagger is how far the contact point sits from the center of the strip.
Gradient is the height change between two consecutive masts, divided by the distance between them.
The two decisions that mattered
-
01
Cameras instead of a laser rig. Laser measurement is excellent, and we still said no to it. A laser rig is heavy, costly, and hard to fit to a train the operator already runs daily.
-
02
The operator’s mast list, not a map service. We load the operator’s own list and match by great-circle distance. But a hosted lookup is useless in a cutting with no signal.
Cameras, a position feed and a mast list only become a single usable number through sensor fusion.
“A laser rig is heavy, costly, and hard to fit to a train the operator already runs daily.”
Decision 01 · Sensing
V2 — The system and its boundaries
06 — The stack
The technology stack we used
Brainy Neurals built this stack around one constraint: every frame has to be processed while the train is still moving. That rules out anything that batches, anything that waits, and anything that needs a network.
The cameras, the detector, the on-device inference runtime and the logger all sit in one cabinet and run offline.
| Layer | What we used | Why | What we ruled out |
|---|---|---|---|
| Sensing | Two roof-mounted stereo cameras | Full width, one pass | One camera, two runs |
| Detection | A compact detection model | Every frame at line speed | Edge detection, beaten by sky |
| Inference | A GPU runtime, compiled | Predictable frame time | Training framework, too slow |
| Frame transport | Shared memory, event signalling | Neither camera waits | Queues, single-process capture |
| Positioning | A receiver on its own thread | Never blocks the frame loop | Reading it on the main loop |
| Reference data | The operator’s own mast list | Swapped on the train, offline | A hosted database, dead offline |
| Records | Live logs, one workbook after | A crash costs minutes | Writing only at the end |
The application layer is a desktop program the crew drives from the train, with every parameter editable during a run.
The modules compile to native binaries before deployment.
07 — The path of one reading
How one reading travels end to end
Here is a single reading, travelling from the wire to the line in the log file.
- 01The two roof cameras capture color and depth frames as the train runs, each in its own process.
- 02Each process writes its frames into shared memory and signals the main application, so neither camera waits.
- 03The detector finds the pantograph strip, the contact point, the registration arm and the mast.
- 04Geometry is computed from those positions, with stagger direction set by which side the mast crossed.
- 05The position feed is read on its own thread and the reading is matched to the nearest known mast.
- 06The value is checked against its tolerance band, color-coded on the live feed, and written to the log.
V3 — One reading, end to end
Same second, same span, same crew. A crew member watching the screen sees the color change before the mast is out of sight.
08 — What went wrong
The problems that nearly stopped us
Four things went wrong on this build, and one of them nearly ended it.
- P1
Two cameras, one machine, and the frames could not keep up. Naive capture blocked the pipeline, so one camera waited for the other and both dropped frames.
- P2
Stagger came out on the wrong side. Early runs logged left as right, because the sign depends on which way the mast crosses the frame.
- P3
The camera moved. The wire did not. Suspension travel shifted the pixel scale, so the same wire measured differently on two runs.
- P4
Daylight is worse than darkness. Published catenary vision work mostly runs at night against a dark sky, for good reason.[3] In daylight the wire competes with cloud, structures, and everything behind it.
Problems like these are why the build needed specialist engineers rather than a general software team.
09 — The fixes
How we fixed each of them
V4 — Each problem against its fix
- F1
Give each camera its own process. Frames go into shared memory, an event wakes the main application, and neither camera waits.
- F2
Correct the sign at the crossing. The system records which way each mast passes through the frame and sets stagger direction from that.
- F3
Calibrate against something already in the frame. A known width in view gives the pixel scale on every frame. Train height and a correction factor stay editable, so the crew can tune them on the day.
- F4
Stop fighting the background. The detector looks for the parts, not for the wire against the sky. Structure is easier to hold onto than a thin bright line.
This is why we run work like this under engagement models with a review point per phase.
10 — The outcome
What changed after the system went live
| What changed | Before | After |
|---|---|---|
| Possessions per measurement run | 1 | 0 |
| People trackside during a run | A gauge team, live wire | Nobody |
| Geometry types captured automatically | 0 | 5 |
| Mast identity on a reading | Written by eye | Matched with coordinates |
| Out-of-tolerance readings | Found in post-processing | Color-coded, live feed |
| Records to reconcile after | 5 | 1 |
Five overhead line geometry measurements are captured in one pass at operational train speed, with no possession taken.
Where two contact wires run together, the system measures their separation and flags anything under 500 mm (19.7 in).
V5 — The change, quantified
So the operational change is where the reading lands. A crew used to get numbers and a mast name somebody wrote down by hand. They now get a mast name, a coordinate pair, and a color that says go look.
We have not published a possession-hours figure. The client has not reported one, and we do not print numbers we have not measured.
11 — In production
What is running on the network today
The system runs today on the operator’s own inspection train, on live sections of the network. A crew sets train height, pantograph width and the camera offset before a run. They upload the mast list for the section and start recording.
Both camera feeds are on screen with the measurement tables beside them. Out-of-tolerance readings show color while the span is still visible through the window. At the end of a run the operator exports one workbook.
Brainy Neurals ships work like this under transportation and rail infrastructure, where the asset never stops.
12 — Lessons
What we would do differently next time
- 01
Fix the direction convention on day one. We found the stagger sign problem in the field when it should have been a bench test.
- 02
Write the log before you trust the pipeline. A run that crashes at minute fifty and saves nothing is a wasted possession you did not need to waste.
- 03
Let the crew change the numbers. Every constant we hard-coded came back as a change request within a month. But the editable ones never did.
- 04
Ask for the mast list first. It arrived late, in a format nobody expected, and it set the whole positioning design.
Unrelated: the crew called overlap spans the tricky bits for the whole project, and we started calling them that too.
“A run that crashes at minute fifty and saves nothing is a wasted possession you did not need to waste.”
Lesson 02 · Logging
13 — The pattern
Where else this measurement pattern fits
Geometry monitoring in motion measures a fixed linear asset from a moving vehicle, tagging each reading to its structure.
Different markets name the same asset differently. UK engineers say overhead line equipment, or OLE. North America says catenary or overhead contact system (OCS), and Australia says overhead wiring.
| Industry | The equivalent problem | What changes in the build |
|---|---|---|
| Highways and bridges | Clearance and sign geometry | Mast list becomes chainage |
| Power transmission | Conductor sag along a corridor | Masts become towers, or drones |
| Ports and terminals | Crane rail alignment | Shorter runs, same tagging |
| Airports | Marking geometry at night | Tolerances from the airfield standard |
| Manufacturing plants | Crane rail and monorail geometry | Positioning goes indoor |
Porting it is mostly reference-data work, because the geometry barely moves.
And the same shape shows up inside AI for manufacturing plants that run overhead crane rail. It shows up again across civil infrastructure, where clearance is surveyed from a vehicle.
14 — Before you commit
Questions buyers ask before they commit
01What is contact wire stagger, and why is it measured? +
Stagger is how far the contact wire sits to one side of the track center. It is deliberate, and the wire zig-zags so the pantograph carbon wears evenly.
02Can overhead line geometry be measured without closing the line? +
Yes, a camera system mounted on a train already in service measures while the train runs. No possession is needed for the measurement.
03Does a camera system work at night or in rain? +
Cameras are optical, so heavy rain, fog and low light degrade them. Ultrasonic and laser systems handle some of that better, so in practice runs get scheduled around the weather.
04How is a reading tied to a specific mast? +
A position feed runs alongside the measurement, and each reading is matched to the nearest mast in the operator’s list. The log entry then carries that mast name and its coordinates.
05How long does a system like this take to build? +
Longer than a proof of concept and shorter than a platform rebuild. The measurement proves out quickly, and field calibration, tolerance work and reporting are where the months go.
06What does it cost to repeat this on another network? +
It depends on how much is reused, and the geometry and detection carry over. The mounting, the calibration and the reference-data format are per-network work, and that’s where the estimate moves. An AI readiness assessment is the cheapest way to find out which side you are on.
07Do you need a dedicated inspection train? +
No, the system was designed for a train the operator already runs, and a dedicated vehicle is not required.
08Is catenary the same as an overhead line? +
Yes. Catenary, overhead line equipment (OLE), overhead contact system (OCS) and overhead wiring all name the same asset. The markets differ, the wire does not. This system measures the same five geometry parameters whichever name a network uses.
15 — Capabilities
The services this build came from
Computer vision development
A camera frame into millimeters
Explore →Edge AI and embedded
Every frame, inside a cabinet
Explore →Video analytics
Live feeds, alerts on the stream
Explore →Robotics and hardware
Mounting, sensor fusion, vehicle-mounted plumbing
Explore →POC and MVP development
The version that proves the measurement
Explore →AI in logistics and rail
Long, linear assets, expensive to close
Explore →Most projects start earlier, with AI consulting, an AI readiness assessment, or a scoped proof of concept. The industries hub lists every sector we build for.
16 — Related builds
Other builds with the same shape
Two other Brainy Neurals builds are published in full, and both are healthcare rather than rail.
Both share the same shape. A judgment the client used to make by hand, moved into software that runs every day.








