InvisibleMaze

This is a project for Burning Man 2013.

Project Status

• 2012-10-19: Started working on the Console half of the software, including maze generation (which will eventually move to the Backend half).
• 2012-10-16: Changed concept from Tic-Tac-Toe to an invisible maze.
• 2012-09-17: Completed schematic and board layout for the Hub LED board. Will submit it with the main Hub board.
• 2012-09-16: Started designing the Hub LED board that plugs into the Hub board and provides R, G, and B high-power LEDs and FETs to control them.
• 2012-09-12: Finished checklist on strip board, CAMed and submitted via OSH Park for manufacturing.
• 2012-09-11: Started working through checklist, needed a bunch of changes to make IR emitter/detector line up.
• 2012-09-09: Started board layout.
• 2012-09-08: Put together BOM and designed schematic for the strip board containing 5 LEDs, the drivers for them (WS2801), the IR emitter/receiver, and the ADC/logic for the IR.
• Wednesdayish on the playa: Started throwing around ideas for 2013's project.

Random Thoughts

• Strips of LEDs/IR sensors run in clear tubes like the Man perimiter's LEDs
• Hubs located at cross points which have high powered LEDs to light squares and laser beams to detect people's location
• All run off the StrichLux system the same as Beacon4
• Higher-resolution grid than was planned for TTT, maybe 4x4 or 5x5 1m or 2m squares?
• Stepping into a square causes the system to generate a maze with the square you stepped in as the starting square.
• Maze is briefly flashed on the lighting strips, then goes dark again.
• "Bumping into a wall" on the maze causes a buzzer-type-sound and that wall to go red.
  • Would it also flash the entire maze again? Probably need to wait and see what works best once the system is built.
• Each bump is added up on some kind of scoreboard
  • Could have a high-score-board too, with some way for people to enter initials?
• Would probably need/want voice prompts to tell people what to do?

Software Architecture

Components

• console - allows viewing of the status of the whole system for troubleshooting, monitoring, etc.
• maze-driver - builds the actual maze and runs all game logic
• lighting-driver - runs the lighting itself
• beam-driver - accepts input from the laser beam detection system
• sound-driver - handles playing sounds

Backend -> Console

• UDP-based, broadcasts data from the backend all the time to any consoles that might be listening
  • Could also configure it with a unicast address, but probably no reason to as long as it's just broadcasting on the management interfaces
• Each update is in its own UDP packet on port 4444
• Parameters for an update are separated by spaces, quoted if the parameter has a space within it
• Example: beam b h 1 2
• Updates:
  • beam - Laser beam breaking/making
    • Sender: input-driver
    • Parameter 1 - (b)reak or (m)ake
    • Parameter 2 - (h)orizontal or (v)ertical beam
    • Parameter 3 - x position of beam
    • Parameter 4 - y position of beam
  • event - Textual event information
    • Sender: all drivers
    • Parameter 1 - From driver
    • Parameter 2 - Text event message
  • maze - Maze layout refresh
    • Sender: maze-driver
    • Parameter 1 - Number of rows/cols (currently must be square)
    • Paramters 2 - size*size - horizontal wall data (rows, then cols)
    • Parameters size*size+1 - size*size*2 - vertical wall data (rows, then cols)
    • Data values:
      • 0 - open
      • 1 - unhit
      • 2 - hit
      • 3 - start
      • 4 - end
  • sound - Make a sound
    • Sender: maze-driver
    • Parameter 1 - Sound to make:
      • buzz - Buzzer, used when hitting a wall