http://DansDepot.railfan.net
Autumn :Home Electronics
| Last Update |
|
Project Cancelled
Project DiaryThe Problem Structure FAT Controller Loco FAT<->Train coms Location&ID Point Motors Signaling Test Layout
http://DansDepot.railfan.net
Autumn :Home Electronics
| Last Update |
|
Practical demonstration of computer information packet transfers using model trains for Monash University's (Clayton) Open day August 2003
As a general design principle, considering that this will be operating in a hostile operating environment with little time for heavy testing and refinement, I suggest that as much logic be implemented in the fat controller as possible - improving the chance of being able to fix things on the day. Also, every actuator in the system needs to have pain and proprioceptic 'nerves'; that is: If we can detect an error condition, be able to report that back to the Fat Controller. If we can detect position, send that back to the Fat Controller (perhaps it can take evasive action).
All operations are controlled by the 'Fat Controller', a modern PC equipt with appropriate interface controllers. The Fat Controller is a Linux based machine running Debian. I propose we use mec-symonds as the test rig. The train status will be displayed using a python based gtk interface.
We need to be able to talk RS485 if we use that for point motor control. Also we need to be able to listen to all the bar code readers, and talk to the loco(s) over the wireless link.
Currently I foresee the need to use real time linux to handle the running on the train, and even if that isn't necessary, it would be good experience for more serious applications later. Charles: this is your domain.
Estimated loco properties for back of the envelop calculations:
| Measurement | Estimated value |
|---|---|
| maximum speed | 1m/s |
Choices
I(njh) am currently tending towards feeding in a high (safe) voltage, say 24V DC, and rectifying and switching it down inside the loco. There are 2 separate power issues - a) power to drive the motor and power for the brain.
Power for the motor can be simply driven with an H bridge directly off the rectified incoming power, and switched at less than 50% and a reasonable speed (25kHz) so as to not fry the motor.
Power for the brain can probably be done using a COTS switchmode regulator chip, such as the MAX666. Noise will be an issue.
We can do this because we already need a bidirectional communication link for other parts of the design, so limiting the rails to power will probably pay off in simplicity. In our current design there are no reversing loops, so all the trace can be wired together, simplifying the design. Clearly, were we to add a reversing loop, or a wye, some attention will need to be paid to how we handle the polarity switch.
Choices
Charles Grief to investigate.
The basic idea is to feed a 50% duty cycle PWM 24v dc to the track.The "on" period being used to power the motor. In the "off" period, communication data will be allowed to flow between train and FAT. At 50% the average voltage to the loco would be 12v, so in order to control speed, the locos internal smart bridge, will cut short the power pulse.
| Abv | Measurement | Estimated value | Formula |
|---|---|---|---|
| sw | sleeper width | 3mm | |
| gw | gap width | 7mm | |
| ts | Train speed | 1m/4sec (nom) | |
| sleeper uS | 12ms | ts/sw | |
| gap uS | 28ms | ts/gw | |
Points of note (nodes) are detected with the locos position sensor either using barcodes or special sleeper/gap ratios, sub positioning is done through sleeper counting.
We may end up with many nodes and thus many readers, so cost and complexity are important issues . Various IR sensors were tried keeping in mind we were solving two problems. .
A convergence type reflective IR Photo transistor is fed into and amplifier and comparator. The Comparator is set to trigger on the amplified and cleaned IR pulses from the sleepers(in train location mode)or bar codes under the trains(in train ID mode). We tested the sensor on a drill chuck simulating speeds far in excess of any model train, and the usual nasty electrically noisy and ambient lighting conditions. Distance from the target was difficult to obtain as most sensors are expecting minimal clearances. Here we have about 5mm. The PCB will end up in the loco and or cars (sleeper counting mode)and of course under the track pointing up scanning train(larger than life) bar codes. Eventually they can be surface mount. The two blue trimmers adjust (left) LED current and (right) comparator trigger level.
The bottom trace is the signal after high amplification. The top
trace is the cleaned comparator output. Comparing it with the picture
left you can see the 3 white lines on the chuck and how they have
produced the "pulse g..a..p pulse gap pulse g....a......p
. " Pattern.
The signal generated by the sleeper counter will be noisy, and reliable removal of the noise will depend on having an idea of what that noise will look like. Because of the need to tune the information, we need to get as much data out of the loco as possible, and move the position calculation code into the Fat Controller.
The incoming signal is correlated with the known pattern to reduce errors. Its expected that tolerances in the sleeper/gap widths and idiosyncrasies like points, crossovers, bridges etc will help the pattern recognition software to deduce the locos position instead of relying on simple sleeper counting. This way it should be possible to pick up the loco and place it anywhere on the track and after some movement the FAT controller should know where it is.
It may be worthwhile building a wire based loco<->computer link first while we procure a wireless solution
I propose that the signal be sampled at (1m/s) * (3/cm)*16 = 4800Hz, which should correspond to 8 samples per sleeper(200us/sample). Hopefully this will be enough to remove the noise from the signal but retain enough resolution to correlate with known track data.
Very good I must say. I tested the sensor on 3 different track underlay's without re calibrating the sensor. I admit its probably working more like a depth or distance sensor. above "Grass" was the most troublesome but over black sandpaper (road) and just plain wood it picked up the gaps between sleepers fairly well. This test was however conducted by hand and the distance ones hand can maintain over the track isn't conclusive. The sensor really needs to be mounted on a loco.
Well the wheels fell off so to speak. The system was tested under these conditions.
This caused some problems in power fluctuations at low speeds. Mainly because the IR LED draws more than can be stored in the tank capacitor. A bigger capacitor is required. This may not be a problem with the PGC implementation.
The various sleeper backgrounds caused problems. Simple wood seemed to be reflective while the sleepers werent but then fake grass and road was non reflective and so no pulses were seen. Its possible some more fiddling on the hysteresis and trigger limits may help this but it didnt look encouraging.
This certainly helped but as I only had small amounts of each track backgrounds to test on, it was all over too soon. I almost need a PC storage cro to record all the events like a real long oscilliscope trace.
bmo. came up with an idea that got me thinking it maybe possible again. We are currently pointing the IR directly downwards and thus if the sleeper backgrounds change it adversly effects the sensor reading. bmo mentioned what about trying to point it at and angle so that the sensor either sees the top or side of the sleeper. this may also solve problems that may arise if the loco went over a bridge etc
The barcode reader points up thru the track at the bottom of the cars where it reads a larger than life bar code painted on the cars underside. This code(format undecided yet) is sent back to the FAT for ID recognition.
Not good I'm afraid. The rolling stock(cars) we had did not have flat bottoms. This meant that the distance from the ID sensor(rail level) to the flat bottom areas where the bar code was, was an extra 5mm on top of the 5mm rail clearance. This pushed the ID IR sensor to its limit and presented a new problem. With the sensor at "full stretch" it was seeing reflections off the undercarriage, purely because they were, now "close". I also noted that with the ID IR sensor at full amplification the background IR (lights etc) were indeed beginning to intrude on the signal. The loco was now a problem also as its undercarriage was far closer to the rails, ie there was hardly any rail to undercarriage clearance. In this state the ID sensor always saw a reflection for the locos entire length whether the undercarriage was coded or not.
Capacitor discharge with FET switching. There is a working implementation of a relay switched design, but I suggest we change to using some power FETs for the switching. These will give a faster rise time, and are more robust against things like contact welding. Also important is the ability to switch them off once the point motor has snapped over (we need a way to determine this) thus requiring less time to recharge for the next operation.
We ran out of dynamic range:(
We probably need a multihomed bus for the bar code readers, so I propose that we have two nodes, one for each yard, consisting of a PIC with an RS485 transceiver, and the numerous port pins connected to the various switching devices to drive the actual motors. The PIC could handle the checking for closure, indicating back the server when the operation has completed or failure.
Issues:
It would be elegant to simulate proper signal protocol when moving the trains around. I believe that AJH knows how this works, and should advise what is required. If we make it interesting with multiple trains, and our current method for noting train position, true safe working will actually be required (because we can't avoid collisions otherwise).
I think that the normal 2 block method with trackside indicators for point position will probably suffice. Wasn't someone going to get some flyovers or bridges built for the cabling?
Many thanks to Dan for his train bullets