CS 452/652 Fall 2019 - Lecture 27
November 11, 2019
- overall: finish trips as fast a possible
- technical objectives
- route finding
- collision avoidance
- sensor attribution
- sensor hit is either
- train - which one?
- keep track of expected sensor passing
- train N, time T +/- error margin
- error margin no necessarily symmetric
- velocity estimate - symmetric
- sensor reporting latency - asymmetric
- error: unexpected sensor is triggered
- error detection critically depends on assumptions
- here: assume at most one failure, not two in a row
- can observation be explained by a single turnout failure or a single sensor failure?
- spurious sensor hit?
- testing: treat as critical error
- demo: ignore and hope for the best
- enhanced error model?
- one error → recover
- two errors → abort
- anything else → spurious/ignore?
- in general: application type?
- online shopping (little at stake): drop transaction, recover by reset
- train, car (lifes at stake): unexplained failure → stop!
- unmanned mission to Mars (recovery difficulty): try to keep going at all cost
- offline: precompute (some) routing information at system startup
- including knowledge about track deficiencies
- finish path computation online
- e.g. Dijkstra previous hop tracing
- e.g. find alternative routes
- on-demand: compute entire end-to-end path online
- including knowledge about other planned routes
- single-node Dijkstra feasible
- on-demand conflict resolution
- avoid conflict in time: wait/slow
- avoid conflict in space: reroute
- planning horizon? direction of conflict?
- chance of stand-off or deadlock
→ need train to go back to clear conflict?
- planning horizon: trade off between safety and agility
- train driving / turnouts
- switch all at once vs. on-demand
- use reservation system (server)
- divide track into suitable segments
- full-path vs. on-demand reservation and release
- planning horizon ↔ velocity / stop distance
and topology: when entering stretch of single-track
- use same planning horizon for routing and driving
- reservation can determine sensor attribution
- more than two trains: cascaded stand-off?