Town and country - automated N-scale layout


K

kleiner

Well-Known Member
With Woodlawn Industrial Park beginning to wind down, its fun to start thinking about my next layout! Just to be clear, this project is still in the very early stages. I will not be able to get started with this project in any significant way until well into 2022.

Anyway, let’s start with some background: I have a diverse set of interests when it comes to model railroading. It was always clear to me that a single layout would never satisfy all of my desires. Consequently, I have always intended to build two layouts.

The first layout was to be a highly detailed HO-scale manually-operated switching layout which is what became Woodland Industrial Park.

The second layout that I have been thinking about is going to be a portable, fully automated computer-controlled N-scale layout. So in a sense it is at the opposite end of the spectrum from Woodlawn. This layout will have a continuous run and will not have super detailed scenery. The landscape and scenery only has to be “good enough”, not perfect. Not too many structures but a lot of trees.

Although I really enjoy switching freight cars on the Woodlawn layout, I also sometimes like watching trains just run. The best way to do this is to let a computer run the trains so that I can stand back and be a railfan on my own layout. Also, I want this layout to be a portable so I can potentially take it to train shows.

Some of the technologies that I will be using in this layout:
  • DCC for train control. I will most likely get a dedicated Digitrax DCS52 as the command station for this layout. I will be using DCC only for train control. Everything else will be controlled directly from computers.
  • The layout will be controlled by a network of Raspberry Pi 4 single board computers. These are really cheap and very powerful.
  • Turnouts will be controlled by miniature model aircraft linear servos. The servos will be driven directly from the GPIO pins on the Raspberry Pi. The servos are controlled by means of pulse width modulation. It turned out to be really easy to control the servos with a few lines of Python code.
  • The layout will need feedback sensors for the tracks so that the computer knows where the trains are. The sensors will be directly connected to the computer. There are several possibilities:
    • Magnetic reed sensors triggered by rare earth magnets mounted on locomotives. I have used this in the past and it worked really well.
    • Current draw detection - like for example a Digitrax BDL 168. I am not super enthusiastic about this approach as it requires a lot of wiring. I want this layout to be light and portable.
    • Computer vision system for detecting trains in blocks. I did some initial experiments and was able to train a convolutional neural network to detect block occupancy. But I don’t want to have to use a cloud-based server to run the neural network code. Need to see if a single board computer like an Nvidia Jetson Nano can handle inference tasks
I will write my own control software using some form of constraint logic programming. I have done some initial exploration in this area and it looks promising.

The track plan will be super simple: effectively it will be an oval with several passing tracks. The trick will be to fit this into a relatively small space and still have it look acceptable.

I have no idea what form the benchwork will take but it will have to be lighter than what I used for Woodlawn for sure.

I have no idea what kind of track I will be using but I would like something smaller than Code 80. Atlas code 55, Peco code 75 or Micro Engineering?

So in a nutshell, there is still a lot of thinking and design work ahead but it should be fun!
 
I am planning to use miniature linear servos for this layout for several reasons:
  • I hate installing switch motors under a layout as it is so fiddly. I have used Tortoise switch machines in the past and have a box full of them but I just hate installing them.
  • Its a lot harder to install switch machines on a foam layout. The best approach I have seen is to cut out a square opening and install the switch motor on a small piece of 1/4 inch plywood. But this looks like a lot of work.
  • I have tried using Atlas Code 80 N scale turnouts with solenoid switch motors but they are ugly and unreliable.
  • I have seen people use the bigger model aircraft servos but they seem to be much too large for this purpose. Also, installing under the roadbed is again something I hate.
The miniature linear servo solves all of these problems as it is small enough to allow it to be installed on the top of a layout. Controlling these servos from a Raspberry Pi single board computer is super easy as it requires just a few lines of code. I took this video to show the servo in action. I will need some kind of a small box to house these servos but I think I can get one 3D printed - will give me a good excuse to get a 3D printer :)

 
kleiner said:
With Woodlawn Industrial Park beginning to wind down, its fun to start thinking about my next layout! Just to be clear, this project is still in the very early stages. I will not be able to get started with this project in any significant way until well into 2022.

