CS 452/652 Fall 2022 - Lecture 8

Track/Train Measurements

• 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

Basics

• speed: train setting 0-14
• velocity: actual travel distance per time
  1. non-linear with speed
  2. different for different trains
  3. different for different parts of track?
  4. changes over time (wear and tear)
  5. 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?

Sensor Measurement

• assume ~60ms continuous sensor polling loop
• unknown (hopefully constant) measurement error
  • train controller box
  • signal latency
  • etc.
• variable measurement error: sensor trigger relative to polling loop → 0-60ms
• processing delays? later... (should be small with dedicated measurement program)

Speed Measurement

• 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...

Data Representation

• word length 64 bits
• no floating point!
• if necessary, use fixed-point integer instead
• avoid rounding errors and overflow

Metrics

• time
  • 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!
• velocity
  • distance in mm; velocity in mm/s
  • distance/velocity? fraction of second → scale up / rearrange

Debugging

• often ad-hoc activity - reflect on it...
• fundamentally:
  • 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?

  	Model	Implementation
  Program	Design	Coding
  Environment	Interface	Internals

• 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?

Experiments

• debugging fundamentally uses scientific methodology
  • build model → gather data → compare
  • repeat
• no amount of experimentation can ever prove a model correct!

Tools

• 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>