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.