Anyway, let’s start with some background: I have a diverse set of interests when it comes to model railroading. It was always clear to me that a single layout would never satisfy all of my desires. Consequently, I have always intended to build two layouts.

The first layout was to be a highly detailed HO-scale manually-operated switching layout which is what became Woodland Industrial Park.

The second layout that I have been thinking about is going to be a portable, fully automated computer-controlled N-scale layout. So in a sense it is at the opposite end of the spectrum from Woodlawn. This layout will have a continuous run and will not have super detailed scenery. The landscape and scenery only has to be “good enough”, not perfect. Not too many structures but a lot of trees.

Although I really enjoy switching freight cars on the Woodlawn layout, I also sometimes like watching trains just run. The best way to do this is to let a computer run the trains so that I can stand back and be a railfan on my own layout. Also, I want this layout to be a portable so I can potentially take it to train shows.

Some of the technologies that I will be using in this layout:
  • DCC for train control. I will most likely get a dedicated Digitrax DCS52 as the command station for this layout. I will be using DCC only for train control. Everything else will be controlled directly from computers.
  • The layout will be controlled by a network of Raspberry Pi 4 single board computers. These are really cheap and very powerful.
  • Turnouts will be controlled by miniature model aircraft linear servos. The servos will be driven directly from the GPIO pins on the Raspberry Pi. The servos are controlled by means of pulse width modulation. It turned out to be really easy to control the servos with a few lines of Python code.
  • The layout will need feedback sensors for the tracks so that the computer knows where the trains are. The sensors will be directly connected to the computer. There are several possibilities:
    • Magnetic reed sensors triggered by rare earth magnets mounted on locomotives. I have used this in the past and it worked really well.
    • Current draw detection - like for example a Digitrax BDL 168. I am not super enthusiastic about this approach as it requires a lot of wiring. I want this layout to be light and portable.
    • Computer vision system for detecting trains in blocks. I did some initial experiments and was able to train a convolutional neural network to detect block occupancy. But I don’t want to have to use a cloud-based server to run the neural network code. Need to see if a single board computer like an Nvidia Jetson Nano can handle inference tasks
I will write my own control software using some form of constraint logic programming. I have done some initial exploration in this area and it looks promising.

The track plan will be super simple: effectively it will be an oval with several passing tracks. The trick will be to fit this into a relatively small space and still have it look acceptable.

I have no idea what form the benchwork will take but it will have to be lighter than what I used for Woodlawn for sure.

I have no idea what kind of track I will be using but I would like something smaller than Code 80. Atlas code 55, Peco code 75 or Micro Engineering?

So in a nutshell, there is still a lot of thinking and design work ahead but it should be fun!
Click to expand...
Kleiner - Wow, that made my brain hurt when I looked under the skirts of Computer Vision Neural Network theory. I will go out on a limb here: You are looking at multiple camera's using 'Face Detection' to determine what train is what and where. Is one camera directly overhead with a 'whole layout view' which would look to be the camera to determine the location of a train or trains. If a frame is processed at 1/2 second intervals, location may not be precise although close enough for what is wanted. Wouldn't you also need other camera's just above the horizontal plane at some location where foreground objects are not blocking to determine more specific things about each train to help with identity? I.E. If you happen to have multiple specific vendor GP30's; which could be identical from the top view, you would need to ID each - according to the Engine number or some other outstanding feature using a side view while it is moving. Again, I guess that you could grab a specific frame every 1/2 or so to process. To me that would be a ton of processing. Looked quick at the Jetson Nano. Quad core ARM processor running a 4GFLOPs/sec with a bunch of RAM. Is that for each core, total or GPU? I suspect that it would reach it limits sooner than later. This is going to be interesting to follow!

I am also working toward some sort of smart control of trains that can circle the layout without my intervention while I am running a local or switching the yard somewhere. I have been using AtMel ( now Microchip ) devices as my goto devices. My layout is bigger ( 30 x 40 ) than what you are going with, so camera's would not be possible because of the sheer count. Current detection looks to be the best way to do this in my case.

I am also a believer of using DCC as train control only. The more stuff you hang on the bus, the more chances sh.t is gonna happen. On top of that if DCC dies for a specific segment or section, so does all the other stuff hung on that segment or section. Troubleshooting becomes a real pain.

