# Android, Raspberry Pi, Linux, RFID and other technologies for train locating



## Brandon (Jul 6, 2011)

As to stop a thread high jacking on airwire we're moving the conversation over here to a new thread. The discussion was about 'future' control devices and using more advanced hardware to control a train.


Some people have been asking about using older music players, phones, or tablets for giving a wireless link and On Board Computer (OBC) and using software either on a desktop, tablet, or phone to control the locomotives. There are many solutions out there but most work of DCC. Another option is JMRI however that is highly based on DCC and some people, including myself, want to go with another solution that does what they need without the extra bells and whistles and complexity of DCC. However it should be noted that if you run an OBC there's no reason it couldn't emulate a DCC decoder in software and simply control the "dcc" loco through wifi rather than rail or other systems like q-wire when working with JMRI.


My personal goal is to simply run multiple 5-10 consists at once on 800' feet of track that has 2 mainlines. Block control, ir sensing, and other location based modeling methods are IMHO an ugly wiring mess and doesn't provide prototypical running. Also if the computer is inside the length of wire runs for each block would be massive. I'm not a fan of wireless but will admit this G scale would be one good sue of this technology. If you have a small collection of locos and cars and don't have club members that visit it's easy to make your entire collection use resistive wheels for block detection and so on however if one car is in a block you could lose 10'-100' feet of usable track and possibly multiple switches for other consists unless you blocked out ever 5 feet or so of track which again IMHO is an even bigger wiring mess.


The way I think about the location problem is for prototypical running a central control (and in our case software) keeps track of where everyone is, what switches are thrown where, and tells the locomotives where to go or what is open (depending if you want each loco to have a mind of its own or be a slave to a master controller -- but it's just a matter of design preference because the master control system could still have all the various 'personalities' of each loco in its software. It's just up to the person implementing the railway if he wants to think the actual loco is deciding or a central control system. I'll most likely go with central control as it simplifies some programming if only one system has access to every locos 'thoughts' so to say.)


For DCC, the biggest problem I saw was it mainly did location by detecting which block a locomotive replied from. If you have 800' of track and 20 blocks that's 40' of possible variance. When you also get into long consists and have leading, mid, and/or trailing locos the problem gets far more complicated for DCC setup of consists and potentially losing access to a lot of space on a layout for other trains to be occupying.


Everyone hears about RFID and there are some good and bad sides to it. I will admit I haven't done any real world testing but from real-world test videos and personal experience with RFID in non-train circumstances it works very well. Worst case is if it skips a sensor it's quite easy to make the software detect this and notify someone there is a problem with a sensor tags which is why I'd put in more than needed just for a way overboard failsafe. People in smaller scales than G do have some issues with reading sensors of adjoining tracks when they either use the wrong antenna on the RFID reader or sensor tags that work at 4"-6" range. In G scale we have less of a chance of reading sensors when using a reader designed for 2"-4" range as our tracks are further than this apart.


Several people who have done RFID place the reader below the track because there was no technology small or cheap enough before the last few years to put an RFID reader in a model train. I however believe the best way to use RFID is place a reader somewhere in the moving consist itself and place the cheap RFID tags all along the track. The expensive/size issue side of this is that you have to have a way to transmit what the data from RFID readers back to a computer which you couldn't really do before. DCC for example doesn't support sending data packets like this. However an like the Raspberry Pi or smart phone OBC can do just this and send the data back over wifi.

For OBC's I've been leaning towards the Raspberry Pi. It's $25 and uses 1Watt of power at max consumption. It uses an 700 Mhz ARM and has 128MB of ram (Or add $10 and get 256MB of ram and an ethernet port) It boots off a SD card, has Composite and HDMI video out as well as a stereo audio plug and HDMI audio. It has 2 usb ports and you can use a passive USB hub if desired. I plan to use one USB port for a wifi dongle that consumes about .2Watts and a USB RFID reader on the other for the 'locating car' for visiting consists (that way a visiting consist can be tracked on the railroad without modifying the persons loco in any way, and my trains will be told to 'run away' from any loco that the software knows it doesn't have throttle control for, or maybe 'block and make difficult' depending if I want to tease them a bit.) For my loco battery trailing cars or locos with this OBC setup I'll have to use a passive USB hub to connect a third USB device that will be either a servo controller, motor controller, and/or relay for controlling lights and other loco items. I have yet to decide which hardware will be best for this. I also think I may try to use the Raspberry Pi's on board sound for loco and other sounds. This could be a fun side project in the future as sound isn't as critical to my wants on the railroad.


Some other ideas mentioned by Victor were using fewer RFID sensor tags and using optics to measure rolling distances once a train passes an RFID. You could count the rotations of a trailing cars wheels (as it would be more difficult to modify a loco to do this) and based on the number of rotations you could calculate distance moved and track location based off this and error correct position when it goes over another rfid sensor tag. There are also other methods of course yet to be discussed. I'm curious how this will turn out but if $200 for extra sensor tags under the railway gives me nearly the same results as a more complex system that counts wheel rotations and costs less I might opt for the slightly more expensive just so have less things to design, build and that can break or go wrong. Part of the KISS idea (Keep It Simple Stupid) that my father taught me from the early software days before bloatware.

Last note is that for me, I will be writing my own code to run the trains. It will be Open Source and AI based where the software knows the distances between each sensor, knows where sensors have two paths (ie where a switch is) and knows the distance from the sensor to the front and to the back of a train. I can then (eventually) sit back and watch as I put 2 80 car trains on the railway and 3-8 smaller 5-16 car trains and see how the software tries to maintain passenger train schedules and other freight consists when some locos are too long for most sidings and it might have to queue the smaller trains up in a siding inches apart from each other to manage the railway and let the larger consists by. This is what I find ultimately interesting, is watching software learn and problem solve while I sit back and watch the trains go by on a nice summers day.


More to come later of course when I have more time to write up about this potential idea.


----------



## Chip (Feb 11, 2008)

Brandon: 
I have been thinking about the location problem for some time. No commercial interest. I looked at GPS, RFID, sonar. A guy named Walter in Santa Barbara produced a sonar based project (RPS) that he sold off to And Reichert of Proto87. I went and saw a demo in early 2009. It learned a layout precisely in real-time. But it won't work outdoors. Bob Jacobsen put an interface into JMRI for it. Gamesontrack in Europe makes a similar product called GT-position. Seems to be strictly indoors as well. Having some GPS background, I looked into local repeaters. At the time, I could not see a cost effective solution, though the accuracy was fine. 
I have a close friend who ran one of the RFID deals around here. With his suggestions, I found cheap "Redbee" RFID readers with Zigbee; but they did not have an adequate time-stamp at the collection point. And getting the packets home to a central point in a timely fashion wasn't a slam-dunk. Then I was at the 
Ontario big train show last summer when I ran into a Cisco guy (Gary) whose day job was building big ticket location systems for schools using RFID. I mentioned the RFID idea: One RFID tag (sub $1) on each car. 
With triangulating antennae at 100 feet or so, he says he now gets about two feet accuracy. 
(Side discussions on big brother tracking kids elsewhere). He figured one could easily get the accuracy needed with reasonable antennae placement 
on a garden railroad. And you could do other things (power, etc.) to juice it as well. I got the impression he was smitten with the idea and would show up with one some day. 
Hope this helps.


----------



## Brandon (Jul 6, 2011)

