InvisibleMaze

From Hackstrich
Revision as of 03:16, 18 November 2012 by SarahEmm (talk | contribs) (Status update with today's work.)

This is a project for Burning Man 2013.

Project Status

  • 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

  • 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