Merry Christmas!
 
ctclibby said:
Kleiner - Wow, that made my brain hurt when I looked under the skirts of Computer Vision Neural Network theory. I will go out on a limb here: You are looking at multiple camera's using 'Face Detection' to determine what train is what and where. Is one camera directly overhead with a 'whole layout view' which would look to be the camera to determine the location of a train or trains. If a frame is processed at 1/2 second intervals, location may not be precise although close enough for what is wanted. Wouldn't you also need other camera's just above the horizontal plane at some location where foreground objects are not blocking to determine more specific things about each train to help with identity? I.E. If you happen to have multiple specific vendor GP30's; which could be identical from the top view, you would need to ID each - according to the Engine number or some other outstanding feature using a side view while it is moving. Again, I guess that you could grab a specific frame every 1/2 or so to process. To me that would be a ton of processing. Looked quick at the Jetson Nano. Quad core ARM processor running a 4GFLOPs/sec with a bunch of RAM. Is that for each core, total or GPU? I suspect that it would reach it limits sooner than later. This is going to be interesting to follow!
Click to expand...

I tried this experiment a few years ago when I had an N-scale layout: My goal was to build a vision system that could detect block occupancy and while also being insensitive to variations in the rolling stock and placement of the camera. So in other words, no matter whether a GP40 or a SD90 occupied a piece of track, I wanted the system to tell me that a train was in a block.

I created a training set by running a bunch of trains around my layout and automatically taking a lot of photos. I trained the neural network using a GPU instance running in the Amazon cloud. Basically, for each block had a two-class classifier that could say whether the block was occupied or not (a yes/no result). It worked remarkably well.

If I deployed this technique, I would be sending snapshot photos to the classifier every 300 milliseconds or so. No real need for the system to be much faster than that - the trains won't be running all that fast! The output from the visual block detector would then be fed into the constraint solver to generate the control output.

The main requirement is that the layout has to be designed so most of the track is visible.

ctclibby said:
I am also working toward some sort of smart control of trains that can circle the layout without my intervention while I am running a local or switching the yard somewhere. I have been using AtMel ( now Microchip ) devices as my goto devices. My layout is bigger ( 30 x 40 ) than what you are going with, so camera's would not be possible because of the sheer count. Current detection looks to be the best way to do this in my case.
Click to expand...
That great - have you written up anything about your layout?

ctclibby said:
I am also a believer of using DCC as train control only. The more stuff you hang on the bus, the more chances sh.t is gonna happen. On top of that if DCC dies for a specific segment or section, so does all the other stuff hung on that segment or section. Troubleshooting becomes a real pain.

Merry Christmas!
Click to expand...

Completely agree - DCC is great but you don't want to use Loconet or equivalent for critical signals. It's best to cut out the middleman and directly handle the signals in the computer.
 
kleiner said:
That great - have you written up anything about your layout?
Click to expand...
Ya, lots of design criterion, part specifications and the like along with operational theory and what is to do what. Pretty much not public consumable, more for me to help me remember stuff instead of 'I remember thinking about this - now where is it' stuff. I suspect in time when there are working examples on the layout, then I will shed light on the how to's. All of the above got me started when I was helping at a club layout and the rats nest of wire under it. A layout is a mechanical beast at best and sooner or later something will come loose, break or worse; become intermittent. Chasing through the best laid plans of wire schematics is bad enough on a circuit board let alone even a small layout.

Generally speaking communication between the various devices will use multipoint RS485 for long runs, Twi ( I2C ) for short runs. Planning on some host controlling everything: probably dual xeons with 6 cores each - way overkill probably although I am getting them pretty cheap.

Major devices needed but are not limited to:
Signal Control
Control Points: [sidings, house track, bridges ...etc] can have Signal, Detector(s) and Turnout Control
Block Control: [blocks between Control Points not directly connected] can have Signal, Detector(s) and remote Turnout Control.
Turnout Control; switch motor and logic, Detector.
Detectors - both Current and Optical, can be used stand alone or with other controllers.
In time - uncouplers, road crossing railroad and other stuff I have thought about but have conveniently forgotten.

