Maze Craze Weekly Log

Week of 1/23/17

• We formulated our team and brainstormed ideas for our project. Then, we decided on our maze game idea and began writing a simple project proposal.

Week of 1/30/17

• We wrote a starting proposal for Maze Craze including a Gantt chart and budget. After meeting with our TA Natalie, we solidified our proposal and overall project idea.
• Once the project proposal is approved, we will design our game board and layout for the maze so that we can order parts to begin construction.
• In addition, we seem to have a clear schedule of when we will be able to work on the project individually and together.

Week of 2/6/17

• We started designing a layout for our game board with possible dimensions that may be subject to change depending on the parts we ultimately use.
• Revisions were made to the project proposal by editing the project description, budget, objectives and challenges. The budget still needs a few prices to be confirmed as we finalize our decisions on a few parts such as the amount of wood we will need which will depend on the final dimensions we choose for our board.

Week of 2/13/17

• This week we had serious problems with our budget. We had to overhaul almost everything on it in order to stay under $150. All of the items below have been added to our budget:

1. We found a new website to order the LED RGB strips.
2. We reduced our order of hall effect sensors to 27 as we only require 25 but want to have a couple extra.
3. We found cheaper spray paint for $3.87 rather than $8.00.
4. We are now ordering a 5V 10 Amp Power Supply rather than using battery packs to power the Arduino.
5. We found cheaper screws that will still suffice to keep our box together.
6. We also found out that we needed 10K Resistors in order to use the hall effect sensors properly.
7. Instead of using LEDs for the number displays we will be using cheaper analog number displays.
8. We found a cheaper breadboard that should achieve our needs.
9. We also need a female DC power adapter to connect the power supply to the Arduino.
10. We will also be upgrading our Arduino to a Mega Arduino.

Week of 2/20/17

• This week we ordered:

1. All the Sparkfun items (Lights, Hall Effect Sensors, Resistors, and Switch)
2. Breadboards

• We visited Home Depot to get our wood, screws, paint, etc.
• Jason mocked up a basic version of the game in Java. The two versions we mocked up were:

1. A version that generates a random maze every move
2. A version that cycles between two mazes with every move

• Jason also tested how probability affects the whether or not the maze is solvable by altering the probability and playing through several mazes.
• We discussed the "maze generating" algorithm and how each maze will be created. We decided:

1. Not every maze has to be solvable
2. The mazes cannot be generated completely randomly because they will generally be unsolvable
3. Every time a game starts, a completely new set of mazes will be generated
4. A possible way of controlling difficulty is generate random numbers for each wall and altering the likelihood of a wall to be green (~60% green is a fairly easy game, while a 40% is much more difficult and likely impossible)
5. The two walls bordering the entrance and the two bordering the exit must always stay on

• Liz mocked up the basic wall/sensor code on an Arduino. It:

1. Models a set of walls (with LEDs)
2. Responds to a user's button presses by lighting a different set of walls (modeled by LEDs)
3. Does not respond if a user doesn't move but just "sets their piece back down" (modeled by buttons)
4. Waits for a player to set their piece in the "start" position to begin the game

Week of 2/27/17

• This week, the following parts arrived:

1. The 1k and 10k resistors
2. The 3 solderless breadboards
3. The 3 strips of LED lights
4. The 27 Hall Effect Sensors
5. The on/off switch

• Liz got a Hall Effect sensor wired up to an Arduino Uno properly and is getting proper readings with test magnets

1. We figured out our Hall Effect sensors are "latching", meaning that they return a '0' until a magnet is sensed, then a '1' until the magnet is sensed again. This changes they way we will go about coding how a player's game piece is registered, but we have a good idea about how to handle this involving an array of "last states" and "current states" of each Hall Effect sensor
2. Our 10k resistors worked with the Hall Effect sensors

• Jason sketched up a 1:2 scale drawing of the top of the game board. This is pictured below.

• We began looking into the coding of the addressable LED strips

1. We found a library that other users of the same LED strips say works well. This code is quite over our head, so we are planning to seek help from Natalie, our TA, with the controls of the lights. This library is linked: Adafruit NeoPixel Library
2. We discovered that our RGB lights do not have adhesive backing and are also more expensive than the other RGB strips. We are considering returning the current LEDs and ordering the LEDs with the adhesive backing.

