InvisibleMaze

From Hackstrich
Revision as of 23:31, 2 February 2014 by SarahEmm (talk | contribs)

This is a project for Burning Man 2013 2014.

Project Status

  • 2014-02-02: All issues fixed in Rev003, sent order to OSH Park for 6 boards. Still have to design 3D printed
  • 2014-01-02: Seems to work as-expected other than structurally and a couple minor PCB issues. Will spin Rev003 which should hopefully be the final revision required.
  • 2014-01-01: Assembled the first north node board, works except that DIO8 isn't actually implemented on the XBee per errata, so need one green wire there to fix it. Testing is continuing.
  • 2013-12-31: Boards and parts are here for 3 complete nodes.
  • 2013-11-18: Completed design for the laser node board, ordered 12 (3 sets) from OSH Park.
  • 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

Known Issues

Node Board Rev001

  • DIO8 on the XBee isn't implemented per errata, to make the north lower laser work a green wire from pin 9 to 12 on the XBee is required, which then connects the laser to DIO7. - Fixed in Rev003
  • Should pull back the ground plane around the knockout holes so that knocking it out/filing out the tabs doesn't expose it. - Fixed in Rev003
  • Should solder jumper in the sensors, so that when knocked out the traces aren't bridged by the lasers. - Fixed in Rev003
  • Solder to attach the 4 boards is hard to assemble and won't be durable, should switch to nuts and bolts. - Fixed in Rev003
  • Need to come up with a non-friction-fit-into-PCB way to mount the lasers, aiming proving a harder problem than I'd originally thought. - Added mount for 3D printed aiming/mounting block in Rev003
  • Node Online indicator comes on when not online, and flashes when online. - Fixed in Rev003
  • Stuffing all 4 boards with 12 pin headers causes interference on the end pins, can solve by stuffing the north board with 12 pin headers and the others with 10 pins, as the end two are only used on the north board. - Modified BOM for Rev003
  • Headers missing from BOM - Modified BOM for Rev003

Photos