The final form of the third project is shown on the appertaining picture.
The two boxes have the same dimensions, even though they are designed for two different types of Arduino board – one “ordinary” Arduino and one Arduino Pro Micro. We figured that the bread board of an ordninary Arduino has the same size as a micro Arduino, and we decided to make the boxes equally. The only difference is, that the Arduino Micro needs three AAA batteries, and so we made holes on the side in one box to screw a battery holder in place.
The micro Arduino was problematic to work with, and unfortunately, we didn’t succeed on getting it to work, in spite of massive code-work. We’re still unsure why the error occurred.
The design of the box – what we did and what we could do better
The size and amount of used material, are optimized as much as possible. The first boxes we lasercutted were way too big . We were concerned that there wouldn’t be room enough for all the components, but as we assembled the boxes, we realized that there wasn’t a need for this much space and we decided to make the box as small as possible, so that it would only contain the necessary components. Furthermore we had to consider if we wanted to have a hole for the screen or if we wanted the user to just see through the plexiglass. At first we just wanted to let the screen stay inside the box without a hole, but when we lasercutted the final box-assemblies, we got the chance to make a hole, and so we did. Now we’re happy about that decision. Even though our material is see-through, it’s more userfriendly, to have a visible and easy accessible screen.
The joystick is joined to the box via tiny srews on the top of the box. It is accessible through a hole. The hole is just as big, as the joystick is able to turn all 360 degrees around when needed.
On two of the sides, there’s air holes to make sure that the Arduino wont get overheated. They might be a little too big compared to what’s needed, but that’s something for further work and considerations.
The hole for the gate is also a little too big. This is something we made on purpose to make sure that the port would be able to fit. The size of the hole is also possible to minimalize. When the gate-hole is as big as it is at the moment, then it’s might not even necessary to have the extra air holes on the sides. There will be abundant air flow to prevent the Arduino from overheating.
On the bottom of the box, our groupname and groupnumber is written. This is a nice and simple personal touch to the product.
The program is built as a state machine, which in different cases have different tasks. To initialize, we send a payload with question.ID set to 0. To get a handshake we compare the current input from the network, to see if it is 0. If it is different from 0, we are part of the game and can receive the first question with the answer possibilities. The possibilities is printed to the display so the user can see what to answer. Next state waits for the user to select an answer, and in the next state sends it. From here it returns to the receiving state and the game goes on through this cycle.
The program is controlled by our CSS “ Current state selector” By combining with a switch statement, we can switch between states and the different tasks needed to be carried out. A runonce instance is set in state CSS=0. This is to join the game, this state is only run when starting the game.
Another approach would be to implement the FSM library from arduino.cc and code cohorently with it. Since the switch is easier to implement from paper and control we choose this method.
For debugging reasons serial monitor printouts has been included in the code, to allow deeper understanding of possible problems during testing.
For future improvement some of the states could be reduced, as they are passive and thus eliminated. The possibility to reset the game without the hard reset on the board, could make the experience more fluent.
Higher up there could be implemented a backwards control signal so everyone sending their package could be informed if it has reached the destination further out the branches of the network. Even more advanced a one connection client-server without any ADHOC to other users may eliminate other pitfalls of testing.
Below is a flowchart showing how it works.
One thing we weren’t able to get to function was the menu. We created a drawingfunction, which shows the possible answers for a quiz, but we weren’t able to indicate the answers so that the user is able to see, what the he or she has chosen. This is something we will have to work on.