bus_analyzer future ideas

[ekimekim]

• parse speed and heat gauges
  • They show up well with the same "only green" filter we use for the clock
  • Just need to identify the slope/angle
• detect point, other screen states
• maybe detect bus stops by looking at door handle position?

[chrusher]

Can you only open the door at bus stops?

[ekimekim]

yes

[ekimekim]

State of bus data as of writing:

• Odometer: Captured. Post-processing step is still extremely rudimentary and done on demand. Should be done as an automated pass that gets saved to the DB.
• Clock: Captured. Post-processing is a similar story to odo and is required to unambiguously determine AM/PM.
• Time-of-day: Captured. High accuracy, no need for post-processing.
• Heat gauge: Should be possible.
• Speedo: Should be possible.
• Bus-on-road position: Should be easy enough by checking road position on screen.
• Bus stop (handle position): Should be very easy
• Tow truck detection: May be possible via horizon tilt. Unlikely to be seen in a run.
• Score screen detection: Important for telling other detectors to ignore any garbage they read. Should be doable similar to time-of-day.
• Score screen details: Points
• Name tag?
• Wheel position

As a meta note, it would be nice to be able to trigger the bot to go back to "points of interest" and take higher time-resolution data (eg. every 0.5s instead of every segment, or even every frame).

[chrusher]

Looking over last years sheet I saw two mentions of the bus being towed. It often happens at the end of the run after the final crash.

[chrusher]

For time of day, the existing code returns one of the times of no matter how different the colour the pixel is from one of the sky colours. Looking at multiple pixels could be a more robust way of identifying things that are not Desert Bus game play.