CS452 - Real-Time Programming - Winter 2013

Lecture 25 - Multi-Train Control II

Public Service Annoucements

When you will give the second demo
- Thursday, 21 March.

Train Control Demo I

What we saw

All groups had calibration of constant speed
- Precision varied: pm 3mm to pm10cm
- Comprehensiveness varied.
Most groups did not have reversing routes. (3 & 4 are needed to make this work well.)
Most groups did not have acceleration/deceleration calibrations.
Most groups could not stop between sensors.
Many groups started off by finding the train.
Many groups stopped tracking the train when they gave a stop command
- Internal to your application every active train should have, at all times, values that are your best estimates of its velocity and position.
Some groups kept track of train direction.
Some groups relied on operating reliably at low speed, which is risky.
One group found the slow then crawl method of stopping.
One group found a scaling relationship that helped them a lot
Few groups had parametrized applications.
- parameters that are changeable at the terminal which your application is running
- giving a demo
- learning more while debugging when performance matters
- example, time and safety margins when reversing through a switch might be adjustable
Most groups had noticed that measurement is very time-consuming.
Few groups had dynamic calibration
- new-v = (1 - a) * old-v + a * measured-v: simple as it is this works very well
- save for next use on a linux disk, start with the most recent save next time
Most demos were too highly weighted to route finding, compared to calibration.
- route-finding is the easy part.

Not having a wide enough state space in which you know where trains are will probably hurt you the most going forward.

Multi-Train Control

By the end of the week-end you should be able to drive one train on the track, knowing exactly where it is.

'Exactly' means within a tolerance that you know.

By the following milestone you will be able to control two trains at the same time. For each train

the train finds itself
you give it a destination: a destination is a location on the track
the train starts travelling toward the destination
it reaches the destination without colliding with the other train
both trains move at the same time
- otherwise there is a trivial solution
- it might be worth implementing the trivial solution as a start

A good goal for the second train milestone is

Two trains on the track going to random destinations.
When a train stops at its destination it is given a new random destination and starts up again.
The trains avoid one another.

Sensor Attribution

Collision Avoidance

Route Finding

It doesn't seem to matter what shortest path algorithm you use, but

you might want to introduce a penalty for reversing,
representing each stretch of track twice in a directed graph is commonly useful
route finding might be integrated with collision avoidance

Reservations: a possible solution to collision avoidance

You have to be able to look ahead.

To do so treat the track as a divisible resource like pixels on a display. Train driver requests some of the resource in order to move.

He needs enough track that it can come to a stop.
The server that "gives" we would call a reservation manager.
The train driver should always be prepared to act safely if a request for track fails.

A very simple way to do it not well enough

Train driver gets a request to do something with the train, and figures out whither he needs to move.
Train driver asks for a route
Train driver is blocked until no other train is moving.
- Route provided avoids stopped trains, which are guaranteed to stay in the same place.
Train driver requests track all the way to the end of the route.

Return to: