Thursday, February 12, 2009
A virtual open house?
But, can we do it via the web?
In preparation for a "Virtual" open house, I added a web cam to the very bottom of this blog.
I'll announce the actual dates and times once I get it all finalized.
In the mean time, scroll all the way to the bottom and have a peek.
Tuesday, February 10, 2009
How does First Zone work?
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.
Steve is a follower, he asked:
"So what are the benefits of having the terms the way you have them? Wouldn't the first zone be different depending on where the loco (for example) was first placed on the tracks? How does that distance help with the rest of the layout?"
This sounds like a good topic for today's blog.
When you power up the system for the very first time, you can place a loco anywhere on the track. When it is run, it will come to a zone boundary, ( the insulator that separates two zones. ) It then starts a timer. When it comes to the other end of that zone, it then notes how long it took to get THROUGH that FIRST ZONE (Fz).
From That point on, for every session, that section of track is the First Zone. It remains the First Zone until you perform a software reset.
The first zone is then assigned a length of ONE. Continuing around the track, the loco can time each of the other zones and assign them lengths that are based on the time it took to get through the "FIRST ZONE".
If the second zone takes twice as long, then it's length is two Fzs.
If the loco takes one fourth as long to get through a zone, it's length is 0.25 FZs.
To simplify the above explanation, we'll assume for now that the loco travels at one constant speed. However, we will see later that the loco can still do this, when the speed changes.
Remember, One goal is to have the system work without the tons of configurations needed by existing systems. In fact, no user input at all.
So, put yourself in the position of a robot.
You wake up and find yourself in a curving, twisted concrete tunnel.
You are on a remote controlled golf cart.
An on-board fax prints out instructions telling you to measure the lengths of all the "Zones" in the tunnel and draw a map.
There is a stopwatch, but instead of seconds, it is calibrated in TICKS.
The servo on the throttle is calibrated 0 through 127 and labeled "STEPS".
STEPS, not MPH of KPH. The golf cart does not have a speedometer.
The servo moves to 40 STEPS. The cart starts moving. You have no idea how fast a STEP is, or even what scale you are. You might be an N scale robot or a G scale robot.
You come to a line painted on the tunnel walls. A sign says, "You are leaving Zone B and entering Zone C". You reset the stopwatch to zero and start it.
You come to another line and a sign that says, "You are leaving Zone C and entering Zone A" You notice it took 1800 ticks.
You start drawing a map showing the first zone you have measured.
FIRST ZONE
ZONE C
1800 ticks at 40 steps
?--B/C-----1800@40----------C/A
You come to another line and a sign that says, "You leaving Zone A and are entering Zone B" You notice it took 900 ticks. Your servo holds steady at 40
You add to your map.
?--B/C-------1800@40--------C/A----900@40---A/B
You come a third line and a sign that says, "You are leaving Zone B and entering Zone C" You notice it took 900 ticks at 40 steps
You add to your map.
?--B/C-------1800@40--------C/A----900@40---A/B---900@40----B/C
At this point, You might think you are back in the First Zone, zone "C".
That would mean you are on a loop. However, there might be several zone "C"s. To be sure you are on a loop, you would predict that you should leave zone C and enter Zone A in 1800 ticks. Then, if the next two zones match your map and each take 900 ticks, you are confident that you have measured the entire loop.
When that is done,you can draw a sketch. The total time to go around the loop was 1,800 + 900 + 900 = 3,600 ticks, or 10 ticks per degree. You can start at zero degrees (12 noon) and going clockwise draw the first zone (C) 180 degrees to the 6 o'clock position. The other two zones each take 90 degrees.
To report this, you can send:
First zone = C
Zone C = 1
Zone A = 0.5
Zone B = 0.5
Notice that we don't know the actual length of any zone. But, we can describe the length of each zone in terms of the first zone.
It would also be useless to report back the time it took to go through each zone because we have no idea what speed the golf cart is going at STEP 40.
In reality, you need to send three other numbers for each Zone, Confidence, Accuracy and Resolution. Confidence has to do with changing speed while measurements are made. Accuracy has to do with variations in the number of ticks required to go through the same zone multiple times. Resolution has to do with the number of total ticks used for each zone.
Once all the numbers are crunched, the information can be shoved back into the golf carts fax machine and will be used by all the other robots that might need a map of this tunnel.
HOMEWORK
If you'd like to try this assignment and receive a grade, record your answers in this FORM. It will open in a separate window.
You are a robot. Another robot has already made a map. You will use its map.
You wake up to find yourself in a tunnel on a fax equipped, remote controlled moped with a stop watch.
The fax spews out the information shown above.
A servo is marked off in numbers from 1 to 14. It moves to the 10 mark and your moped lurches forward.
Exactly 155 ticks later, you see a sign that says "you are leaving Zone B and entering Zone A.
- Question 1 - What direction are you traveling?
(a) Clockwise.
(b) Counterclockwise.
(c) Unknown. - Question 2 - How long will it take you to get to Zone C?
(a) 900 ticks.
(b) At least 155 ticks or longer.
(c) 745 ticks.
After entering Zone A, you found it took you 200 ticks to get all the way through Zone A to to Zone C.
- Question 3 - When you enter zone C at step 10, how long do you predict it will take you to get to zone B?
(a) 200 ticks.
(b) 400 ticks.
(c) 1800 ticks. - Question 4 - You just left zone C and entered Zone B. 600 ticks later, where are you?
(a) In Zone A.
(b) Lost.
(c) At the 3 o'clock position on the diagram above. - Question 5 - You leave Zone B and enter Zone A, Still going at 10 steps. Starting at the time you enter Zone A, how many ticks later should you slam on the brakes to stop at your original starting point.
(a) 645 ticks.
(b) 45 ticks.
(c) At the 3 o'clock position on the diagram above.
If you get all five answers right, then you realize that, without knowing any actual speeds or distances;
- We can tell exactly where you are now.
- We can tell where you will be in the future if you continue at that speed step.
- We can tell you how long to continue running to arrive at any spot in the tunnel.
Click HERE to see the correct answers.
Sunday, February 1, 2009
Track Plans
Wednesday, January 28, 2009
Defining automation terms.
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:
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.
Thursday, January 15, 2009
What can train robots do? (PART 1)
[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.
Wednesday, January 7, 2009
A lesson on "User Friendly"
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 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.