Introduction

Blog & News

About the Model Railroad

RTAC Software

Videos

The Randall Museum in San Francisco hosts a large HO-scale model model railroad. Created by the Golden Gate Model Railroad Club starting in 1961, the layout was donated to the Museum in 2015. Since then I have started automatizing trains running on the layout. I am also the model railroad maintainer. This blog describes various updates on the Randall project and I maintain a separate blog for all my electronics not directly related to Randall.

2024-08-02 - Experiment: Track Cam Monitor

Category Randall

Here’s a small side project I’ve been working on for the last month on-and-off and I finally deployed the first prototype of it this morning.

One of the key issues we have on the layout is that we can park trains on the Napa and Richmond yards, and enter the mainline via turnout T150 - yet that is located on the other side of the mountain, out of view of operators who typically stand on the other side of the layout at the Stockton Yard.

Thus the goal of this new project is to give the Saturday Operators, who are located at the Stockton Yard, an easy way to view trains in the back of the layout, with a focus on the lower tracks where the mainline branches off to the Napa and Richmond yards.

To that end, I’ve added 2 cameras in the back of the layout, pointed at the track:

These cameras provide a video feed on the internal layout wifi which is then picked up by a new tablet display next to the Stockton Panel:

The tablet runs a special custom software that I wrote. It takes the video feed from both cameras and displays it side by side:


An engine approaches on the mainline track, as seen on TCM.

The tablet software named “Track Cam Monitor” (TCM) is designed to operate automatically. It starts automatically when the tablet starts, and stops the video feed when the layout power is turned off to preserve battery power on the tablet. That way, we never need to turn the tablet on and off -- it’s always on, except it’s in sleep mode when the layout is not powered. The cameras are also tied to the layout power and stop when the turnout is turned off.

The cameras are actually mounted “rotated” on their side to benefit from the larger field of view of these cameras: a portrait view is better suited to show the track which is “vertical” on the image. One feature of the software is that I can zoom, rotate, and scale each video feed independently. These are live feeds. There is no recording.

Please excuse the crudity of this setup as this is just an early prototype. The next step is to see what the operators in question think of this and iterate. Upfront, I can think of a few improvements to try down the line:

  • Camera placement is obviously the biggest issue.
    • The camera pointing towards Sultan is pretty much what I had in mind. One question is whether it should be mounted higher or lower. We cannot do a full “view from above” as there are pipes on the ceiling. I opted for a more mid-level view.
    • I originally envisioned having a camera near the Sultan tunnel surveying the track towards the back. Then I realized this is a tricky spot to mount a camera and power it, whilst at the same time it would be covering much of the same track as the other camera. Instead, by having the camera look directly at the back of the layout, we can potentially see trains arrive well before they get into the blocks we want to monitor.
  • Similar to what I’ve done in the Vision project, I’d like to have some track motion detection and highlight the screen when I see motion on the track.
    • The goal is to bring attention to movement and warn operators in advance.
    • One issue is that I’d like to avoid detecting people, as that’s not the thing to warn about here. I think that can be typically solved using the basic “grid mask” technique.

The cameras used are Tapo C110, like I used for the Vision project. I configure them from 1080p down to 720p as wifi bandwidth is more important than video quality in this usage. In RTSP mode, they have different streams -- stream1 is 1280x720 (example: video feed on the right in the screenshot above) whereas stream2 is 640x360 (example: video feed on the left in the screenshot above). Interestingly, the feed difference is not just the resolution but surprisingly changes the FoV a lot -- the “low-res” feed has a much wider FoV, which can be quite beneficial in this project.

The reason I don’t use the 1080p feed is that we don’t have a need for it -- there is a lot of benefit in not using the top higher resolution: a lower res feed uses less bandwidth on the wifi but more important it’s faster to process on the tablet. Since the tablet has a pixel resolution of 1200x800, there’s really no point in wasting bandwidth and CPU with a 1080p feed only to scale down the image at the end.

The software is open-source and can be found in the “Track Cam Monitor” bitbucket repository.


 Generated on 2024-11-21 by Rig4j 0.1-Exp-f2c0035