InvisibleMaze

This is a project for Burning Man 2013.

Project Status

• 2012-11-03: Wrote the basic beam driver, fully functional other than supporting periodic recalibration. Added beam simulation functionality to the console, clicking a beam now sends a break/make event.
• 2012-11-02: Wrote a controller that launches all the drivers and handles monitoring/restarting/shutting them down.
• 2012-10-26: Wrote a basic lighting driver, receives commands over the UDP protocol and controls the Art-Net lighting via ruby-artnet. Improved the sound driver so that it now dynamically loads all sounds found in sounds/.
• 2012-10-22: Wrote the basic functionality for ruby-artnet.
• 2012-10-20: Wrote a bunch more software. Sound driver, laser beam driver/emulator, game logic/maze driver, and the GUI console are all in working states now.
• 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?

Timeline

• January 1, 2012 - Electronics for a test square built and tested
• April 1, 2013 - One test square fully built and tested
• June 1, 2013 - Hardware and software complete for entire project complete, testing begins

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

UDP Protocol

• UDP-based, broadcasts data to a "packet reflector" which then sends it out to all drivers and the console.
• Each update is in its own UDP packet on port 4444, then reflected out to a port for each driver
• 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)
    • Parameters 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
  • playerloc - Update where the player is on the board
    • Sender: maze-driver
    • Parameter 1 - X location
    • Parameter 2 - Y location
  • sound - Make a sound
    • Sender: maze-driver
    • Parameter 1 - Sound to make:
      • buzz - Buzzer, used when hitting a wall
      • mazegenstart - Announcement that maze generation is starting
      • mazegen - "Computing" sound as maze is generating
      • mazegendone - Announcement that the maze is generated
  • state - Notify of the game state changing
    • Parameter 1 - Old state
    • Parameter 2 - New state
    • State values:
      • init - Engine starting
      • attract - No game in progress, attract mode running
      • mazegen - Maze is being generated
      • ingame - Game in progress
  • lightnodes - Announcement of lighting (Art-Net) nodes currently on the network
    • Sender: lighting-driver
    • Parameter 1 - Number of nodes
    • Parameter 2-n - Universe.Subuniverse number that's on the network

Beam Controller <-> Computer Protocol

• Beams are organized serpentine, one controller for vertical beams and one for horizontal beams
• Controller sends two bytes for each state change
  • Byte 0: beam number (beam 0 = closest to controller)
  • Byte 1: 0x00 = beam broken, 0x01 = beam restored
• Computer sends two byte commands to controller
  • 0x00 0x00 - No-op
  • 0x01 0x00 - Recalibrate all sensors
  • 0x02 0x00 - Lasers off
  • 0x02 0x01 - Lasers on
  • 0x03 <beam> - Read current raw beam value
    • Returns one byte, current raw beam value
  • 0x04 <beam> - Read stored ambient light value
    • Returns one byte, ambient light value