Posted By Chip on 25 Oct 2011 12:04 PM 
Brandon: 
I have been thinking about the location problem for some time. No commercial interest. I looked at GPS, RFID, sonar. A guy named Walter in Santa Barbara produced a sonar based project (RPS) that he sold off to And Reichert of Proto87. I went and saw a demo in early 2009. It learned a layout precisely in real-time. But it won't work outdoors. Bob Jacobsen put an interface into JMRI for it. Gamesontrack in Europe makes a similar product called GT-position. Seems to be strictly indoors as well. Having some GPS background, I looked into local repeaters. At the time, I could not see a cost effective solution, though the accuracy was fine. 
I have a close friend who ran one of the RFID deals around here. With his suggestions, I found cheap "Redbee" RFID readers with Zigbee; but they did not have an adequate time-stamp at the collection point. And getting the packets home to a central point in a timely fashion wasn't a slam-dunk. Then I was at the 
Ontario big train show last summer when I ran into a Cisco guy (Gary) whose day job was building big ticket location systems for schools using RFID. I mentioned the RFID idea: One RFID tag (sub $1) on each car. 
With triangulating antennae at 100 feet or so, he says he now gets about two feet accuracy. 
(Side discussions on big brother tracking kids elsewhere). He figured one could easily get the accuracy needed with reasonable antennae placement 
on a garden railroad. And you could do other things (power, etc.) to juice it as well. I got the impression he was smitten with the idea and would show up with one some day. 
Hope this helps. What sort of costs were associated with the localized gps and/or repeaters? How well do they do with tracking 10 items at once or 150+ items at once? 