All devices are designed to do specific stuff and can talk with its neighbor and/or the host. Thought Ethernet first, 802.11 next and settled on 4 wire RS485, well 5 with ground. Ethernet needs a 'home run' cable to each client and 802.11 is limited to client count on an Access Point. Either Ethernet or 802.11 would force more spendy devices; whereas Uarts are already built in. Looking at my layout plan, and using seat of pants thinking, I will have more than 100 devices connected if you include all the major devices above. RS485 ( RS232 and RS422 ) can be setup full duplex multipoint and can address 255 other devices. 485 fan out is 32, see below for more. RS422 has better fan out, but slows down for every device you hang on the bus. RS232 is not a differential signal. Given the amount of noise a layout could provide I just left that out.

Maybe someone here knows: With straight back to back relay of RS485, the messages on the bus are everywhere happening instantaneously. Devices wanting to talk have to wait for the bus to become available. A few days ago I got to thinking about a RS485 smart relay. Since not all communication is to/from the host, a Smart Relay could step in and help. Said relay would have its own address, and could pass messages up/down the bus depending on address. Addresses would be ordered down stream from the host. Say the host wants something changed on that last device on the bus. Can't do much with that. Now say the host wants something changed somewhere inbetween that last host on the bus. If the address was greater than the relay, no reason to relay. That would free up the bus down stream to allow devices to talk with each other and not have to wait. Same for upstream. Might work.
 
ctclibby said:
All devices are designed to do specific stuff and can talk with its neighbor and/or the host. Thought Ethernet first, 802.11 next and settled on 4 wire RS485, well 5 with ground. Ethernet needs a 'home run' cable to each client and 802.11 is limited to client count on an Access Point. Either Ethernet or 802.11 would force more spendy devices; whereas Uarts are already built in. Looking at my layout plan, and using seat of pants thinking, I will have more than 100 devices connected if you include all the major devices above. RS485 ( RS232 and RS422 ) can be setup full duplex multipoint and can address 255 other devices. 485 fan out is 32, see below for more. RS422 has better fan out, but slows down for every device you hang on the bus. RS232 is not a differential signal. Given the amount of noise a layout could provide I just left that out.

Maybe someone here knows: With straight back to back relay of RS485, the messages on the bus are everywhere happening instantaneously. Devices wanting to talk have to wait for the bus to become available. A few days ago I got to thinking about a RS485 smart relay. Since not all communication is to/from the host, a Smart Relay could step in and help. Said relay would have its own address, and could pass messages up/down the bus depending on address. Addresses would be ordered down stream from the host. Say the host wants something changed on that last device on the bus. Can't do much with that. Now say the host wants something changed somewhere inbetween that last host on the bus. If the address was greater than the relay, no reason to relay. That would free up the bus down stream to allow devices to talk with each other and not have to wait. Same for upstream. Might work.
Click to expand...

This sounds great! About 30 years ago, I did work in developing gigabit networking so I am familiar with the topic but I have no personal experience with industrial standards like RS485. I worked mostly in optical networking myself. This was considered very exotic back in the early 1990s :)

For this layout, I am going all wireless. I am going to have lots of Raspberry Pis each controlling a few local devices and all of them communicating via Wifi (or possibly zigbee). I just hate the thought of having to put down miles of wire for occupancy detection and turnout control. Considering how cheap these single board computers have become, I think it will be much better than hard wiring devices. Each Raspberry Pi has enough GPIO pins so I will be able to control a dozen devices locally and I will probably have 4 or 5 of them controlling the layout with one of them acting as the ringmaster (unless I use a Jetson Nano for that purpose).
 
Sounds fasinating. Looking forward to seeing updates. Have you looked at https://arduinorailwaycontrol.com I've played around with it a little. He recommends hall effect sensors over reed switches. If you went with a esp32 or esp8266 they are basically an Arduino with wireless built in. Also you might find some of Udoo's (udoo.com.) options interesting regarding the neural networking. I have some but haven't had the time to venture into that arena yet. I like pi's but sd failure is a concern. Udoo has more storage options.
 
