InvisibleMaze

This is a project for Burning Man 2013 2014.

Project Status

• 2013-11: Reactivating project to work on for BRC2014! Moving to wireless laser nodes to hugely simplify design and on-playa construction, rest of the project should be the same as the 2012/2013 design was.
• 2013-05: Have been sick/off work too much this year to be able to fund this anymore, plus can't figure out how to get it down to the playa as the Site3 truck has no space. Changing to dormant, can try again for 2014 :(
• 2013-02: Finished Hub board + sent off to OSH Park for manufacturing.
• 2012-11-17: Test pack of 10 lasers is here. Fit them into the first laser/sensor support and defocused them and seems to work as-intended (though no sensors yet). Improved the IO-SPI firmware so that it now supports the WS2801, and tested the first 5-LED board successfully.
• 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.Port number that's on the network

Beam Controller <-> Computer Protocol - LEGACY - 2012 DESIGN

• 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

Photos

• 

  invisibleMaze Console (as of 2012-10-21)