CS 452/652 Winter 2022 - Lecture 25
March 11, 2022
TC1 Demo Review
- importance of robustness increases between TC1 and final project
- being able to quit your program - and restart
- without reload
- without reboot
- good for demos, but also helps development
- initialize BSS
- initialize data
- keep constants for initialization
- always/periodically check for exit key
- use headlights to (manually) detect train's positioning during initialization
- use sensors to detect trains location and travel direction
- double-check kernel mechanisms: message passing & context switch
- double-check UART servers and interrupt handling (including CTS)
- double-check priorities
- double-check main bottleneck: serialization at half-duplex COM1
- avoid interrupts: performance and control
- avoid buffering in kernel
- clock/timer: interrupts always needed
- can count interrupts and deliver via AwaitEvent
- expectations and error checking?
- make clock server not the highest priority?
- UART: TX interrupt cannot be always on
- TX interrupt for every send? unnecessary...
- loop: try-send → enable interrupt → wait
- can still buffer characters in user-level
- RX interrupt?
- think of tight loop: RX arrival → response needed → RX next arrival
- make receiver notifier lower priority than response tasks: track vs. terminal?
- think about layered safety?
- emergency stop (speed 15); regular stop (speed 0); collision avoidance
- also for speed re destination & collisions
Train Control Objectives
- travel at constant speed level
- can recalibrate velocity estimate
- optional: slow down before stopping
- travel at specific velocity
- timed adjustment of speed level, verify via sensors
- travel in cohort: multiple trains at specific distance
- adjust one or both trains, verify via sensors
- fault resilience - handle one faulty part
- shortest path routing is often presented as optimal
but not always the best choice → bottlenecks!
- common optimisation criterion required for consistent path computation
- from the perspective of different nodes, especially in distributed setup
- run Dijkstra algorithm only for branch nodes
- use overlay data structure for reservations and faults
- mid-travel reverse - relevant for merge nodes (and begin/end)
model as extra link → augment track data
- online: on-demand routing?
- compute path using track \ reserved route
- single-node Dijkstra (overlay) is probably doable online
- offline: determine loop-free alternative path with loop threshold!
- loop-free: take other edge, then remove turnout from consideration
- or take loop to get out of the way