bigfoot13 said:
Sounds fasinating. Looking forward to seeing updates. Have you looked at https://arduinorailwaycontrol.com I've played around with it a little. He recommends hall effect sensors over reed switches. If you went with a esp32 or esp8266 they are basically an Arduino with wireless built in. Also you might find some of Udoo's (udoo.com.) options interesting regarding the neural networking. I have some but haven't had the time to venture into that arena yet. I like pi's but sd failure is a concern. Udoo has more storage options.
Click to expand...
I have played around with Arduino in the past but I really like the fact that there is a full operating system running on Raspberry Pi. Its dead simple to control the GPIO pins from Python or Node.js. In contrast, the Wiring language used in Arduino was a little bit too much like C for my liking😀.
That said, the Arduino railway control website does look interesting and I will give it another look.
Regarding Udoo - there are all kinds of SBCs but almost all of them apart from the Raspberry Pi have weak Linux distributions. You are right about the corruption problem for SSDs but in my case, it will not a problem. Only one Raspberry Pis will need maintain state. So it will be easy to keep a few extra SD cards preloaded with my code.
 
@kleiner I agree. I prefer the newer languages than C but am comfortable with it. The Udoo x86 and Bolt will run the latest Ubutnu or other distros. They are x86 code. They used to have more memory and speed then the Pi's too. My Bolt has 32GB of ram. The x86 has a Arduino hat built into if for the Arduino like processor. Makes integrating and reprogramming the Arduino supper easy.

The esp32 and I believe the 8266 will also run Node and micopython. They have less analog inputs and run at 3v instead of the arduino 5v but that is similar to the pi then. The direction that I'm contemplating is using the Arduino/ESP32/Computer/JMRI with Digitrax DCS52. The DCC gets the trains and possibly interaction with switches and the Arduino/Computer takes care of the rest.

Definitely interested in following your progress. Each has to make a decision of what will work for them. I find it interesting to see what factors affect different peoples decisions.
 
bigfoot13 said:
@kleiner I agree. I prefer the newer languages than C but am comfortable with it. The Udoo x86 and Bolt will run the latest Ubutnu or other distros. They are x86 code. They used to have more memory and speed then the Pi's too. My Bolt has 32GB of ram. The x86 has a Arduino hat built into if for the Arduino like processor. Makes integrating and reprogramming the Arduino supper easy.

The esp32 and I believe the 8266 will also run Node and micopython. They have less analog inputs and run at 3v instead of the arduino 5v but that is similar to the pi then. The direction that I'm contemplating is using the Arduino/ESP32/Computer/JMRI with Digitrax DCS52. The DCC gets the trains and possibly interaction with switches and the Arduino/Computer takes care of the rest.

Definitely interested in following your progress. Each has to make a decision of what will work for them. I find it interesting to see what factors affect different peoples decisions.
Click to expand...
I had ruled out Arduino but you have made a persuasive case that I need to take another look. Its been over ten years since I last played around with an Arduino - looks like they have progressed quite a bit since then. Its been at least 20 years since I last coded in C. I have mostly used Java and Python in recent years.
I am really delighted that there are so many technically minded hobbyists in this forum. I should mention that worked in tech myself for thirty years until I retired at the end of 2020. My PhD work was in machine learning but I was a bit too far ahead of the curve when I graduated in the early 1990s. So was forced to work in other areas. Thankfully in 2010, I was able to get back into machine learning, mostly natural language processing.
This is an exciting time to apply tech to model railroading - so many good options and best of all, they are all generally quite inexpensive. The main reason I retired was to spend more time on model railroading :)
 
Here are some interesting specs. I personally have a bolt if you ever wanted me to try out some code for you. :)
shop.udoo.org

UDOO BOLT V8

Almost twice as fast as the MacBook Pro 13
shop.udoo.org shop.udoo.org

This looks interesting to but I haven't gotten one yet. To many other unfinished ideas. https://udoo.org/udookey/

I lean towards trying to take the best from each system instead of forcing 1 to do everything.
 