On Redbee/Zigbee, could you explain a bit more about what you meant by "did not have an adequate time-stamp at the collection point"? I'm not sure why a time-stamp would be critical when dealing with data received for a G scale layout. I had also looked at Redbee in the past but for the cost of the $67 Redbee you could get the $25 Pi, $10 wifi dongle, and a $20 usb rfid reader you're at $55 (but this wouldn't include something to control the locomotive and lights, but you could possibly do sound included in that $55) but you have a lot more hardware to play with. The Redbee does have 4 io pins you can pulse for some things but I'd wonder if it could be used to do everything a loco would be able to do (smoke, lights, motors, soundcard, etc). 


2' at 100' is pretty good. my layout goes out 75' from both corners of a home so I'd have to add extra relays to handle that, but what type of relays/readers was he using and what was he using to do the triangulation? The biggest issue with rfid triangulation is they often can only be reading 1 item at a time, or the cost is pretty high. In a G scale layout and parallel tracks we'd need 2" of accuracy as that would give a 4" range it could be in which would just barely help software thinking trains jumped the track.


----------



## Chip (Feb 11, 2008)

_What sort of costs were associated with the localized gps and/or repeaters? How well do they do with tracking 10 items at once or 150+ items at once? _

GPS localized stuff was several hundred $ for the main unit. The tracking is done the opposite way from my RFID scheme ( i.e the cars would have a a GPS receiver like a cell phone) and have to ship the data from each car wirelessly. It would obviously scale pretty well if you could time-stamp the reading and then interpolate the speed, acceleration, etc. You would need enough bandwidth for the back channel to get the stuff to your central computer.


_On Redbee/Zigbee, could you explain a bit more about what you meant by "did not have an adequate time-stamp at the collection point"?_ 


The Redbee, as of last summer, did not time-stamp each RFID read. I tried to talk the designer into it; he's focusing on other markets. My RFID scheme is fixed location readers with RFID tags on each moving car. When I looked at the other way (fixed RFID tags with moving receivers), there were several problems. One was that readers generally need a stable RF environment around them. Seemed to be easier to set up and "tune" in a loose sense with a fixed reader. And by having a tag on each car, it seemed a lot easier to get acceleration data. 


The problem with the Redbee was that on collision detection, the unit added a factor (unit id times 50 milliseconds, plus a fixed amount) for retry. Hence there is no real way to know the time of the read. So no speed, acceleration, etc. and given other latencies, you could get an RFID tag read-time that is off several seconds. 


_but what type of relays/readers was he using and what was he using to do the triangulation?_

It was obviously Cisco stuff but I know nothing more. He told me he tracks (cheap pun) lots of kids real-time. 


There are many videos on youtube, some going back several years, about RFID and model trains. Search "rfid trains".


----------



## Greg Elmassian (Jan 3, 2008)

If you really want to do some groundbreaking, inexpensive location sensing, try looking at using TDR. There are some companies looking into this. 

The other way outdoors is probably an RF location system, I'd use the excellent locating abilities of UWB, but you would have to build it yourself, and the frequencies are too high for a non-RF engineer, let alone someone who is not an engineer. 

I'm a bit intrigued about "_ want to go with another solution that does what they need without the extra bells and whistles and complexity of DCC" 

Well, DCC is not complex compared to your embarking a new system on your own, you could use DCC as the control, and add in your position feedback. Saves you from inventing all the commands and controls to do consisting, and are you going to design all your lighting controls, mars lights, etc? 

Overall, the most promise, and really the least expensive was the UWB, and there's a real inexpensive way to make it, but most of the good ideas have patents. Of course, you could make it for yourself, not sell it. 

Greg_


----------



## Brandon (Jul 6, 2011)

Chip: Any chance you know the gps transmitter model or the receiver models? If the receivers support usb and are less than $50 that might not be a bad solution. A couple hundred bucks for the main station isn't a project killer because if everything else works well that would save time by not having to buy and install a bunch of rfid sensors below the track. 

For the Zigbee timing issue I was wondering if the collisions were ultimately what would cause problems. In a perfectly tuned environment collisions are rare but getting a perfectly tuned zigbee network when some nodes are moving is next to impossible. I have around 100 zigbee devices in my home and even though they are in a mesh network setup, when I lose one phase of power to the home and only roughly have the devices go offline, after this power comes back on the network topology is such a mess I typically flip the main breaker to power cycle all zigbee devices to undo the rats nest of paths. I also have a dozen zigbee stations with ethernet connected as well that can relay data back to a central location to help reduce the number of hops each zigbee device takes, this makes a huge improvement to paths. I think the longest hop I have no is 3 that is about 50' away from a zigbee bridge. From all this the biggest thing you'd want to be careful of in a zigbee network is try to never use a moving zigbee device as a node that could route data for another zigbee device. Path changing for zigbee in the devices I've worked with are very slow and could take up to 5 or more seconds to repath to where it was going. Zigbee just doesn't do changes well. Meanwhile when this happens data is often lost. Zigbee range is also not the best in many devices. If doing Zigbee I'd make sure you run a more point to point rather than mesh topology. Just some thoughts from my experiences. I also have been looking through youtube for videos of rfid and trains, mostly ho stuff and all fixed position readers... Cool stuff to see concepts that work. 

Greg: I've been lookup up TDR and UWB locating tonight, any idea of a product that someone can by off the shelf for these? I'm terrible at soldering so hardware like this might be beyond my reach if there isn't a product someone could by to do it. 

One other promising thing I was doing tonight is I downloaded some train models designed for OpenBVE. They have dozens of loco sounds from various track noise to whistles, horns, brakes, idle sounds and so on. I used the sample clips for the models and played them in loops (as they're designed for) and write a simple little perl script that can take input from a socket to cycle through various sounds and play them based on me sending a "start" "stop" "faster" "bridge" "signal" and other commands. I'm sure a phoenix sound system works 'better' at the moment but I bet I could spend a couple hours and come up with something quite useful if I could do all this in 20 minutes of scripting using OpenBVE's models. Could be also fun to play sounds when passing other items. I also wouldn't have to deal with io to a sound card if I could play the sounds directly from the Pi. Just more thoughts, nothing in stone yet.


----------



## Brandon (Jul 6, 2011)

Forgot to mention. The reason I'd prefer to not use DCC is because there will be overhead and I'd be working with something like JMRI. Although JMRI does a lot it really doesn't (or I didn't know it did) artificial intelligence for testing how trains move, learning, and also working with time schedules and other custom requirements. I know you can have JMRI set a train to follow a pre-programmed schedule but I want something that is dynamic. I believe that I could write everything I want from scratch (which it's always easier to new/more code when you're the one who wrote it all) in probably a quarter or more time. When adding plugins or extending an API you have to do a lot more work, and I'd have to see JMRI in action personally for hours to really understand it but it's hard to see a complex JMRI setup and what all it can do when you don't have any of the hardware for it. Thus why I'm inclined to do something completely new. maybe if everything I do works well and I get the time I could re-write or port some of the code to JMRI's API but I'll do the POC first with whatever I find fun to do first. 

For mars lighting and so on I probably will. I'm leaning towards creating trailing battery cars for most all my locos. If I did this I'd actually add a switch to keep the train working in 'standard' mode but then in a custom mode for a trailing car all lights would be broken out into different wires that can be daisy changed through all locos to the trailing car. This would include forward, reverse, cab, ditch, mars, smoke, and possibly other functions. I've also toyed with the idea of having two electromagnets in a loco or trailing car that as it passes a sensor can flip the switch infront of it so I don't have to run wire pairs to each switch but instead can run the switches off a shared power source and have the trains control switches as they get close. All ideas, might not actually work, but interesting ideas. This is also why I think having an OBC would best 'future' protect my locos. I've been in the embedded linux market for about 15 years and the biggest issue with any product is hardware limitations. The Pi device with 700Mhz and 1 watt usage gives plenty of head room for future features so I often keep finding myself thinking it's a good solution since it's not as much an embedded device as a small thin client that's the size of a typical embedded device. 

For signals around the track, I have _no_ idea how I'd do these yet. I imagine signals are 5 years away so I'll cross my fingers a wireless or shared bus method for signals comes out before then.


----------



## VictorSpear (Oct 19, 2011)

Brandon,

Came up on deck for some air to take readings on some loggers we are testing. Glad you've pinned your core objective clearly to location precision targeting and identified what you don't care about. This makes it easier to follow. You have no concerns about power too, so this can easily be influencing your design orientation away from microwatt powered controls - my humble view. 

We argue now to use a different and cheaper thought process and 'compute' a solution: You do not need GPS at all. 2 feet at 100 is terrible for the sport and you don't want 'guess' positioning at this scope. Unless you are researching collisions. There is nothing 'global' about positioning requirements for 800* feet of track here. An alternative, LPS (Location based positioning) that is terrestrial and localized if you are into positioning checks with a small mesh network will work reasonably better than GPS, but still not good enough. But who wants approximates when sitting right next to the train ? You're on a flat and immovable track - every inch is already mapped and known on a scalar grid. It does not float, roll or pitch, so mathematically or otherwise the location of any of your stock cannot be off by 0.25 of an inch at a gridpoint computed under any speed condition. This should be the minimum rt analytics output requirement. Agree ? Knowing where loco Susie is at any time precisely is cool. Cooler is bringing her to a precise braking stop no more than 5 mm from a spot on the track every time with a single click ?

For every tee on the track, there is a coordinate in the db loggers at mission control, right ? Now refine this further. You can optically pick up coordinates from the track - on demand or with alert bursts on pre-specified (or all) sections of the track. And, you should be able to transmit real-time location readings wirelessly to mission control without this 2 lane RFID *sensor alley* solution alongside the track even if you inherit readers and tags for free.

At this point there is more than one fork on the road, Yogi. Firing a non-reflective microlaser through a pinhole in the floor of the loco to the track tees can easily replace the rev counter with improved accuracy. (I could send you the clip on this when i find it) But I'd prefer the dime sized micro optical rev counter for n tactical reasons - more on this later. If your'e planning to write software, the math using either is around a dozen function calls using the OBCs embedded libs so don't let this scare you anyway. You could focus on plug and calibrate your grid (track) with a few runs in both directions. 

These devices interface with the open source Arduino, for example, beautifully. Regardless of the OBC you finally select, consider the alternatives: A one-two punch with the Xbee+Arduino combination for rt_data collection plus packet broadcasting of dozens of parameters from the loco. You could attempt to plot the entire location solution now with just 3 Arduino beacons for triangulation (optional for dynamic error recalib) , 1 (Xbee+Arduino) on board. You also also add the Ethernet shield for Web server, XMPP server, Speed control shield... So the kids can tweetx Susie and get a xtweet back on when she's precisely arriving with candy in the third car. Possibilities are endless. 


With precision location and the Xbees also telling each other 'You know where I am, I know where you are', you've also inherited collision control for free. Agree ? You can tell locos Susie and Courtney to stay a min of 9.5 inches away from each other anywhere they meet on the track tomorrow. 

No wires, tags, readers. One intelligent optical sensor on board that simply counts tees for location tracking. 


Cheers.
Victor


----------



## Brandon (Jul 6, 2011)

Victor: I'm not sure I'm completely sure the overall method for locating you're describing. You mention that "every inch is mapped out and known on a scaler grid." Do you mean that the locos will receive some signal from transmitters to find it's coordinate on x,y for the layout? Or do you mean that locos would read rfid's around the track and count revs/tees to know every inch of the track? If the loco was using a mini gps system how tight is the error ratio for when trains go over top of each other on bridges, or around or in obstacles? Most people use wire mesh for mountains and that's obviously a decent faraday cage? 

I think if I understand what you're meaning by mapping the rest of the paragraphs will be a little more clear. I understand the rev counter and laser beam through a pin hole for detection and tracking (watched plenty of science shows on this stuff) but I'm just unsure which method of mapping you're referring to. 

For hardware, another thought I had last night about sound cards like the phoenix and others is that they often go by input voltage to know what is happening. I've seen trains start to move or slow down before you hear the sound, and that always bothered me a bit. I also didn't like how limited they were for yard sounds and other things. I don't know if the phoenix cards do this, but I know some dcc decoders can track rotations of tires so they could more easily compare input voltage, current, and motor revs to theoretically adjust sound pitch and volume to make a train sound like it's struggling or freewheeling. If you have an OBC you have control over when sounds get played and when the motors actually start to change speed. When playing with OpenBVE I really liked how they had different sounds for different surfaces. Imagine hearing different sounds as the train goes over bridges, rail crossings, and so on. While all this could be done on arduino alone, having all that processing power and sound chip already on the Pi would make it easier to develop on. 

I just keep coming back to that Pi board as a good choice for all sorts of features and the ability to write code in languages I already know and also use the the linux sound drivers for audio output. I took a quick look through the arduino stuff and they do have usb interfaces on most so that would be a great item for controlling lights and possibly motors. Google shows they have a motor sheild although it's not listed on their hardware page. I also read one place it was 12v and did 6v-18v yet another website has 3v-36v listed. Those arduino boards are also pretty cheap. If they had one that could run the motors on a loco and had 4+ pins for led lighting that would be perfect.


----------



## Brandon (Jul 6, 2011)

More food for thought, the Model A Pi uses max 300ma and has a 5v input, it appears this was finalized a few days ago. A usb wifi dongle uses about 120ma max for transmission. A usb rfid reader uses about 80ma for reading. Now if it's possible to find a cheap rc car esc with BEC (since BEC provides the 5v needed for the Pi) then if I can find an arduino board with usb with the ability to control a servo/the RC car esc to get forward/back for the loco motors and if that arduino board also had 4+ pins that can be used for lighting (headlights, cab, ditch, mars) then this would be a possible hardware combination that could work for my needs. I'll still have to wait and see what Victor was describing since I'm not as up to speed on the location technology and terms he was using. 

Oh, and one other trick with the ESC is finding one that's DC and supports either 5 or 6 cell lipo's. There are 5 and 6 cell lipo's for AC/brushless motors but I have yet to find one for DC as most of those stop at 4 cell for cars. If I have to maybe I just don't run the loco's as fast/at higher voltages. 

Edit: Also to note, I did find some arduino 10A 6v-41v boards, but they were $60 each. For that price it may be better to go for the esc method that I think (am I wrong?) would be a better way of controlling the motors in the loco. I can find some 4cell lipo brushed esc's (so 14.8v) for $40. I know RCS makes some esc's but since an OBC would be controlling the servo/esc, would you need an RCS type of esc that uses multiple servo inputs to do forward/backwards to change gears and do all the momentum stuff?


----------



## VictorSpear (Oct 19, 2011)

Brandon, 

It's an optical mouse on wheels with a long tail and whiskers. That's it ! 
And think of your mousepad as the trackpad that will only allow forward or backward movement on tracks.....and you will get the 'mapping' concept. 
No transmitters, no rfid, no mini-gps...no nothing. Just the optical mouse in the loco's belly and a calibrated track, and of course some math libraries. It sends out the track-id of every tee it crosses because it can 'see it' or sense it.


Yeah, there are a few motor shields out there for the Arduino and Seeduino. Lot of fun with the Arduino gangs. Will dig out the clips. 


Cheers.


----------



## Brandon (Jul 6, 2011)

That's not a bad idea. I should have thought of that. But one thing with optical mice is they don't like variant surfaces. Can an optical mouse be trusted to count tee's when some tees may be covered with ballast or on bridges and other sections? I guess a scroll wheel on a mouse could also "count" too if it's on an axle of a trailing car. 

What do you mean by "it sends ot the track-id of every tee it crosses because it can 'see it' or sense it? Do you mean put magnets at switches and use a reed switch to detect them? Then if a train goes x clicks between two read switches it should be able to locate where it is?.. As long as you don't have two magnets the same distance apart at any other locations of the railway? A third sensor/switch would also have to be detected too to know which direction the train was going. This could cause problems on loop backs unless an extra sensor was placed mid way through the loop. One issue I see (and maybe you know the fix) would be that the trains would all have to move down a fair bit of track before it could locate where it is. If using rfid it takes 2 sensors, and if placed a foot apart that's a pretty quick calibration. You can also just have trains stop themselves on an rfid tag and when you put on one the track just put the rfid reader over tag and there's no calibration required. The only downside would be as soon as you placed it on an rfid tag for the first time, the master controller would have to assume the tail end of the train can be either direction and mark extra track as possibly used until a second rfid tag is read to determine train direction. 


Or is there a faster way of knowing calibrating a setup of 10 trains after 'first boot' when nothing is known about where trains are located?


----------



## HaBi Farm (Aug 28, 2011)

Over 99% of what you are talking about is over my head - I do get the idea of mapping like an optical mouse on a 2 dimensional mousepad but that's about it. But here's a thought. It would be really nice if whatever you come up with would easily transfer to other layouts. For example, you could take your equipped train to someone else's layout and it would still be able to perform most or all of it's tricks (like sound control and avoiding collisions with similarly equipped trains). Also if someone else could take your system's components and easily install them into their own train(s). Ideally, then someone (like me who doesn't understand precisely how it works) would be able to use some or all of the great capabilities you are talking about. 
But as Victor alluded to on the earlier thread - let's avoid "8 track" hardware technology that will soon be outdated.


