CS 452/652 Fall 2022 - Lecture 8
Oct 4, 2022
- train control assignments need velocity information
- preparatory measurements can be taken without full kernel
- start early before the tracks fill up!
- default turnout setting - use captive loops: small (left/right), medium, large
- middle turnouts: do not set to C/C! (can lead to derailment)
Speed / Velocity
- speed: train setting 0-14
- velocity: actual travel distance per time
- non-linear with speed
- different for different trains
- different for different parts of track?
- changes over time (wear and tear)
- two velocities per speed level 1-13 - previous lower vs. higher
- handle at least 1. and 2. by measuring and storing velocity data
- offline experiments → start now!
- continuous online measurements?
- data import/export?
- assume ~60ms continuous sensor polling loop
- unknown (hopefully constant) measurement error
- train controller box
- signal latency
- variable measurement error: sensor trigger relative to polling loop → 0-60ms
- processing delays? later... (should be small with dedicated measurement program)
- velocity = distance / (stop - start)
- constant error in 'stop' and 'start' cancels out
- maximum variable error: up to 60ms
- at speed of 0.5m/sec, this corresponds to 3cm
- use averaging (and deviations) to deal with uncertainty
- to be revisited...
- word length 64 bits
- no floating point!
- if necessary, use fixed-point integer instead
- avoid rounding errors and overflow
- clock: 54 Mhz
- 32 bit (CLO) can represent > ~79.5 seconds
- small numbers: 10ms tick
- location, distance
- millimetre granularity sufficient
- longest short path (without reverse): ~10.5m ⇒ no problem
- keep in mind: size of train, location of pickup!
- distance in mm; velocity in mm/s
- distance/velocity? fraction of second → scale up / rearrange
- often ad-hoc activity - reflect on it...
- software: model ↔ implementation
- debugging: reconcile model and implementation
- (your) program vs. environment (soft- and hardware)
- what's in a bug?
- error in model?
- incorrect implementation?
- potential problems
- design: your model is incorrect
- coding: your implementation does not realize your model
- interface: your understanding of the environment is incorrect
- internals: there is an unknown bug in the environment (unlikely)
- debugging helps with
- verifying design/interface
- verifying coding/internals
- basic technique: inspect and compare → alert
- debugging strategy
- rule out or confirm problems
- start with most likely problem?
- or start with most easy to rule out?
- debugging fundamentally uses scientific methodology
- build model → gather data → compare
- no amount of experimentation can ever prove a model correct!
- tracing, logging (print)
- checking (assert)
- snapshot inspection
- interactive debugging: breakpoints, single-stepping (if possible)
- post-mortem (if reboot keeps RAM): need custom software
- source or binary instrumentation
- stack backtrace? see 'man backtrace' on Linux
- not available in newlib, you could re-implement...
- execution trace: str pc, <location>