A lot of my interests when it comes to model train layouts are all about automation. Automation can mean to make the trains move automatically but it can also mean to automate signaling -- displaying semaphores and search lights according to traffic on the layout. The common denominator for both is block occupancy detection, namely to know where trains are on the layout.

An early prototype of camera-based block detection

The traditional way is to do this electronically. Rails are cut to form blocks, and current sensors are embedded in the track feeders, allowing sensors to detect when track power is being consumed. There are a number of commercial products to do that already -- BD20 and AIU01 on the NCE side, BD4 and BDL169 on the Digitrax side, SRC8 from Team Digital, etc. In O-Scale 3 rails Lionel layouts, they typically use reflective IR sensors mounted on the side of the track to trigger accessories.

All these require a lot of wiring, including careful track planning. Need to plan where the blocks start and end, have proper track feeders for these blocks, install sensors, wire them to their controllers, report to the main cab bus, etc.

A while ago it occurred to me that all this could be simplified by using cameras to detect the trains:

• Either kinect-style that would detect 3d volume changes,
• Or ipcams-style that would look for visual changes.

I’ve been dealing with IP security cams for the last decade or so. These cameras are now ubiquitous, cheap, powerful. Many models are wifi enabled, removing the need for wires. And motion-detection software for these cameras is equally ubiquitous. So why not use them?

My first test was the “translate” project: https://bitbucket.org/model-railroad/layout-wifi

Now to make it clear, this was not the desired outcome, only a very preliminary experiment. This project was a quick early experiment with some clear constraints: detection was mostly done by locating white stickers on the track. Obviously everyone would comment on how obvious the stickers were, but that’s because looks were not important in the project. The layout was also fairly unappealing (just a bunch of EZ-Track laying around). A lot of people can’t see past this surface.

Still that test revealed some interesting facts I had not thought about before:

• Because the track, nor the table, where fixed, they could shift slightly enough to perturb the markers locations recorded in the software if one was to bump into it. That was fixed by adding an offset in the configuration file.
• Actual detection was done by forcing the cameras in IR “night” mode (not all cameras support that). This worked fairly well and helped remove illumination changes. One typical issue with all optical solutions is that they depend on brightness, but this allowed it to work reasonably whether the room was lit by sunlight, artificial light, or even in the dark.
• The layout, for as non-realistic as it was, had two important features: a bridge/elevated section and a tunnel. Obviously the camera could not see in the tunnel, however there was enough coverage to use the entrance and exit to form a block. The elevated section did severely limit places where blocks could be detected.
• Cameras were merely 640x480. That proved quite enough for the precision needed and arguably made processing faster. No need for high resolution 4k cams here.
• Camera placement quickly became something to account for early. Even mounted in the ceiling, the narrow field of vision meant I needed 2 cameras for a small 4x9” layout. I tried wide-angle cameras and found the barrel distortion to make the edges absolutely unusable.
• Camera placement also had limitations with parallel track. For example a train on the first track could obscure enough of the second track given the angle of a specific camera. In one place I fixed by placing the white stickers not on the track but next to it, so that a train would inevitably cover them from a camera point of view.
• Human interaction and placement also mattered. For example reaching in to rerail a car could easily trigger a block detection by masking some markers. Camera placement must account for where people stand so that they do not block the view of the layout.

One thing I did in another experimental project later was to place IR leds in the roadbed, mounted vertically (like sensors for railroad crossings). These show up as bright points on the IR cameras, and it’s clear when they are obscured by a train, yet are invisible to us.

So quite a few interesting learnings here.

Eventually the second part of the project, which I should still get to someday, is to not use any markings on the track. Amusingly at that point, every software engineer I know would throw in “OpenCV” as some kind of battle cry. I mean it’s “computer vision”, right? Enough bragging rights and more hype than one can shake a stick at. Except I think it’s mostly overkill. What we need here is merely detect contrast in selected sections on a series of images. That’s what the Go program in Translate does. Arguably that can be using OpenCV instead but yeah, it’s overkill. I only wish OpenCV had Go bindings like JavaCV offers.

The one part where I think OpenCV could shine is in setup & calibration. Ideally I’d want to give it an image taken by the overhead camera and have it detect automatically the track for the initial setup of the blocks boundaries. Then I’d expect to have a quick calibration to account for any position shift when turning on the layout, especially in setups such as mine where the camera is fixed to the ceiling and the layout table could shift slightly.

Finally I’d like to share another pure hypothetical case where I think camera detection and OpenCV or similar could shine, and that’s in equipment inventory. The CMRS club where I belong is looking into RFID such as Traxx to identify cars coming in and out of a yard, to help in their operating sessions. This seems to me like a problem that could be solved by computer vision. I’d envision a system using two HD cameras, placed at the throat entrance and exit of a yard, and with trains at adequate “realistic” speeds (a.k.a. “slow”), it should be enough to inventory the cars getting in and out of that yard. There’s enough similarity between cars to build a model to recognize their shape (box car, flat car, gondolas) with a bit of model training, and OpenCV or similar could be used to read the numbers on the cars.

That seems like a problem worth solving.

---