A LiDAR mounted above the loading track identifies, counts and locates every freight wagon as it stops — six lid centerpoints, wagon number, Roboterwagen flag, all from a single scan in under two seconds. Drives the automated loading sequence, writes a per-wagon material log into ERP/MES. This is our shipped Bahnwagon pipeline, in production today.
Railcar detection AI is a perception pipeline that ingests a single 3D-LiDAR scan of a freight wagon at the loading station and returns the wagon position, its identifying features (lid count, lid centerpoints, the leading roboterwagen if present) and a wagon-number assignment — drives automated loading workflows and per-wagon material logs into ERP.
The pain shows up at every industrial plant that loads bulk material onto rail — salt mines, scrap recycling, bulk yards, fertiliser depots. Wagons roll under the loading equipment one by one, and the loading control system needs to know precisely where each wagon is, how many compartments it has, and when it is full. Today operators do this visually: peering over the rail, eyeballing lid positions, ticking wagons off on a clipboard. It is slow, error-prone and unforgiving — the wrong lid gets loaded, the wrong wagon gets billed, the ERP entry does not match the actual yard state, and the shift loses an hour reconciling paper against reality.
Our approach is one LiDAR mounted above the loading track. As each wagon stops, the sensor captures a single scan; a six-stage stateless geometric pipeline — ground crop → deck-Z estimation → height-band masking → lid clustering → wagon-bounds → tracker state machine — returns the wagon's exact 3D position, all lid centerpoints, the leading Roboterwagen if it is in frame, and a sequence number. The geometry stages are pure NumPy and scipy in the prototype and port cleanly to C++/C# for the final plant controller. Mean centroid error stays under 5 cm against hand-labelled ground truth; the whole scan is processed in under two seconds on commodity hardware.
This engagement descends from Industrial Perception AI and is the one use case where we already shipped — the Bahnwagon-Deckelerkennung pipeline runs in production at a north-German recycling and mining operation. The same geometric approach works whether the wagon carries rock, salt, scrap or grain; only the calibration constants in config.yaml change, no model retraining required.
The Bahnwagon-Deckelerkennung pipeline is in production today — six lid centroids, sub-5 cm error, two-second response, Electron + Vue 3 + Three.js operator UI.
One LiDAR mounted above the loading track, IP65+ housing, scans every wagon as it stops at the loading position. No camera required, no second sensor to calibrate. Runs through dust, snow, night light and the steam that comes off warm bulk material. One scan per wagon stop, written to local storage with a per-wagon UUID for audit trail.
Pure NumPy and scipy in the Python prototype, ports straight to C++/C# for the plant controller. Six stateless stages: ground crop, deck-Z estimation, height-band masking, lid clustering, wagon-bounds, tracker state machine. Runs in under two seconds on commodity hardware. No GPU required, no model retraining when the wagon class changes — calibration lives in config.yaml.
Wagon ID, lid coordinates and material assignment write back over OPC UA or REST — same wagon stop, before the next train pulls in. The loading control system reads real wagon positions instead of operator clipboard estimates. Misroutes get flagged before the lid opens; the ERP material log matches the yard state by the end of the shift.
The architecture is boring on purpose. Three loosely coupled stages, each one independently testable, each one swappable when the rail operator changes wagon class or relocates the loading position. Built on the same stack we use across all our perception work: NumPy, scipy, PCL, Open3D.
A single LAS file per wagon stop — typically a million-plus points covering the wagon deck, the lids and a strip of track on either side. The LiDAR captures the scan as the wagon comes to rest at the loading position. Raw point cloud writes to local storage with a per-wagon UUID for audit trail and re-labelling.
Ground crop removes the track and ballast. Deck-Z estimation locates the wagon-deck plane. Height-band masking isolates the lid layer. Lid clustering returns the six centerpoints. Wagon-bounds gives the 3D box. The tracker state machine assigns a sequence number and flags the leading Roboterwagen if it is in frame. Mean centroid error stays under 5 cm against hand-labelled ground truth.
Output per wagon: JSON record with wagon ID, lid centerpoints, material assignment and audit images. Writes into the ERP, the MES or the loading-control system over OPC UA or REST. The Electron + Vue 3 + Three.js operator UI shows the live 3D point cloud, the train summary and a CSV export for the shift log.
All three stages run on an industrial PC at the loading station — Python prototype for development, C++/C# port for the final controller. No cloud dependency, no external API, no licence dial-home. The code is yours at handover.
Every wagon stop returns an exact 3D bounding box, the six lid centerpoints, a wagon sequence number and a Roboterwagen flag. Drops directly into the loading-control state machine so the next loading move is unambiguous. Same geometric output the Bahnwagon pipeline produces in production today.
Material type, tonnage and per-lid breakdown write into ERP/MES per wagon — same shift, before the train leaves. No more clipboard reconciliation, no more billing the wrong wagon. The yard-management system sees the actual loaded mass instead of the operator estimate.
Vue 3 + Three.js desktop app for the loading-station operator: live 3D point cloud, per-wagon summary, train list, CSV export, wagon-by-wagon audit. Already in production with our Bahnwagon customer — handed over with full source. Run it locally on the plant PC; no browser-cloud dependency.
Every loading station has its own wagon class, its own track geometry, its own existing control system. A generic detector solves the generic case; your loading position is not the generic case.
Every wagon class is different — six lids, eight lids, end-loaders, top-loaders, with or without a leading Roboterwagen. We calibrate the geometric pipeline on your wagons at your loading position, and we re-calibrate when the rail operator rotates the fleet. Calibration constants live in config.yaml — no retraining, no GPU.
The same geometric approach works on rock, salt, scrap and grain — only the lid clustering tolerances change. No ML retraining required when the material switches; the pipeline cares about wagon geometry, not what is inside the lid. This is the property that made the Bahnwagon project portable across plants.
The geometric stages are stateless. State lives only in the tracker — the component that assigns wagon sequence numbers and detects the leading Roboterwagen. Clean boundary, easy to integrate with your existing yard-management state, easy to swap when the loading control software changes.
You own the Python prototype, the C++/C# port, the calibration files and the Electron operator UI at handover. We document the system, train your team and walk away clean. No black box, no monthly per-wagon licence, no service contract you cannot exit. See our FAQs on IP and engagement model for the standard terms.
The engagement-model questions we hear from every loading-station customer considering a custom perception build. Need something more specific to your wagon class? Ask us.
Sensor setup, sample scans, your wagon class, your loading-control interface — anything you have. We come back within two business days with an honest first assessment and a fixed-price scope for the Discovery workshop.