----------



## Brandon (Jul 6, 2011)

Absolutely, I've been using Linux since 92 and have been involved in over 20 open source projects. Sharing is the best way to get more for yourself in the end IMHO. I may stick to a simple language for "master control" called Perl that is easy to pick up and many people know already -- No recompiling needed and it can run on Linux, Windows, and Mac. I'll also create a bootable SD card image that anyone can use on any OBC, so when Pi gets outdated you just plug it into another newer OBC and it will run. I'll keep things pretty simple so there's little learning curve for use but there could be some plain text or xml files for basic configuration. Depending on what learning method I use it may require a database like mysql. Or I may just decide to make it real simple for people and write things so any SD card/locomotive can act as the master control rather than another PC somewhere and make all config via a web interface. Lots of possible choices, but what I'm saying is I always keep the idea of other using things I do when I do development. There is the rule of 3 where you can have it easy to develop, powerful, and easy to use but you can only pick 2. Which two will probably be unknown for sometime.


----------



## VictorSpear (Oct 19, 2011)

Ok..your thought waves are syncing now. There are several calibration techniques for varying conditions including snow. This is simply optical calibration with electronic verification and ovveride. 

All it is doing is logging the imperfections on the track during the calibration run, dog doo included. It is not hunting for clean track . Calibration once every six months still produces good results. If the imperfections including gravel and chicken grit have changed exactly every three inches in at least two sections, you had an earthquake or relaid the track so you have to recalibrate. During the next run, all it needs is two matching hits on any 12 inch section of the track. The reference beacons deterministically extrapolate for further precision. You can skip at least 30 feet of track and still know accurately where you are. We found a spot between the two rivet heads of the inside track of LGBs that give very accurate reads. Hard for birds to land exactly there and on every three inches to defeat the system.

No sensors, no reeds, no weeds, no magnets. Just the laws of the speed of light and corrections for bad light.


----------



## Brandon (Jul 6, 2011)

So are you saying you can do all locating without any rfid and simply by counting incoming pixel(or whatever the input data is) changes from a mouse? 

What exactly happens during calibration? If you have some time I'd be interested a brief description of your loco setup, how calibration works, and how functioning works. What mice do you use that don't turn off the optical sensor if the sensor isn't against the desk (most mice I know of shut off the optical sensor when lifted up more than about 1cm). How do you make/use/establish your "beacons"(hardware and where they're placed). And how do you calibrate and watch for errors when running?


----------



## VictorSpear (Oct 19, 2011)

Ahoy Brandon, 

Excellent questions. Was photographing some heavenly objects during the early hours and completely lost track of time. Then remembered the question you had earlier. 

So....simply think of the process as industrial surface inspection scanning. The 'mouse' was just an analogy, because the principle is the same. No you cannot pick one up at Staples. In this case we are just doing coarse surface sampling with varying levels of precision. It doesn't matter how coarse your gravel and how dirty the track is as long as there is sufficient precision sampling of the entire track. In your case, the sample run could be done in 8 minutes. 

For example: 

At the highest level we can inspect the skin of aircraft for cracks .... 
and at the lowest level we include bird dropping on tracks.  

I use the ultra-miniature micro laser sensor for some precision tracking exercises with green-safe level 1 variety. There are at least 1000+ low priced inspection sensor models, but you could even start with the common industrial inspection photosensors and get good results for initial experiments. 

You can create various sampling algorithms for yourself. Here's a simple one: 

When I said - send out each tee_id, that is for the calibration process at slow speed range, say 3 to 30 mph. The OBC writes to the onboard microloggers for every 100 reads and transmits the calibration samples to mission db. An index of samples of each section is stored. It has actually sampled the surface profile of the track in a very tiny precise line along the track and indexes it. That's all it is. 


You can experiment with various run settings: 

On regular runs, you set the tracking level: High, Medium, Low, or Random...and run trains. The ISAM indexed onboard logger data is periodically checked with the current sample and optionally after higher speed runs, a cross check is initiated by the Arduino contacting the 3 IR distance beacons for a triangulation arrived validity check whenever the trains slow down or stop. This is to make sure the exact location indicated by the main tracking process is not totally out of sync and way off expected coordinates. Stuff happens sometimes and you need a safety cop to check things out. For the beacons you could look at these: http://zuff.info/RangeFindersComp_E.html 

You should be able to get location tracking within +5/-5 inches for average runs. Otherwise your sampling needs to be readjusted with tracking spikes - little pins you stuff every 10 feet in the track for further error correction. 

Hope this helps. 

Cheers 

Victor


----------



## VictorSpear (Oct 19, 2011)

Just passing by to drop off your homework reading assignment: 

http://www.acroname.com/robotics/info/articles/sharp/sharp.html .... Remember we only use it for ad-hoc verification. The loco must confirm where she says she is and the IR beacon must confirm this at a precise spot on the track. Then she can go her merry way....till we check again at the next beacon. 

"These new rangers all use triangulation and a small linear CCD array to compute the distance and/or presence of objects in the field of view. The basic idea is this: a pulse of IR light is emitted by the emitter. This light travels out in the field of view and either hits an object or just keeps on going. 

With the introduction of the GP2DXX line of Sharp detectors, a new approach was developed that not only gives object detection at a longer range than the previous method, but also offers range information, in the case of the GP2D12, GP2D120, and GP2DY0A ('0A') detectors. These new rangers offer much better immunity to ambient lighting conditions because of the new method of ranging."


----------



## Brandon (Jul 6, 2011)