• We were having problems wiring up the LED strips. We hope to get help from Natalie to figure how to wire the LEDs up.
• We began strategizing MegaArduino pin distribution.

1. 25 digital pins will be used for Hall Effect sensing
2. 8 pins (unclear whether analog or digital as of yet) will be used to control each strand of RGB LED strips
3. 1 pin will be used for the on/off switch
4. Up to 20 pins could be used for number displays (this is in the air at this point, as we don't know whether we'll have time or funding for this feature)

• We updated our "Challenges" portion of our project wiki to reflect the currently projected issues.

Week of 3/6/17

• The hall effect sensors we ordered are latching and our game requires that are non-latching. We found a program online that helped us program the sensor to act as a digital reed switch. This means that the sensors will detect when a magnet is near and act like a switch being toggled on. When the magnet is out of detection range the hall effect sensor will no longer provide an output and be switched off.
• We started learning how to 3D print and printed a sample piece from Thingiverse.
• Liz got the LED light strips to turn on using Adafruit’s NeoPixel library test code.
• Jason created a design for a casing to go around our hall effect sensors to attach them to the top of our box.

Week of 3/13/17 (Spring Break)

• Jason worked on the maze generation algorithms. He:

1. Realized that a player could only reach certain squares at certain times because of the nature of the game. (IE, a certain square may be accessible on maze 2 due to the switching of the mazes). This may aid us in testing if mazes are solvable.
2. Designed a storage system for the maze data. This is a 2-D array holding 4-bit binary characters that represents each wall. These 4-bit numbers will be processed with a bit mask.

• Liz worked on getting the lights and Hall effect sensors working. She:

A single strand of LEDs responding to a magnet's presence. Please click to watch.

1. Designed a Lights Protocol that converts from programmer-friendly addressing (IE vertical wall at 0, 1 is set to GREEN) to RGB values and turns the lights in that specific wall on.
2. Wired up a few different light strands and got them to respond and change color to a user's game piece.
3. Practiced designing colors and implementing them.
4. Worked on her soldering skills in preparation for the coming weeks.

• Together, Jason and Liz worked on brainstorming for the future of the game board. We discussed:

1. New game ideas (A TRON-inspired game where you race against a computer to a finish, a "whack-a-mole for adults" where you have to hunt and find the correct color and place your piece before a certain time, a basic maze, and tic tac toe).

Week of 3/20/17

• We drilled all 180 holes for the lights in the board.
• We spray-painted the top panel of the board flat black. See picture below.
• Jason programmed the maze generator in a way that the maze always has at least one solution
• The lowest number of moves possible to complete the maze is always 8 moves on every maze.
• The each space on the 5 x 5 grid maze is assigned a 4-digit binary number (ie. 1010) to represent the 4 walls bordering that space ([Up][Down][Right][Left]).
• Since each move by the player flips between the two mazes, the program refers to one maze when the player has made an even number of moves and the other when the player has made an odd number of moves.
• The player will start in the bottom left corner of the grid and make their way to the top right corner by only moving up, down, left or right.
• With this knowledge, the maze can incorporate a pattern of moves that brings it from corner to corner in 8 moves by generating a raandom solution consisting of only up and right moves.
• The corresponding values of the 5 x 5 grid are adjusted. (ie. if at the starting space there is an open wall to the right then the number is adjusted so the 4 digit number has a 0 as the 3rd digit).
• These final 4 digit wall numbers are converted into the two mazes by having spaces with even sums of coordinates(ie. [1][3] -> sum = 4) translate their walls onto maze 1 while spaces with odd sums of coordinates translate their walls onto maze 2.

The game board with a few light strips taped on.

• This data can now be easily displayed by the LED strips

Week of 3/27/17

• We attached the lights to the top face of the board using tape. The picture shows a few strands lit up.
• We began translating the maze-generation code from Java to Arduino C. This process may be a tad more difficult than previously anticipated. Liz is working on it, and hopes to be done soon.
• We ordered our breadboards, reset button, and display screen for the box.

Week of 4/3/17

