Defining automation terms.

This is going to be another nerdy post. So first, just so this isn't a wasted visit, here is little clip I took years ago with a Mavica camera. Not good by today's standards, but sorta neat just the same.




A lot of what I want the ALLY to do has not been done before. (At least NOT in the way I want to do it.)

As a result, I had to make up some new terms, or apply terms not normally associated with DCC within the context of what I am doing.

I'll probably have to edit this list from time to time. A lot of this post will deal with subtle distinctions between different terms that might seem to mean the same thing, but really have different meanings here. For example "Speed" and "Velocity"

DESIRED SPEED
Desired Speed is a number between 0 and 100 inclusive. It is a percentage of the maximum speed a loco will travel. Desired speed is the speed set on a throttle. It is not linear, so a throttle setting of 50 does not mean the loco will travel at half speed.

SPEED
Speed an unsigned number. It represents the time it takes to travel a distance.

REAL SPEED
The real speed is the distance a car or loco will move in a certain time. Internally, the software uses Ticks as a unit of time, and Fuzz as the unit of distance. When the real speed is displayed to a user, the speed is always converted to minutes. A speed of 2 FzPM means that the loco is traveling at two "First Zones" per minute.

TICK
A tick is usually 100 milliseconds. Loco positions are re-calculated once every tick. The system can alter this time depending on the processor speed and number of cars and locos being tracked.

FUZZ ( or First Zone )
Fuzz, (abbreviated to Fz), stands for First Zone. It is a unit of measurement for length. All internal calculations for length, speed and velocity use the length of the First Zone. The First Zone traveled through by a loco after a system reset always has a length of one Fuzz. The speed of a loco is then calculated in terms of how long it took the loco to go through the First Zone.



If the loco took 1 minute, you could say its speed was one fuzz per minute. The system measures time in ticks, typically 10 ticks per second. So, the system records the speed of one Fuzz per minute as 1/600th of a Fuzz per tick. ( 0.001666666 FzPT) The physical length of First Zone is used as a constant. The First Zones length will not change (other than a insignificant thermal expansion). All other zones are measured in in terms the First Zone.


Note: The software, when running on a PC with a display, will show speeds and distances in terms of Fz's. However, the system can display either real or scale distances and speeds in English or metric.

There are two methods to accomplish this, both of which are optional and not required for the system to operate:

• The user can enter a measurement for the First Zone into the PC in either feet, inches or meters. The software will then display actual speed in feet, inches or meters per minute. If the user also enters the scale ratio, the the system will display the distances and speed in scale distances and speeds.


• These two values can be detected without the user input, however, that requires a loco or car with an SFX sound decoder, a working chuff cam input and a custom program. The decoder will provide actual measurements and the scale ratio to the system without user input.

Using either method, the system would then be capable of displaying scale speeds on a DT400 display. However, the current DT400s have a bug which prevents updating the display, Hopefully, the new bi-direction radio throttle will have that bug corrected.

VELOCITY
Velocity is a signed number that is time, distance and vector dependent. Since a train is on rails the vector is always positive or negative. A positive number means the loco is going in the Normal Traffic Direction regardless of the locos direction of travel (FORWARD or BACKWARD) of the locos orientation on the track. When a car or loco exits a reverse loop, its vector is multiplied by minus one (-1). A car or locos position is update once each Tick by adding the velocity to the current position. The system uses a different unit of measurement for distance, the Degree. The degree is 1/360th of the length of the longest loop as measured in Fz. Velocity and Position are both elements of a fuzzy set. They include both a membership value between 0 and 1. This as to say that each value also has accuracy values associated with them so that they can be adjusted over time to become more accurate. Several techniques adapted from FCL (Fuzzy Control Language) are used to speed up the process of getting accurate measurements of the layout and the real Velocity Tables.

Distance, speed and velocity are all fuzzy numbers. That is to say, they are represented by an array containing additional components that vary from 0 to 1. These have to do with the accuracy, reliability, and repeatability of the measurements. The accuracy of a locos velocity is inherited from the measurements of the Transponding zones. The accuracy of the position is inherited from the accuracy of the decoders velocity.

Animation
Turning on or off lights, smoke and sounds to make operation more realistic without botherin the operator with all the details.

Automation
Taking control of a train.

Helper Application
Assists users by providing warnings or optionally, slowing or stoping a train to avoid mistakes.

Software History

If this is the first time you visited this blog, you might want to read these posts first:

• Hunting for the DCC system of the future.
• Robotics and DCC.

I am now writing my fourth generation of software for the ALLY.

VERSION 1
Version 1 was written over 10 years ago. It did a fair job of automating a couple trains while other trains were controlled by users. It was mostly hard coded to one track plan and used Transponding as its only requirement.

VERSION 2
Version 2 was a complete rewrite using the same programming language. It incorporated the ability to "learn" the track plan. I also had a pretty good idea of the types of automation and animation I wanted at it's onset so it had quite a few cool features. Its biggest fault was that it was started using speed rather than velocity as the method of tracking train positions. It had to rely on kluges in the code to determine direction of travel when a loco's orientation on the rails was swapped, as a result, it was unable to handle reversing loops. My solution was simple. I removed the reversing loop from the ALLY.

VERSION 3
Version 3 was a total departure from previous versions. It used the Java scripts and JMRI for the operational part of the program and used my favorite Windows programming environment to configure the scripts. Version three used zone influence for a lot of it's capabilities instead of tracking individual loco positions in each zone. This was easier to program in JMRI but required more zones for some features. Where versions 1 and 2 could automate the whole ALLY with just 4 zones, Zone influence required 12 to 16 zones. A new concept incorporated in version 3 was the idea that each decoder acted like a robot. Robots could have pre-programmed behaviors. They learned how to apply some behaviors by watching the human operators. Robots could also perform "scenes" in a "play". Scenes can be triggered by "event messages". Event massages can be sent from; The fast clock, a loco, a decoder equipped car, entering or exiting a zone, or a function key or a change in speed. Version 3 also incorporated the ability to build a list of decoder equipped cars behind a loco. This was very slick. Couple a loco to a string of passenger cars. Pull out of the siding or through any gap between zones and the loco would have a list of the cars in the order they were connected. Each car also knew which loco was pulling it, it's location on the railroad and it's velocity. This opened up all sorts of cools animation features for the lights and even sound cards in the cars.

The multitasking nature of JMRI was a plus in some respects but eventually I decided that multitasking was also going to make it impossible to control more than just a few decoders at one time. Commands sometimes arrived at the decoder out of sequence. Opening and closing multiple throttles for every decoder equipped car and loco on the ALLY often got out of sequence due to the length of time it took to get slot information from the command station. This isn't a fault of JMRI, so much as the natural result of multitasking when there is not an acknowledgement for every command issued. With only a dozen decoders being tracked, I found that the slot table was often getting corrupted and I had to reset the command station several times a day.

VERSION 4
Version 4 is another complete rewrite. I'm incorporating the better features from versions 1 and 2, translating all of the features in version 3 from JAVA to a windows based development platform. I'll incorporate an IP based interface to JMRI so that some of the features of JMRI (running on a separate computer) can be accessed.

New to this version will be the "Zero User Interface" concept.

That is to say that, the system can installed on a single card PC. Then it can be connected to, learn, and run, a unknown layout without the need for a keyboard, mouse or monitor.

Of course Version 4 will have a user interface, but the interface is more like a user instruction manual, robot teaching guide and system monitor.

It will also provide extra utility throttles, and a drag and drop robot behavior editor for those interested in customizing how the animation effects work.

The next post will cover some terms I have adopted. If my use of words like "Zone, Segment, Degree, Tick, etc that confuse you, then read the next post.

What can train robots do? (PART 1)

I've been asked about using a computer display of the railroad, so this time I thought I'd show something with a display.

[left] Here is my son Dan. He is an HO model railroader. He does not have a layout yet, or DCC.

Looks like he is having fun.


[RIGHT] A closeup shows he is using two wireless Digitrax cabs (four throttle knobs) to run four trains.

Below is a nice picture of Dan checking the progress of a F3 AB, you can just barely see the B unit at the upper left edge of the picture. He is also running the steamer just to the right coming toward the camera, and the two entering and exiting the field of view in the lower left.

Two other trains were being run by collision avoidance robotic control.
Here is a screen dump from the old windows 98 PC that was controlling the robotic trains.
This was my first generation control software. It used way points to calculate speed to estimate the position of each train. Accuracy was within about two feet. Trains could be controlled manually, or , by turning on F9 the robot would take over.

