Category: John’s Status Reports

This week I completed the assembly for the game controllers and modules. It involved gluing things together and a lot of soldering.

Module Assembly

There are 6 total modules that do different things in the game, but there are 3 different kinds of modules (2 buttons, 1 slide potentiometer, 3 encoders).

The bottom of each module is a row of 8 pogo pins that are magnetized and will stick to the pins in the module slots.

Inside of each module there are 1 or 2 pieces of perfboard, depending on the module type. For the encoder module, which is shown below, there is a piece of perfboard glued to the bottom which connects power/ground to the corresponding ID pins so the Arduino knows which of the 6 modules it is. The top perfboard holds the encoder in place and wires them to the lower perfboard. The second image shows different ID pin configurations for each of the 6 modules.

Controller Assembly

Each controller is a box with two module slots. For each module slot, a row of pogo pins (8 pins each) is soldered to a piece of perfboard. 8 Wires are then soldered to the perfboard and connect to the header pins of the arduino. The pogo pin perfboard is also glued to the 3D printed module slot which is glued to the controller.

I glued 5 of 6 panel box sides together. The 6th side, which has the hole for the USB cable to the Arduino, is left un-glued for now so it’s accessible.

The Arduino and wiring inside of controller box:

All of the assembled parts:

Progress and Next Week’s Deliverables

Progress is on track for the final demo/report/presentation. For next week, I will be preparing for the presentation and report since I am delivering the final presentation. I will also update the software if playtesting from users yields any valuable feedback.

Testing Platform

I continued working on a platform to test our modules with the Arduino. The board is symmetrical with two copies of each component to simulate the two module slots in each player’s panel.

Three switches are used on each side of the board to select which module the protoboard should simulate. This is because a 3-bit signal is used to determine which module is plugged into each slot of the panel.

Each side has a potentiometer, a button, and a space to insert an encoder. There is a row of header pins that connect to the Arduino pins via jumper wires.

Progress and next week’s deliverables

Progress is on track. For next week, I’d like to get some electronics integrated into the 3D printed modules. This should allow us to test gameplay / user interface.

Arduino-Unity Interface

I spent time integrating our Arduino code with Unity. I was able to successfully simulate the Arduino as a game controller. The game now reacts to us interacting with the buttons/potentiometers/encoders. I spent some time trying out the new electronic components that arrived. I made sure that the encoders are sending good signals and that the other components (buttons and potentiometer) work as well.

I also spent time working on the Arduino codebase and optimizing our design.

Design Report

I spent a significant amount of time this week working on the design report.

Progress and Next Week’s Deliverables

My progress slowed a bit due to midterms and time spent writing the design report, but I am still on track. By next week I hope to have some semi-permanent circuits (i.e. soldered protoboard instead of just breadboards) but that also depends on our panel/module design progress.

Arduino-Electronics Interface

Since we received the Arduinos this week I spent time working on code to interface with the modules’ electronic components. We’ll be using the Arduino Joystick library, which works with the Arduino Leonardo.

The Arduino can be made visible as a game controller using the following initialization code:

Our code will dynamically check the ID pins and process the modules’ data pins depending on which module is currently inserted:

For reading from the encoder, we have two options: polling or interrupts. The polling option is less complex but risks skipping transitions if the encoder is turned very quickly. Here is an interrupt service routine that reacts to encoder state changes: The ISR is attached using attachInterrupt(digitalPinToInterrupt(encoderPinA), encoderISR, CHANGE);

Progress and Next Week’s Deliverables

My progress is on track. Since we’ve now ordered all of our components, I’d like to get my code working with Unity by next week. If the Arduino-Unity integration goes well, I’d like to work on planning the spatial organization of the electronics within the modules.

I spent this week looking at different approaches to interface between the modules and the Arduino.

Module Pins

As a team we decided that each module would get Vcc and Gnd, 3 pins to identify the module, and up to 2 data pins per module. Using the identification pins instead of unique data pins per module allows us to reduce the total number of pins used which is beneficial since the Pogo pins we’re using can be expensive. This also reduces the total number of single points of failure. Each module will therefore have a unique 3-bit identification code. They will be wired as shown, with Vcc and Gnd driving the ID pins:

 

Debouncing

I also considered the problem of debouncing. We don’t want a single button press to be registered as many presses in a short period of time. I compared software solutions with hardware solutions and landed on a few different approaches. For the button-press module, a simple RC filter with a Schmitt trigger should work:

 

The RC filter smoothes the transition from LOW to HIGH and the Schmitt trigger replaces the single threshold voltage with two separate LOW/HIGH threshold voltages. This ensures that any oscillations near threshold voltages do not result in an oscillating output.

Progress

My progress is slightly behind since we just recently settled on the schematics and electronic components so I haven’t made the initial module prototypes. To catch up, we will place the remaining component orders soon and work with what we’ve got for the simpler modules.

Deliverables for next week

Since our Arduinos have shipped, I hope to have some working code that interfaces with hardware components by next week. Ideally we’ll be able to see a physical button press register in Unity software. I also hope to place the orders for the remaining electronic components so we can build all of the remaining modules.

This week I researched ways to connect the modules to the panels and communicate between the modules and the Arduino.

Connecting modules to panel/controller

Players must be able to quickly connect and disconnect the modules without pausing gameplay and shifting their focus. This immediately rules out any connector that requires precise positioning, such as pin headers and sockets, USB connectors, audio jack style connectors, etc.

One viable option is a combination of pogo pins and magnets. Magnets will help guide the modules to the right position and the pogo pins can make a good connection without needing perfect alignment. They are also typically rated for tens of thousands of cycles (or more), which is important since the core of our game is switching modules around. These connectors are expensive, but worth it for us due to their importance.

Sending signals from the modules to the Arduino

I looked at a few different options for how modules can communicate with the pins of a microcontroller (e.g. Arduino). The simplest option would be a module that is just a button with passive electronic components.

 

I also looked at different debouncing techniques. For our MVP, a simple RC circuit might work but I also considered the possibility of incorporating a Schmitt trigger. We’ll make the decision later after more testing.

Progress and next week’s deliverables

My progress is on schedule. By next week I hope to have some working hardware that is ready to communicate with a microcontroller. It should provide reliable, noise-free signals based on user input. I will probably start with a simple module like the push-button, but will also work on more dynamic modules that involve more electronic components.