• This was a very busy week for both of us so we did not get as much work done as usual
• Liz worked on integrating the java code from Jason and her Arduino C code
• Liz applied code to the lights on a small sample that displayed a section of the maze.

Week of 4/10/17

• We tested some lights with the power supply and blew two of the LED strips. The ground connection from the Arduino had not been connected to the ground from the power supply, which in tandem with a current that was too strong, and us fiddling with the voltage while plugged into the lights, damaged them.
• We then tested the lights again with the power supply this time with constant voltage and the grounds properly connected. We were able to have all of the lights on at the same time.
• We then finished integrating the maze generating code and the lights code so that a random maze was displayed on the board. We then had the board flip between two mazes and it worked well.
• We noticed a bug where the lights would flicker, change to blue and the current would spike. We found this was caused because the metal connections on the light strips were coming into contact with the metal connections from other strips. To fix this issue we taped over all of the metal connections using masking tape.
• We figured out the power supply issues and were able to power all the strips at once. This allowed us to begin soldering permanent connections between parts.
• We played with the Mosfet switch that Dr. Humberto recommended to us to power our Hall Effect sensors at our last evaluation. This turned out to be very easy to code and control, so we drew up a circuit diagram for the 25 Hall Effect sensors and the Mosfet switch.
• We soldered all the power leads of the 12 LED strips to a main power wire, and the same for the LEDs' grounds. This will allow all the LEDs to be powered off one line, leaving only two (possibly 3) external wires to run to the power supply.
• We did a preliminary layout for where each breadboard will sit inside the box to get a rough estimate of wire length.

Week of 4/17/17

• We got all 25 Hall Effect sensors wired up to the Mosfet switch and their resistors.
• The game algorithm code is mocked up and ready for debugging. The basic outline for the code is shown below.
• The code can now read in Hall Effect readings and reset using the Mosfet when a move is detected.
• The code can now check for 2 kinds of move invalidity. It detects:

1. When a move is too far or non-adjacent. If the position change is greater than one square horizontally or vertically, the board displays the error screen. Similarly, if you attempt a diagonal move, the board will display an error screen.
2. When a move is over a red wall. If you attempt to move over a wall that is red, the board will display an error screen.

• The code turns all the Hall Effect sensors off and on in order to reset their latching effect only when a move has occurred. This means the sensors can detect magnets properly and will output a 1 only in the presence of a magnet.
• We acquired housings and crimps to connect the Hall Effect sensors to the resistors.
• We encountered a big problem with our hall effect sensors where most of them are not working. We had tested them earlier and most were working properly. None of the sensors are drawing too much current that would fry any of the circuits as the current for a single sensor has never exceeded 3mA. We also made sure to test on circuits that definitely had no clear visible shorts.
• Several of the sensors that were no longer working and we tried several actions to investigate the issue.

1. We tried swapping out the sensors to make sure the problem was with the wiring rather than the actual hall effect sensors and found no difference between sensors.
2. We re-crimped and put new housings on the wires connected to the sensors. This did not change anything with the sensors.
3. Next we soldered a hall effect sensor directly to the wires and still encountered the same problem where the circuit was still passing current through but the sensor was not detecting anything.

• We are going to continue testing but if we are unable to find what the issue is then we may need to rethink our entire circuit.
• The circuit problems were solved, and we got 23 hall effect sensors connected, responding, and glued to the board. Ultimately, we still do not know what was wrong with the sensors. We did not make any circuit changes and came back to the project the next day and the sensors suddenly worked. In order to prevent future disturbances we glued the sensors to the board as soon as they worked.
• After further testing, some of the sensors are still faulty so what we have decided to do is have our maze generator still generate a 5x5 maze but we have moved the finish spot inward. We moved all of the faulty sensors into one corner where the player should theoretically not move to. This effectively make our maze a 4x4.
• Although the maze is smaller than planned for, it is fully functional except for part of the move validity checker. The game can not properly check to see if players move over a red wall because of interruption from the faulty sensors.
• The maze could still check distance, though, and when a player moved more than one space, an error screen was displayed.
• Our demo was a success and the maze worked the entire hour and a half without needing any troubleshooting. We're happy with how the game responded, looked, and functioned in the end.