The robot avoided collisions by restricting the distance between it and the rear of any train ahead of it. The minimum distance that it would approach the train ahead was determined to be half the distance between the robots caboose and the train behind it. Another way of understand this is; A robot subtracts the length of all the trains on the track from the length of the track to find how much empty track there is. It divides the track into thirds. It divides that by the number of trains on the track.

When there are only two trains, that resulted in the robot keeping about one third of the empty track between it and the train it was following. Double that to four trains and one sixth of the empty track will be the minimum distance for following. We ran 6 trains at once, so each train had a 1/18 if the empty track as the minimum. The trains totaled about 30 feet. The main is about 235 feet. Divide 205 feet by 18 and we had an 11 foot minimum. With an accuracy of two feet we have a eight foot margin of safety.

Here is a diagram showing the relationship between the picture and the computer display.

The robots don't just stop when they hit that minimum distance. You won't see them waiting for the engine ahead to clear a block like they do on a conventional block system. Instead, they try to run at whatever speed they have "learned" from a human operator. They slow down in yards or the approaches to tunnels. They will never go faster on any spot of the railroad than a human has driven. ( It's one reason they never run off the end of a siding unless some human went faster than speed zero off the end of that siding.) Instead, Robots run at the "learned" speed as long as they are in the rear half of their share of the empty track. They reduce their speed in proportion to the where they are in their share of the empty track. The closer they are to only having one third of their share of the empty left, the more they slow below their learned speed. They only stop when the train ahead stops and the robot has used up two thirds of it's available space. If the train ahead is going slower than the speed that the robot has learned, then it will gradually match speed with the loco ahead.

The result is a very pleasing appearance. Locos don't appear to be playing follow the leader, nor do they stop and start except when they need to stop at a station or passing siding.

One side effect has to do with very slow moving locos. My shay, for example, has been "taught" to go very slow. Just like a real railroad, it will eventually have all the other trains bunched up behind it. You have to teach the shay to pull off at a passing siding and let other trains pass.

On future versions, I'd like to make the robots smarter and identify when they are clogging the main and then identify the next available passing siding that is (1) empty, and (2) long enough for it's cars. Then, the Shay would allow other trains to pass, even if the operator had not told the robot to stop periodically. The other improvement is to have the robot wait until all the jammed up trains pass before going back on the main. Currently, it only allows a fixed number of trains to pass before pulling out.

Dan spent about four hours running trains that day. At one point we had 7 trains all running at the same time. There were no mishaps. It was a fun day.

A lesson on "User Friendly"

I've made a living creating easy to use systems for various government agencies. I've employed touch screens to build user interfaces that require zero user training. Just when you think you have made an idiot proof system, someone will prove you wrong.

Here is a little example:

I developed a high definition video arraignment system for a county in Alabama.

It worked a lot like a video phone with speed dial buttons to call the other locations.

We had just upgraded our system to use a touch screen instead of a mouse. It seems that many of our customers were not comfortable with mice. It only displayed buttons on a touch screen when they were needed.

While installing the system, I used the system to make a video call to the courthouse from the jail. I was sure there were people at the courthouse.

They didn't answer.

I asked someone at the jail to wait 20 minutes and then press the "COURTHOUSE" button on their touch screen.

When I got to the courthouse, I waited. At the appointed time, the speed dial buttons disappeared, and the touch screen displayed:

INCOMING CALL FROM JAIL

Press the answer button to accept the call.

[ANSWER]

This was displayed in red letters an inch tall over the incoming video from the jail. The speakers played the familiar old fashioned ringing sound over and over until you touch the [ANSWER] button on the screen.

I asked the worker, who was in the room, if she had heard that ringing sound earlier, She said; "YES"

I then asked why she hadn't answered. Her reply; "I couldn't find a mouse or keyboard".

Of course, she was not trained, I thought it was so simple that we wouldn't need to do any training.

When I looked at the screen and re-read the prompt, I realized what an idiot I was.

I changed "Press the answer button to accept the call."

To read " Touch this screen to accept the call."

Of course, I also had to make the whole screen active, not just the single [ANSWER] button. I also had to rework several other screens.

The point is:

You don't build user friendly DCC systems by turning over prototypes to a core group of "Beta Testers" or customers who are advanced DCC users.

You learn how to make user friendly DCC systems by handing them to kids who can't read, railroaders who have never used a DCC system, and railroaders who are technophobic.

For today's post, I think a video is in order.

The video is called CHAOS.

My granddaughter, Ally, invited some new neighborhood kids to play with our trains. She was 10 when this was taken.

Ally did all the operator training. She even operated my new camera to capture this video.

In fact, I didn't know she was doing this until she came in to tell me one of our four "visitor" throttles wasn't working. (I had run over the long cord with the lawn mower.) I had find a short throttle cable to connect the throttle.

I made it a point to not say a word to her visitors and let Ally handle everything. In the video, you will see me answering a little girl's question with hand motions. She wanted to know which way to turn the knob. That was the only help I provided.

You will notice that things seemed very chaotic at first, but, toward the end, things settled down.

Ally managed to provide them with chairs, and even served them sodas. After about four hours, they were running four trains at once. They were operating a passenger train between the two stations, and were just getting their feet wet with switching operations and moving loads from one siding to another.

In all, they had a lot of fun, and it was educational for me to watch how Ally handled the whole visit. The boys have been back since and actually volunteered to rake pine needles from the tracks.

Robotics and DCC.

What if we had a little robot in every loco?

Today, there are a lot of very smart little high tech toys that employ robotics. We also have vacuum cleaners and lawnmowers that are very smart.

Robots are aware of their surroundings and react to them. You can buy a robot kit from your local Radio Shack. I got one just to learn how to program the processor. It's amazing to see a little robot avoid obstacles or follow your movements as you walk around. Even more surprising is that the little kit can "see" without some expensive camera. Using just one simple photocell, and two LEDs, it can tell if an object is directly ahead, a little to the left or right, or a lot to the left or right. It can also tell how far away it is and how wide it is.

Today's robots use very simple sensors and a lot of "smarts". It surprised me to discover that most of the sensors that these robots use are the motors that run the robot.

Back Electro-Motive Force (BEMF) tells the robot how much the robot moves. Current draw tells the robot how much work the robot is doing. Many robots use the motor to detect when they run into an obstacle, eliminating expensive, unreliable bumper switch contacts.

Carpet cleaning robots can tell how thick the carpet is, how much dirt is being sucked up, and when the bag is full, in part by measuring the current draw of the various motors.

An experiment with a PIC-AXE robot.

Just for fun, I modified a little robot kit from Radio Shack to run around on my garden railroad. It had one motor for the left side wheels, and another for the right side wheels. Since the wheels on the outside of a curve turn faster, I was able to store that data in the little robot. Then, at the end of it's run, I could download the data into my PC and draw a crude diagram of my layout. It didn't work very well, but, it did work. Imagine that! A track diagram using only the motors as sensors.

So, I can imagine some reader is about ready to give up on me.
He probably thinks,"There is no way I'm going to install all new decoders with robotics built into all my locos."

Remember, I want the system of the future to be smart, but use existing, off the shelf DCC decoders. We won't be installing "robot boards" in every loco.

It turns out, that we can install "VIRTUAL ROBOTS" in our trains. We will just use one small processor connected to the system, to run robotic software for all the trains.

All our robots can be connected trackside. They control each train by sending DCC commands over the rails.

It turns out, that this is a very efficient, and inexpensive way to add smart features to all the trains. The system only needs to load one copy of a robots code into memory. That single copy can be executed over and over for multiple trains.

Hunting for the DCC system of the future.

I started this blog to document how I added features to the Digital Cab Control (DCC) system that we use on our model railroads.

DCC is still in the dark age. It reminds me of DOS. and HEX and BINARY and MACHINE LANGUAGE.

It's time to develop new ways for us to interact with our model railroads.

I wrote my first software to improve the way DCC works about 8 years ago. I'm working on my fourth generation of software now. Eight years is a long time, and much has been learned. So, these first few posts will be sort of the back-story. I'll try to bring the readers up to date on what I have gotten working so far, and the lessons learned.

First, I'll introduce you to my garden railroad. This blog is mostly about the future of DCC on the garden railroad, but, later I'll also cover my N scale layout and a couple of medium sized club layouts in N and HO.

My Granddaughter, Ally, when she was three.

The ALLY is a ten year old Garden railroad.

The ALLY takes on multiple roles, everything from round and round for display, to formal waybill switching using point to point.

The ALLY is for fun. My granddaughter, Ally, and I have been building it it since she was a one year old. Many of our visitors/operators are Ally's friends. Ages range from 2 to 12. They are Ally's cousins, neighbor kids and her friends from school.

I learned a lot about serous switching operations from five year old kids.

I've spent hundreds of hours watching kids, ages 3 to 11, run the ALLY. I don't tell them what to do. I let them decide how they will run the trains.

Guess what! They just naturally OPERATE the trains just like the big model railroad clubs do.

They have a simple rule:

If it's not nailed down, ship it by rail.

Like any Garden railroad, the ALLY has cars, people, and lots of farm animals. Kids will pick animals up and load them onto the trains. At the end of an "operating session" it could take days to find all the cows, sheep and pigs to put them back into their "right spots". I'd find them inside cars, in the "woods" or scattered about the yard.

I soon discovered a trick.

I made two pastures with little fences and water troughs for the cows. I put lots of cows in the first pasture. At the other end of the railroad, I just put one cow in the second pasture. Without saying a word to our visitors, at the end of every operating session, all the cows were in one "stockyard" or the other.

Automobiles are popular with kids too. They got loaded on the trains and were never where I wanted them to be at the end of a session. I added a new car lot filled with new die-cast cars. I added a junk yard with one rusty old car and some tires. I put old cars on the streets and in driveways of the houses. At the end of the next session, the citizens of the ALLY had a new car in the driveway and the junk yard was full.

What was happening?

Well, the kids were running a sophisticated train order system, just like the big model railroad clubs. But, without the cards. Instead of cards or waybills, the kids were doing almost the same thing with cows and automobiles.

You could say, they replaced the cards with tokens.

Experiments with other tokens:

I had always kept logs on our logging train. I removed them and piled them near a forest where I planted some "stumps". At the other end of the ALLY I placed a couple logs next to a building with stacks of cut lumber. At the end of the day, all the logs were at the "saw mill".

Ally likes those little plastic figures called Polly Pockets. They have tons of accessories. I bought a few and added some open passenger cars. It just wasn't possible to load and unload people on our closed coaches. Passenger operations between the two passenger stations thrived on the ALLY.

The ALLY uses a Digital Command Control (DCC) system to control the trains.

And therein lies the problem.

The DCC system is very advanced for a personal railroad:

• It has multiple decoders in every loco. All locos have sound. Some have three color classification lights, mars lights, smoke and other DCC controlled features like cab controlled DCC uncouplers.


• It has up to four decoders in every passenger car and caboose. Nearly every light is individually controlled. Many cars have sound decoders.


• There are decoders is stock cars and even logging disconnects.


• Turnouts, signals and building have stationary decoders.


• Water pumps for falls and even the valves on the sprinkler system have DCC decoders.
  

The problem, how does one operate such a complex array of lights, sounds and other features?

Forget the three year old kids of a second. My two sons, now 30, are masters of all sorts of computer games. The have just about every certification that Microsoft issues. I installed the ALLY's DCC system.

Yet, the three of us can't possibly use every light, sound and function available on the ALLY during a normal operating session.

DCC is still in the dark ages when it comes to consumer electronics.

If you look at the new toys, you see animated dinosaurs that learn their environment, react to it, and their owner and even anticipate the owners wants.

The iRobot Roomba cleaning robot automatically figures out the size of a room and all its obstacles. It adjusts to different carpet, finds its way back to its charger and avoids falling down stairs and entertains cats for hours.

• Today's DCC automation systems are great for museum displays. They run the trains automatically.


• Today's DCC automation systems are great for large model railroad clubs. They control signals, and force operators to obey rules or follow a schedule.

Both of these examples require tons of work to set up and configure. Clubs members spend a lot of time learning the system. These systems are way to complex to set up or operate for model railroader.

I needed a system that:

• Has to be very smart.


• Has to configure itself by learning the track plan just by running a loco over all the track.


• Has to work without any wiring other than the power feeds to the rails. This was especially important for my garden railroad. Wires and watering systems are not a good mix.


• Has to work using existing off the shelf DCC hardware. Preferably from a single maker.


• Has to learn new locos by monitoring how a human operates the loco and then mimicking the human operator.


• Has to dispatch a loco automatically. I have noticed that a three year old can master putting a loco on the rails, turning the throttle and operating a direction switch. They can't key in or select a DCC address, so the system must auto-assign the most recently added loco to the first unassigned throttle that changes speed or direction.

During the past 10 years, I wrote various extension for the ALLY's DCC system to accomplish all of the above. None of the systems did everything, just some of the features. The eventual goal is to combine all of these features into a single "smart" device that can be plugged into the system and add all of these features.

This blog will follow that quest for the next generation of DCC.