I read up last night and will be again tonight. Lots to learn as there is a bit of complexity to these ir proximity sensors.


----------



## VictorSpear (Oct 19, 2011)

Brandon, 

Hope your reads overnight were fun. Don't worry too much about the technology. It's after all only human-made stuff . The proximity sensors used are for triangulation checks and are not needed if you don't need accuracy down to 1 inch for a location fix for fun rides. Just the optical rev sensor with the mathematical model gives excellent results when adjusted for curves and track jitter and you can do it very inexpensively if you calibrate well. You haven't yet asked me how we figure out how the Loco is reporting the exact turnout and siding she is on without any sensors planted next to frogs so you probably figured it out  

In the design use cases for an OBC with location targeting, you should ask yourself these Y/N questions: 

1. With two trains a foot apart on two lines, the GPS readings are the same on both. (If they are not, you have your first problem). Now which loco is on which track ? 

2. Place two locos 10 feet apart and using a handheld GPS (SIRF ++++ or whatever), take a reading at each loco. Are they same, approximately the same or different ? Now take the same reading the other way. Are there any variations ? And when it is cloudy what do the readings look like ? 

3. With two trains running parallel on the RFID freeway of 800+ tags, which train gets a hit ? Or do you need tags on the other side too ? This would end up with more than 800+ tags perhaps ? 
Ok, so if there is a single main line and Susie with 5 cars is behind Harry with 10 cars and exactly a foot apart, what does the RFID galleria report? One or two locos ? 

It should be fun to analyze your observations to the above three. 

For this Use Case you should have a flat Y/N boolean: 

4. My locos must know exactly where they are at anytime without the assistance of any external sensors or wires. 
5. My loco should tell me where she is, not rely on me to tell her where she should be or where I 'think she should be'. 



There are plenty more use cases, the answers to which, may help you tune an optimal lower cost, less-wire solution. 

Cheers 
Victor.


----------



## Brandon (Jul 6, 2011)

I always have enjoyed reading and learning. If I stopped learning I probably wouldn't be happy as much.  

Lots of reading yes. the IR reminds me back when at the University and seeing the master CS students in AI working on their robots. There are a lot of complexities to IR and laser feedback and it takes a bit of time to develop a system and work out different real world issues that come up with each environment. If I want to make something that requires less development and others can use, I think IR may not be the way to go at first but I still want to consider it as I think it would be interesting. Also with an on board computer with USB placing a small camera in the cab could be more of interested to me because you can watch what the loco sees as well as use image processing to detect where are and which direction you go on a switch. I actually considered using cameras to track the loco but software to do this isn't quite there yet. I use zoneminder and a dozen cameras at my house 99% for fun and 1% for security so it is possible to setup zones and if there is motion have it trigger other software based on zones being occupied. I could hack up something that way but being that the cameras are analog and have a simulated resolution of 480x320 and mounted on the eves of the home that move during wind isn't a perfect solution either, though I could probably make it 'work' well enough. More projects for the future maybe. 

1. I'm not sure you can tell which train is on which track unless you have a history of where it has been and know how switches are thrown. Distance from the beacon is all you need to know where it is on a 2d grid. 

2. Readings are the same depending on the how accurate the equipment is. It is also possible the error rate of each locos receiver may take somethnig that is close and make them far off or the other way around. At first I thought clouds wouldn't matter but then snow does ruin satellite TV and water in the air does reduce the range of most RF signals but I'm not sure if clouds would affect the environment enough to cause enough change to be a worry, but I'm probably wrong. 

3a. Depends on where the tags are. I would opt for the tags to be under the tees in the center of the track. This way it would be impossible for a train on a different track to read an rfid not directly below it. 
3b. Central Command knows it's two locos, as it knows the length of each train. This one variable would have to be input into the computer so it knows the length on either side of the rfid reader. 

4. 1 
5. 1 

I'd be willing to give up some accuracy for reduction in complexity of the system. If I had to move sensors 4' apart that would be fine because trains don't stop quickly and if it passes a sensor command central could tell it to slow down and it can be crawling by the time it hits the next sensor and then do a full stop when it's on top of that sensor. If I need more accurate spacing in the future I think the rev counter is probably the simplest method for others who might use this system to build. I can't imagine hacking a mouse scroll wheel would be overly complicated and it's a cheap rev counter as one example of how rev counters can be done. For me, I'd stick to 1'-2' because RFID sensors are just $.30 on ebay for the 125khz blue eye key fob (though I wonder if these are water proof/resistant or if I'd have to use the glass encased ones which are considerably more expensive -- maybe I could get the blue ones and silicon around its seal and make it waterproof too). 

800*$.30 is 240.  If I went to 1600 sensors that's less than $500 for 6" accuracy and the detectors themselves do have a margin of error of an inch or two so unless I calibrated the margin of error on each rfid tag in the ground for every sensor and also measure each distance between rfid tags down to a 1//32" of an inch and have no wheel slip and the trucks are at the same position on a rail on every corner there will always be some margin of error. In railroading the accuracy only needs to be 1) far enough to keep two trains from colliding 2) close enough to queue up trains on sidings if that functionality is desired and 3) run enough trains on one line for visual pleasure. Some people could be fine with 20' of range between rfid sensors. Take roller coasters for instance, they know what block a car is in and even some of the newest rollercoasters are only split into 2-6 blocks as there is no reason for more than that for it's ideal 'functionality'. and 4) if using scenery like train stations you would need to hit platforms well enough and the most accurate scenario I can come up with is coal and other loading where you would need a couple inches of accuracy and for that situation a rev counter would be needed I believe. 

You could also put extra sensors only in areas where you need the accuracy but then you'd have to know the limits of where the sensor vehicle would be whenever in that area because if you ran a 40' train and needed 3" of accuracy you could have to put up to 240 (3*80') sensors as depending on which direction the train entered the loading area from you'd need that much range to be able to simulate filling every car. For me in this situation I'd probably just have an extra sensor car (if the electronics were in the loco and not a trailing batter car) that has a rev counter and keep it on consists where I want the extra accuracy. No need for general consists to have this level of accuracy.


----------



## VictorSpear (Oct 19, 2011)

Brandon, 

You've got to simulate your model before spending a dime. It wouldn't take too much time to get your scopes out and study the characteristics of your RFID tag across the middle of metal track and especially at the turnouts. Then compare it to the more expensive metal-embeddables. Also study it with both tags firing from the middle on two parallel tracks. You will see the difference and issues in minutes. 

Simplicity doesn't inherit from low prices alone. Even if the tags were at .05 cents a tag, your solution could be approaching a condition called 'sensory overload' where there is more noise than information flowing. Before you sprinkle your layout with sensors, why not start with the question ? 

Can I do this with 5, may be 10 ? How about One (1) ? 

And, don't use any 'track wheels' from the garden variety mice even if it is premium quality or you inherit for free. It will not work and collision is certain on day one. In this day of solid state optical sensors, banish and trash all moving parts in the loco other than the motor it comes with - just my humble advice. 

There are several more elegant solutions I'm aware of, but they don't use simple math and trigonometry, but more gadgetry. Works for some, others not.

Just to recap and focusing only on the location tracking I suggested a few low cost, low sprawl options:


1. A low cost synchronized micro rev counter kit and embedded data logger chute to track two vector movements. 


2. A micro optical photelectric sensor and data logger that is focused on a pinpoint on the track. Works even better that item 1.


3. A safe microlaser that does surface inspection sampling and creates small samples of track imperfections, digitized and indexed for reference. You can be a perfectionist and calibrate every tee or go for a snapshot every six inches during calibration. The loco obtains a sample from its embedded memory logger for the track *ahead *and compares with what it has just *crossed*. This is proactive sampling, the reverse being reactive sampling. Random samples checks requested by the loco every 10 seconds are sufficient for accurate reporting. Very similar to the old CD players oversampling. Amazingly. the dirtier the track, the better the hit.


4. Add a purely optional triangulating IR sensor beacon and increase by increments of one as needed. You do not need three of these to compute a solution.


