CS452 - Real-Time Programming - Winter 2016

Lecture 23 - Giving a Demo

Public Service Annoucements

  1. Train Control I demo on Friday, 11 March.
  2. The exam will start at 12.30, April 19, 2016 and finish at 15.00, 20 April 2016.
  3. By Friday you should be able to drive one train on the track, knowing exactly where it is. Talking to students in the trains lab I have gotten the idea, rightly or wrongly, that many students are not trying to do the easy things first. In class I suggested something like the following order of development:
    1. stopping distance,
    2. velocity at constant speed,
    3. stopping time,
    4. short moves, and
    5. acceleration and deceleration.
    I suggested this order because train calibration seems to work best if you build you intuition slowly, starting with things that are quite simple.
  4. Suppose you decided in advance that you want a train to travel at exactly 28 cm/sec. A similar approach can be used to have one train follow another at a specific distance.


Multi-Train Control

By the next milestone you will be able to control two trains at the same time.

Sensor Attribution

To accomplish the first milestone you sorted sensor responses from the train controller into two categories:

  1. ones caused by a train, and
  2. ones you ignored.
For the next milestone you split the first case into two: ones caused by train 1, and ones caused by train 2. In other words, Which train triggered which sensor?

One way of doing this is to plan ahead.

Communication bandwidth to train controller

This is the scarcest resource.

The symptom that you are trying to use it too much is getting a lot of time-outs for events that actually occurred. Switches switching too late is another symptom.


Route Finding and Following

You need to be able to route in the presence of obstacles. Some obstacles are stationary; others are moving: you should handle both properly. It's normally a good idea to start with stationary obstacles. Blocking one or more sections of track by a keyboard command, then asking for a route is probably the easiest place to start.

You need routes that reverse because they improve the performance of your project.

Please remember that it's not enough to find a route; you must also be able to drive a train along it. Driving over a route to a destination is not too hard, but it must be very robust because it's a basic capability required for driving two trains at once.

You can try a gradually harder approach.

  1. Make sure that you really have the train finding the shortest route using only one train.
  2. Make sure that you can route around one or more obstacles by manually removing an edge from the graph.
  3. Drive a second train to some point; make sure that you route around it automatically.
  4. Let the second train move in a simple way; make sure that you can route around.
  5. Make two trains route simultaneously.
When you are testing hand or mentally calculate the shortest route before you start the train moving.

It doesn't matter what shortest-path algorithm you use, with one exception: the Floyd-Warshall algorithm does NOT work.

When calculating the length of a path you might want to add some extra distance every time the train has to turn around. That is, you are probably most interested in the time a train takes getting to its destination, and reversing adds significant time.


How to give a demo.

You are in charge; don't forget it.

General: stay in control.

Don't leave dead air.

There are two of you.

Plan what you are going to do and who will do it.

When you are planning what to say try thinking about these questions.

Make sure that the things you are going to show actually work.