Regarding sensors: I have used these miniature reed switches very successfully in the past. They are only 1/8" in diameter and are easy to install under the track. The only extra consideration with these is that you need to install a rare earth magnet in each locomotive - but this is very easy since the coupler mounting screw is generally magnetic in most locomotives that I have seen!
IMG_2920.jpeg

A reed switch next to an N-scale locomotive for scale

IMG_2923.jpeg

A rare earth magnet stuck to the coupler mounting screw
 
After a long break from model railroading, I am now beginning to think about this N-scale layout again. I now have a new approach that I'd like to explore - building a compact, portable and fully-automated N-scale layout not to keep but to potentially sell.
Why sell? I have come to realize that I really like the process of building layouts but I don't have enough space to keep all the layouts I want to build :) Also, the goal for this project is not to make money but rather to just break even. I have a strong hunch that there might be many potential buyers for such a layout in my area. If nothing else, it will be fun to take this layout out on the road to shows and display it around my town.
This layout will have a really simple track plan baed on on an oval. I will use Atlas code 80 N-scale track with #4 turnouts. I will build very light benchwork and use extruded foam as the scenery base. The trains are going to be very short, just a couple of railcars or a Euro style locomotive with a couple of short freight cars. I will most likely not be using DCC but rather blocks that will be computer controlled. This is an initial sketch showing the kind of track plan I have in mind.

N_sketch_03.jpg
 
Since this is to be a compact layout for continuous running, an oval makes the most sense. And due to the tight radius of the 180 degree curves at either end of the layout, I will have to use sectional track. From my experience, Atlas code 80 flex track is not easy to lay in such tight curves.

Rummaging through the spare tracks bin, I found a few packs of Atlas sectional track that I had bought a long time ago. I have three radius: 9 3/4", 11" and 19"

IMG_6771.jpeg


I tried out the two smaller radius sectional track on a 2 ft by 2 ft piece of extruded foam. The 11 inch curves are just too big for a 24 inch wide layout but 9 and 3/4 inch curves fit fine. I tried out a small 4 axle switcher (SW1500) and a 50 foot box car with body mounted couplers. To my pleasant surprise, they ran just fine on the 9 3/4" radius curve. Keeping the layout radius less than 2 feet will make it much easier to move around. I think I will go with the smaller radius for this project.

IMG_6774.jpeg
 
kleiner said:
I tried out a small 4 axle switcher (SW1500) and a 50 foot box car with body mounted couplers. To my pleasant surprise, they ran just fine on the 9 3/4" radius curve.
Click to expand...
On the micro layout I’m currently building, I’m using both 8.5” and 9.25” radius curves and my 4 axle switcher with 65’ cars works well surprisingly! Although, they have truck mounted couplers. My gondolas are 55’ (I believe…) with body mounted couplers and those seem to work good too. Glad you were able to make those tighter curves work!
 
GuilfordRailman said:
On the micro layout I’m currently building, I’m using both 8.5” and 9.25” radius curves and my 4 axle switcher with 65’ cars works well surprisingly! Although, they have truck mounted couplers. My gondolas are 55’ (I believe…) with body mounted couplers and those seem to work good too. Glad you were able to make those tighter curves work!
Click to expand...
Indeed, I'm glad that the tighter curves worked without too much hassle. I think it looks quite acceptable with shorter cars and locomotives.
 
I have been waffling over two issues that needs some more thought:
  • DCC or DC: I thought about it and it appears that using DC might result in greater complexity for both wiring and the control software. I would basically have to implement something like Bruce Chubb's automated progressive block system. It's not a big problem but dealing with multiple throttles and multiple blocks just seems like a lot of work. I am now leaning towards using DCC with the nifty Pi-SPROG add-on for the Raspberry Pi.
  • Track system: I strongly prefer turnouts with powered frogs since I may be running short wheelbase locomotives such as European steam. But I am discovering that there really aren't many options in N-scale code 80. Atlas makes a #8 with a metal frog and there is the peach electro frog. The Atlas #8 is a bit large for such a small layout. With the Peco electro frog, I would need to make a bunch of modifications to make it work properly. Alternatively, I could switch to Atlas code 55 which has a good selection of turnouts but the problem is that some rolling stock with deeper flanges may not work.
 
You must log in or register to reply here.



Back
Top