CS452 F23 Lecture Notes
Lecture 15 - 14 Nov 2023

1. Nov 14th - TC1 Demo review, TC2 Issues

better to avoid manual entry of initial train position
- easier, more robust
simple strategy: move slowly until first sensor trip
You can make assumptions about where trains are initially placed
- the weaker the assumptions, the better
for TC2, avoid manual entry

simplest approach to TC1
- pre-switch entire route to destination
- wait for one sensor that will trigger a stop command
for TC2
- pre-switching problematic for TC2 because trains’ routes may conflict
- need to monitor in-flight trains for the same reason

many interpreted routing target as location + direction, rather than just location
for TC2, important to treat targets are locations
- more emphasis on speed means more important to find short routes
- route to A1 or A2, not just to one of the two

Problem: route target is too close
- planning assumes train is moving at speed, determines sensor and delay for triggering stop command
  - uses velocity and stopping models
- if target is too close:
  - train might never get up to speed
  - train might not be able to stop in time if it did
Will become more serious problem in TC2
- train is routing to destination, but has to stop early because of contention with another train
  - remaining route (after restart) may be a short move

reversals are not needed for TC1
allowing reversals in routes increases the space of possible routes
- larger space often includes shorter routes
  - but shorter doesn’t necessarily imply faster

take advantage of scripted part of the demo
- plan how to highlight the best features of your system

sensor report is either
- triggered by a train (which one?)
- spurious
Sensor Attribution means deciding which of these cases a sensor report represents
for each train, track next expected sensor trigger, expected trigger time
- train N, time T +/- error margin
  - error comes from
    - imperfect velocity model (estimated time to travel distance between two sensors)
    - variable sensor read delay (plus or minus sensor period)

sensor errors:
- unexpected sensor is triggered
- expected sensor is triggered too soon
- expected sensor is not triggered within error window (timeout)
multiple possible causes for each error
- triggered too soon?
- Is it a spurious sensor reading, or an inaccurate time prediction?
try to tolerate at least a single failure
- in case of error, track multiple possible next events to disambiguate the error
tracking train on route, next sensor is S, next next sensor is S’
consider multiple possible next events
- Sensor S, too early
  - on route but faster than expected, or spurious?
    - sensor S at original time: spurious
    - sensor S’: missed sensor S
    - something else? multiple errors
- sensor S deadline missed
  - on route but slower than expected, or missed sensor?
    - sensor S: inaccurate time prediction
    - sendor S’: missed sensor S
    - something else? multiple errors
- some other sensor
  - spurious or off route?
    - sensor S: spurious
    - anything else: off route
Can handle switching failures using the same framework
- If planned route sets switch straight, also monitor next sensor in curve direction
- If that sensor triggers, need to distinguish switch failure from spurious sensor reading
handling multi-errors
- during testing, treat as critical
- during demo, continue and hope for the best

calibration experiment
- design
  - from a stop, start command a speed \(s\), wait time \(t\), then send stop
  - measure total distance traveled from start point
- choose one speed, and vary \(t\)
modeling behavior during short move
- total distance traveled is \(d\), known from the calibration model
- assume you have acceleration/deceleration models for the train
  - acceleration modeled as constant rate: \(a_1\)
  - deceleration modeled as constant rate: \(a_2\)
- assume you have a velocity model, and the velocity corresponding to the short move speed (\(s\)) is \(v_{target}\)
- picture below illstrates a short move
  - \(t\) and \(t^*\) are unknown times, and \(v^*\) is the unknown peak velocity during the short move
Figure 1: A Short Move
- we know:
  - \(a_1 t^* = v^*\)
  - \(-a_2 (t - t^*) = a_2 t^* - a_2t = v^*\)
  - \((v^*/2)t = d\)
- can solve these three equations for unknowns \(t\), \(t^*\), and \(v^*\).