*Unless you are competing with the Swiss railway*, item 3 will be impractical for most garden rail activity. We just use it for competitions.


Did you forget the KISS premise you started with already ? What about Keep it Super Simple ? 

Cheers 
Victor


----------



## Brandon (Jul 6, 2011)

Sometimes I really wish I had an scope, but that's not a piece of equipment I have lying around. 

I'll definitely buy some things in small quantity before I mass buy parts. I have all winter to test after all. 

So you think this wouldn't work? http://tinyurl.com/5wr8bpj 

The key fob tags are water proof (verified this by checking around). 100 of these key fobs run $26 shipped. Not bad, but as you said quality could be an issue. 

Most of my rfid research has been trying to figure out what real range and experience you can get from tags. Sadly people aren't posting experiences with range online except for some of the id-2/id-12/id-20 sensors from thinkgeek. In their tests the id-20 had the best range and could get about 4" on a rfid card. Button sensors were 2". I've measured the distance from the bottom of the tees to the bottom of the inside of a freight car and it was right about 2". Now obviously the plastic floor of a car and the tees between the tag and reader would reduce range but the question is how much and I think this will just take some testing to figure out but I might as well start with cheap rfid items and buy more expensive until I find something that works. I like the rfid readers that could be mounted to the underside of a car, hopefully reducing distance to 1" between tag and reader and I just hope it doesn't require me to put rfid tags on the top of tees, that would of course be ugly and not acceptable in my opinion. It's also hard to find information about range of various tags. There's no "with this type of reader it works at X distance" that gets marked on tag specs and I've had years of work where I used rfid tags daily and the 'butt to reader' usually works when keeping an rfid tag in a wallet but some days my aim must have just been of or something because it didn't always work perfectly every time and that's what testing will be for. 

For the cheap mouse I understand there may be better solutions, and for possibly the same price. Support for mice though is pretty universal so that could help others where they want a little more accuracy and if it doesn't work perfectly every time it wouldn't be a huge issue (aligning cars for station or something). 

My error checking to avoid collisions for a setup would likely include skipping or seeing an unexpected rfid tag, making sure X rfid tags are between any two consists (skipping 1 may happen, skipping 2 shouldn't and skipping 3+ would be really bad. Also I'd know what voltage a train was using and could calibrate mph based off rfid distance and trigger time so if a train didn't hit a tag in an expected time based on voltage I would know there is a problem. Adding a cheap mouse scroll wheel or other rev counter method would just give another check system for calculating speed and tracking distance that would be checked against other systems to verify things are working as expected. If a rev counter doesn't match when a given voltage, time an rfid sensor and history of performance any one of those could throw an error.


----------



## Brandon (Jul 6, 2011)

I really need to do more research on ir, micro lasers and other sorts... I just don't understand the accuracy and how they work and before I think it's too complex I need to understand them to really come to a valid conclusion. You're quite more versed in these technologies than me so please be patient as I go through learning pains and momentary frustration that it's over my head. Hopefully I can try all sorts of things eventually and help others be able to jump some steps that I can prove one way or another for the hobby so we can all get more accuracy and realistic running railroads that can operate themselves...


----------



## VictorSpear (Oct 19, 2011)

Brandon, 

Well said. The solution will reveal itself as long as you are seeking it. No one knows all the answers, none of us. Einstein's laws that nothing can be faster than the speed of light (1905) were challenged on Sep 22 of this year (2011) - less than a month ago. So all those who claimed they understood lasers, photons and optics knew something based on something that probably wasn't true ? http://online.wsj.com/article/AP58b5aed0a77c45ddb163d90951b36b35.html. The whole world of modern physics now wants verification. 

But thinking and self criticism is still free. Let' reconnect after your winter experiments and spar again. Perhaps there are cheaper, faster, smarter solutions than the ubiquitous RFID tag. 

Cheers 
Victor


----------



## VictorSpear (Oct 19, 2011)

The Journal relocated the article I referred to for reasons best known to them. The new article they posted is equally fascinating. The last line says it best. 
http://online.wsj.com/article/SB10001424053111903703604576588662498620624.html


----------



## VictorSpear (Oct 19, 2011)

I guess they want a subscription. But Reuters has the more descriptive narrative: http://www.reuters.com/article/2011/09/23/us-science-light-idUSTRE78L4FH20110923 

Cheers.


----------



## Brandon (Jul 6, 2011)

A nice vacation/break was taken, I feel better now So back to work on this project.

Victorspear: It will be interesting to see in fact if Einstein was wrong. His theories have done us quite a lot of good over the years and even if he's proven wrong, it took some time to prove it. I'm also not holding my breath as many times we've though things were wrong but it becomes a new way to understand how things really do work and how tests don't always produce the results we thought. 

So really back to the project, my first rfid reader and 2 types of tags have shown up. The one that came first was this one: http://www.ebay.com/itm/125Khz-EM41...677?pt=LH_DefaultDomain_0&hash=item4842594fb5


I have the 125khz key fobs tags and some key card tags. I've done a fair bit of testing and the results so far are good. 


Tests involve placing the sensor UNDER the ties, but between the gaps in the case of the key fob tags. 


The key fob (listed as either water proof or water resistant) pick up 100% of 200 tests at 3/8th of an inch above the track. 7/16ts goes to 94% and 1/2" is 67%. 9/16ths was only about 10% but I didn't actually do hundred+ attempts as it was so low. It's quite amazing how fine the hit or miss variance is. 

The key card hits 100% at 3/4", 97% at 7/8", 85%, 76% at 1" and 20% at 1 1/8". A more variance but probably still within the same % considering distance/scale of signal.


I opened the usb rfid reader (I should have taken pictures...) but basically it's a 2"x3" board with 2 very thin, probably 64 gauge or thinner wire, connected to a loop antenna that's 2"x3" and placed at about a 30 degree angle inside the reader (like // vs || inside the box). 

When I get the other readers I'll dig into them but considering the tests of this I'm pleased with the results. Even if I had to place the sensor outside of the case (which would increase range) and 1/8" above the track it would hit 100% according to my tests which would be most ideal.


----------



## VictorSpear (Oct 19, 2011)

Brandon,

The graphics output @1080p for the *pi *looks amazing. Haven't got the audio report from my colleagues yet. Here is the great* Upton* himself speaking in Cambridge English to a French reporter (who refers to it as the 'pee', like in French ) at the ARM 2011 if you haven't seen it yet. It is amazing what they have done with a limited budget and resources. The USB version of four of five years ago - do you know if they will ever re-intro that ? I'm thinking this version would make a great solution for a wireless remote Handheld controller where you could have touch graphics on one side and knobs/buttons on the other.

Cheers
Victor


----------



## Brandon (Jul 6, 2011)

People have been posting various lcd's that are close to the same size and could be stacked on top of the r-pi. Audio on hdmi should be just fine. There was a point where the analog audio out would be that of a FM radio but they've since solved that so it's CD quality. 

I've been working on a software design of what I'll be writing to automate my railway and have a good enough idea of how I want to do the basic architecture so now it's just a matter of picking a name for the project and writing the first code. Got any thoughts on a name? I've wondered about 'AutoRail' 'SmartLayout' 'SmartRailway' 'AIRail' (pronounced air-rail or are-rail maybe since there will be some AI in it), 

The basic architecture will be a very dumb client and the server tells everything what to do down to the particular diesel sound. All information about the railway will be kept in a DB so the (likely) the only thing you'll do on a client is set an IP (or I might do upnp) and the clients mac address is registered with the server and used for communication/identification. Lots more I can go into but instead of putting it on this thread I want to start a new thread for the software development to allow others to comment on what features they want so I know what's in store now and later for development so I don't code it in such a way that it would make what would have been easy to implement harder later. I want a solid API for this project so it can be built on and expanded. 

PS, as far as I've read the earlier usb version got left by the wayside and time was spent on the end goal rather than releasing that usb version. My guess is cost was it wasn't effective to produce for them.


----------



## Brandon (Jul 6, 2011)

VictorSpear: btw, is there any information about your railway online that I could look through? You're far beyond me in knowledge of electronics and G scale railroading so I'd be interested in reading the material if it exists. I'm also looking for various ways (or best way) to run the loco motors, lights and smoke (and aux items) and my knowledge of electronics stops at jk's and variable resistors right now. BEMF motor sensing, voltage measuring, wheel slip and other useful but 'miracle happens here' and all the various electronic threads you've posted on are just above my head right now so if you have any thoughts I'd be interested in hearing. Ideally something that was a USB device and I could write a driver to control everything and get sensing back would be ideal, but that's over my head by far to create a board. My best solution right now is a usb servo board ($20) to control something like an RCS esc ($90) and some usb relay's($10) that can handle 10amp for smoke/lights/etc. This gives no motor feedback or other potentially useful info so if you have ideas on something that a r-pi could work with and do controlling for loco's that would be helpful. I can do software, just not hardware... ... and I'm not expecting a solid answer now(although if you have any that would be helpful), but in a few months I'd like to be done past the 'using my hand to move a sensor car(s) to simulate train movements to test the software' phase and be able to use what could be the hardware I recommend for using the software I develop.


----------



## VictorSpear (Oct 19, 2011)

Most of my work revolves around University labs into applied robotics in aviation and dynamic supply chains - model railways are a fundamental platform for robotic sciences and many new robotic concepts have been seeded from solving problems in model railroad layouts. I work with fellow University colleagues in Europe, Asia and the US exploring radical and futuristic methods and intense robotic competition is what drives the fun. Due to limited budgets at the colleges, smaller layouts are the norm where the experiment is conducted and then recycled for a new one. In the US, I recommend joining or visiting my favorite layouts, even as a guest. 

RPI (Intensive history oriented approach - from Steam to today)
MIT

And also closer to home base - NYU's ITP communities. Simply hanging around the coffee shop is where ideas are exchanged. Other work involves working with Universities on large scale simulation exercises using open source concepts: OpenTrack and RailML. Working closely to examine and re-define the Command & Control precepts requires a total remote control environment. Currently we are designing prototypes for 'command *with *control' aboard remote vessels. If you are considering your own implementation of a model railway, look closely at today's European prototypes and simple RailML for messaging. And, look at the robotics world closely to see how far advancements have been made. I can provide some examples, if you open a thread on robotics for model railways.


----------



## Brandon (Jul 6, 2011)

Great reading resources, spent a few hours tonight reading and will do more in the future. Too bad one site is re-working itself and you can't even sign up for paid access right now to see stuff. OpenTrack looks very slick, I'm wondering though if it's overkill for what most people would want in G scale railways. I'd be curious though how easily the simulation piece could be swapped out for a model railroad but considering it's not OSS I think the answer would be impossible. RailML is really nice to see. I've gone through a few dozen xml files and it's very detailed. I think quite a bit could be learned from that but as-is I think it's overkill (aka too complicated for an average G scaler to come up with all the specs) but a toned down version is what I had in mind for my software. I'm working out in my head how to have basic, normal, advanced and expert way of using the software so someone could just start by doing beginner and just use a tape measure to find the distance to the front and back of the consist and let it go and up to expert that would allow someone to come up with xml time tables and other more advanced setups. Trick is making the software usability functional to different groups of people. MIT's setup is very fun to read about but 50 blocks isn't something an average railroader would be interested in doing on their backyard, they probably just want 1-3 trains to run on their own. 

I'd be curious if you know of someone who already makes or could ping anyone who would be interested in making a usb card with at least one 15A+ motor circuit (with all the feedback circuitry useful for a loco but I'd personally like to run up to 5 locos in a consist which I'm not sure would be past the ability of the circuits to monitor that many motors in parallel), 5qty+ VDC pins with maybe 5v or 12v (TBD) 5A+, enough for several light or smoke units (and enough amps if you're running multiple loco's off one battery car) and third, maybe a couple PWM pins for people wanting servo connections. 

PS. I'm in the US mountain region and it seems like there isn't anyone around here doing stuff like European and East coast universities. What fun it would be to visit some of those institutes and talk to the people who are working on projects there...


----------



## VictorSpear (Oct 19, 2011)

You wouldn't really need all the functions of the OpenTrack software but you can get the simpler, general ideas for your model - Timetables are relayed to all trains and delays, accidents, changes, track slip conditions, rain, debris, ... are dynamically propagated in real time. Trains do their best to keep schedule taking into account the hindrance factors they received. Every train reports back speed, acceleration/retardation (defined as the rate of change of velocity, not just speed in steps), power, consumption, location,....Every station and siding confirms the arrival and departure of trains. By using RailML for a simple timetable that you broadcast to trains and stations, you've set the network schedule requirement (Command) for the day's work. The trains are expected to follow this and self-adjust by accelerating or retarding...to adhere to schedule. Now did you not indicate that you wanted to sit and watch trains run by themselves  ?

Note that this is a little more than a back-emf measurement to adjust chuff synchronization with a sound decoder. This is fleet synchronization that can scale from 1 to n trains. A two train garden layout is also fine.


With the XML format messaging exchanged with the engine, the software aspect of Control now takes on a dynamic dimension, unachievable in todays decoders with limited functions. Your R-pi comes in handy.


If you are seeking a USB supported control (why USB ?) , you could start with the Pololu Jrk controller with feedback. It is little larger than the size of a quarter (25 cents US) and provides the ability to customize your own features/functions or expand it. To allow this, it ships non assembled I believe. It supports up to 3A continuous/5A peak and can get you started experimenting in less than an hour. It does have an RC PW interface built-in. Why on Earth (or Mars, the next stop) would you need 28 A on board ?


In case you are in Boston, you should visit the MIT club on Wednesdays (7pm onwards) or Saturday afternoons when you could go out for dinner with the members at the nearby Chinese restaurant. AT NYU, the City never sleeps.


Cheers,
Victor


----------



## Brandon (Jul 6, 2011)

That makes more sense. I thought you were pointing me to OpenTrack as something to implement to rather than use as potential guide for architecture. 

Is there a reason that stations and switches would need to confirm trains passing? I'd think this could be simulated in software by the master control system just fine. With this same concept of the master controller handling things, is there a reason to have the locos (or battery car per consist) thinking for itself? The more systems that think for themselves independently the more difficult the logic would be and potentially the amount of hardware needed to operate the system per consist and the more bandwidth (and power use) needed to send all info to each train vs just sending very basic info when needed to each train. 

There is something to be said though for having each train think for itself and as much as I was set on thinking a central command to operate everything was the best idea (and using the trains as sensors and movable items of the 'central/main robot' I do like the idea of having each train think for itself. There are quirks to having each train think for itself, such as having to update software, config files and so on for all trains for any changes vs if the software on each consist just sent location, velocity and acceleration data and received the same info back with added sound and whistle ques it would rarely need updating and you would only have to reload one systems data which might be more attractive to less tech savvy railroaders. What would your arguments be for either of these methods, taking into account some railroaders might not be as interested in the autonomous functionality as much as they just want to see several of their trains run without crashing into each other? 

I'm now wondering if maybe I should write a simple software layer that simple exposes sensor data and takes hardware commands for the train and then write 2+ completely independent pieces of software that use this layer. One piece that is very simple and operates like a master controller and another that allows each train to think for itself and would run on each consist... 

Soap/xml/REST are all potential methods of passing data. All could work so it's just a matter of deciding which fits the best and allows for expansion of features that people may want later... I've worked with soap and xml a fair bit but REST is new to me, I did some quick reading and I see why it could be a good fit. I do like to keep things simple which is why I often like to start from scratch and leverage pieces that fit perfectly and don't add overhead or additional complexity that could fail functionally without an easy way to solve the design flaw. 

I agree though that hardware like r-pi, beagleboard, arduino and pic's are a much better way of getting more out of our locos and railways which is why I never thought dcc or revolution would make me happy in my railroading hobby. Movement and living devices are what I find the interesting. I was hoping for all that control in one usb board as the more devices you have there would be more hardware ($$ cost and occupied volume in the host vehicle) and software (time for development) needed. That many amps does sound like a lot but it's a 'fits 99%' of what people need. One SD-45 can use over 3-4 amps alone (and I'd like to add ditch and other lighting to the loco's on top of this), put 2-5 of those in a consist and you need a lot of amps or a controller per loco and the cost effective way for someone like me who has about 30 locos would be having 5-7 battery cars that I can attach to any combination of locos to save cost and time. 

I have looked at the Pololu Jrk's, they do have some that go up to 25amp (not sure if it has all the feedback circuitry though) but rather than trying to stuff 5-7 different boards in a small space if there was a single board that did what 99% of most railroaders want in a single board it would be helpful. 

I'll keep the MIT club meets in mind. One day I'd love to tour that campus and everything, it's not exactly a weekend road trip though... I'm sure just about everyone there has already gone through the same thoughts I am now so it would be fun to talk and discuss all this face to face.


----------



## Brandon (Jul 6, 2011)

Well add this to the r-pi toolbox... http://www.raspberrypi.org/archives/411 The Gertboard, looking at the board it has 2 motor controls, at least 50 io pins and is being designed for the r-pi. It might be pretty easy to add all the components needed for a loco on to this single board, only problem is I'm not an electronics guy so figuring out what would be needed might be out of my reach. If there are any hardware guys who might be up for the task that would be helpful. 

Also I've been looking at the teensy: http://www.pjrc.com/teensy/index.html Very simple but could be a solution for lights on a loco and smoke, but I'm pretty sure it can't handle the current needed.


----------



## IPTRAIN (Jun 1, 2012)

Sorry,

got the feeling, this post TCP/IP over WiFi to control a GardenRailway via Radio Mobile DirectLink should be moved into here.


Have fun,

Regards

IPTRAIN


----------



## jbooker (Jan 15, 2008)

Ran across this thread today. Very impressive discussion of location tracking etc. Must admit I skimmed some of the details, but think I got the ideas.

I would interested to know what became of your ideas, Brandon. 

I am have some of the same problems to solve. Being a software developer (and not an electronic engineer), I want some level of computer control but mostly want to track trains without block wiring. 

It seems to me multi-train control and sound are handled pretty well with DCC, and there are some nice software interfaces available to do the programing assuming we have the inputs to work with. 

I'm leaning toward going with digitrax and use this software which has a nice scripting api and underlying assemblies can be used in your own custom software too.

http://www.perecli.com/rrauto/

The main problem with DCC (absent block detection) is the lack of feedback. Though I've not tried it, digitrax transponding does not have great reviews and the only guy using it outdoors has vanished from the hobby. That said, before his disappearance, Bob Grosh did share a nice theory which you might find interesting about how software can 'learn' a layout and track trains with only three feedback zones:

How Does First Zone Work?

My feeble minded understanding: If we could simply know for a given train, when the loco and caboose cross each boundry in a 3 zone loop - combined with 'speed' of said loco - we'd have all the inputs for a software program to do the tracking using Bob's self described 'Fuzzy Control Language'.

Now back to the missing part - feedback. I don't think we'll see much advancement in this area in DCC and feedback over rail just hasn't happened so lets do it ourselves. I think your on to something with the inexpensive RasPi. If it were me I'd avoid complete train control and leave that part to the DCC companies (baby steps you know) let's focus on the feedback. 

Anyway let us know how you made out.

TIA,
Josh


----------



## Brandon (Jul 6, 2011)

Things have progressed pretty far, but I've been on hold waiting to finishing my layout as I've had many parts that are quite involved in building/construction.

I'm also waiting to see what power control options there will be as there are quite a few changes in the hobby lately, spurred by RC developments.

For software, I have everything written to learn a track, control a train (including sound, movement, LED's and smoke), and actuate switches. I have yet to write the full AI "run trains" code because I'm still finishing my layout and that is the more rewarding mechanism to work on that part.

My current develop setup consists of a r-pi, pololu usb esc, usb rfid reader, wifi usb dongle, and relays controlled by GPIO's for LED and smoke. I'd like to find a better alternative to the pololu esc though as this is the most expensive component at $40 each and doesn't support as much feedback as I'd like (don't get me wrong though, it gives voltage(or was it amps) and other kind-of-useful information, but not rpm which would be helpfu to reduce the number of rfid tags or a great BEMF for very low speed movement).
I have 48 pneumatic valves being controlled by solenoids controlled by a relay bored controlled by a r-pi (running the server software). I have a html5 app that talks websockets to the main railroad server that then controlls the gpio's for switching the pneumatics to control all the switches.
This year I will have the switches and the track running on track power for certain but the rest is an unknown. It's likely that over the next winter I'll be putting together final hardware in 20+ locomotives and working on sound frequency to mimic real sounding load and movement. If I stay with r-pi in the locomotives, all the software for running the trains, horns, led's, and so on I'm set, but I'm hoping someone makes a sub $50 all-in-one device I can use in locomotives instead of what I've done (not sure that will happen though) and at that point I'll have to adjust the communication protocol of course from the server for the end point hardware. Right now it's just tcp sockets for transmitting location from the locomotive to the server and the server telling each locomotive what to do. There's of course fallbacks on either side to handle if a train goes silent or the server does as well. Lots of little bits are done and working on a test setup I have. I personally plan on running the layout in
AI mode 90% of the time, making it be it's own living/learning entity. I however will have an html5 UI that you can take control of any train at any time and the AI system will run the other trains on th
e track around what that human controlled train is doing. 

Hope this gives you an insight into what I'm looking to do, how, and where I'm at.


----------



## jbooker (Jan 15, 2008)

Thanks Brandon for the update. Sounds like a really nice setup you're working on. I'm just getting started on train control and am pretty much convinced DCC is not the right tech for me.

We do have computer controlled pneumatics for turnouts using DCC, but stopped short of installing DCC in locos and definitely won't be block wiring outdoors for detection - currently have nothing in the works for location feedback.

We to are in a holding pattern awaiting release of some of the promised new tech such as that from Victor Spear's pals at Turret Robotics which they say will be announced at Denver show in July.

Being a software developer and not a electronics engineer, I like the idea of a Linux board on each loco and another board or PC as a central controller. Be they RPi, Arduino or BeagleBone. 

I like the idea of WiFi 802.11 rather than other RF options because it's everywhere - built-in to so many devices.

We agree that one important thing to nail down is the communication protocol. Be it RailML over REST or sockets - lets do it in an open and collaborative way.

I like HTML5 + javascript for UI tier - no love of native apps for android or iOS. All devices run HTML5/JS and the request/response nature of http is a perfect fit. REST / sockets is a common bi-directional pattern in web apps. 

JS can also run on the 'server' with node.js. I ran across a nice node.js framework for robotics here: http://cylonjs.com/

You'll def wanna check out that site if you havn't already. It's an open source js framework for controlling 35 different platforms including Beagle, RPi, Arduino and many more. Plus it's architecture enables devs to add devices and components should yours not yet be included in the framework. 

The IoT arena has a lot of steam right now and I'm happy to see such an open framework is actively/collaboratively/openly being developed- seems like all parts are converging to make model trains - large scale at least - 'internet enabled'. 

Maybe for the first time - large scale train control is poised to be many steps ahead of the smaller scales. IMHO, that should make up for the rather dismal advancement applicable to G-Scale we've seen from the DCC companies for the last decade.

My hope is that we'll see more info on the Turret Botics - Digital Rail System on their website (http://turretbotics.com/) later this spring - leading up to the summer release.

Furthermore, I hope their implementation is highly open and documented. Allowing for collaboration - especially on the software side but also hardware. I would think a company could disclose (and sell) all the components/ 'how to' for DIYers and still make money selling 'Inteli-Car' PnP kits - as there will always be a majority of folks who just want to plug in and go.

Keep up the great work!
Josh


----------

