Posted on

Alan’s Status Report 3/15

Mostly I worked on redesigning the modules. We used some of the advice from Gloria and made a model with slanted walls. I also got it printed

It works better than the last print. There’s enough room to insert it somewhat comfortably. I fear there might be some issues in a more high pressured environment with fitting. I’m not sure how exactly to solve that, I think maybe rounding the edges might help. But I will discuss more with the rest of the team.

I next need to make the cap for the module. Right now it’s just a generic hole, but we want to make a cap that can be easily snapped on (for reusability purposes) and also we need to make the holes custom to the specific type of peripheral they will be housing.

Lastly, I made some more progress on the code (which can be seen on the github). These changes were mostly centered around the encoder but also a lot of actual integration efforts. We got to read actual inputs and test it with a sample protoboard that John made.

 

For next week, I want to finish the cap design (mentioned above) and then print out the laser cut walls for the controller. There are also some discussions I want to have about the sending the encoder values from the arduino, that I have been saving for an in-person discussion. I think we should get that finalized soon just so we can integrate the arduino with the unity game, since we do have the protoboard set up at least. Also, we need to do some work for the ethics assignment.

Posted on

Angela’s Status Report 3/15

This week I added some basic UI for the player’s score and implemented the behaviors and animations of a second enemy, a barracuda. I also started work on the third and final enemy type, a sailfish. My main goal for next week is to finish the sailfish and barracuda enemies, and make a few more small visual / quality of life improvements to the game. Next week’s stretch goal is to implement the enemy spawning system. Game is on track to meet MVP. Continue reading “Angela’s Status Report 3/15”

Posted on

Team Status Report 3/8

This week we wrote the design report.

We successfully simulated a game controller in Unity using the Arduino. We also received the rest of our electronic components and confirmed that they work as expected. We also made significant progress with game programming.

Design Changes

We have to make a slight design change with regard to pin assignments. Since only digital pins can be used for interrupts, we need an additional digital data pin. This is because we want to be able to use interrupts for reading encoder updates. We were originally planning on using one analog GPIO pin and one digital GPIO pin, and treating the analog pin as digital when we needed two digital pins for the encoder. We will now have two dedicated digital GPIO data pins and one analog data pin. This is not a significant change because we have the available pins that we need and our pogo pins have a spare pin available.

Significant Risks

The only risk we can think of at this time is the latency being higher than expected, but we will test this as soon as possible.

A was written by: Alan
B was written by: Angela
C was written by: John

Part A: Consideration of Global Factors

In general, the game we are designing is meant to be played at home with your friends physically next to you and hence lives in a very local space. But the general concepts that our project pushes toward have broader themes. In a more global context, our project contributes to the idea of more physical-oriented alternative controllers. Video games are a phenomenon that exist globally but many people are used to the same controller designs. Our project spreads more awareness of the possibility of controllers that can be uniquely created to enhance the experience of a specific game.

Part B: Consideration of cultural factors

Our product has a cultural aspect in encouraging players to play a cooperative game in person. The game is accessible to a wide age range considering that the modules have very simple controls such as buttons and sliders, so that young children and elderly people can both easily play the game.

Part C: Consideration of environmental factors

Our solution uses a microcontroller and the users’ personal computer, which use less energy than a large arcade machine. This efficiency is good for the environment since current power production often uses fossil fuels and other non-renewable resources.

Our design also uses easily repairable, open-sourced design, so users do not need to purchase a complete new set if something breaks. This reduces E-waste.

Posted on

John’s Status Report for 3/8

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.

Posted on

Team Status Report 2/22

This week we made progress on implementing game mechanics and created a GitHub for / started experimenting with Arduino code using the joystick library. There have been no significant design changes or schedule updates.

Significant Risks

The documentation of the Arduino joystick library is not quite through enough for us to be able to exactly predict how it will interact with Unity. We will need to do a bit of experimentation and iteration to make sure that the interfacing between the two parts goes smoothly. Now that we have the Arduinos, we have begun experimenting with the joystick library and next week we will try to nail down the integration with Unity.

Posted on

Angela’s Status Report 2/22

This week I finished implementing the player mechanics that weren’t finished last week as well as adding some sprites to the game. Gameplay features are now all implemented, except for enemies and enemy behavior, which I will be working on next week as well as working with John on Arduino-Unity interactions. Progress has slowed down a bit because of midterms, but everything is still on track Continue reading “Angela’s Status Report 2/22”

Posted on

John’s Status Report for 2/22

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.

Posted on

Alan’s Status Report 2/22

This week I decided on the electrical parts we needed for our modules and arduino connection and made purchase orders for them. We are getting a slide potentiometer for the speed. Rotary encoders for the shield and aiming. We will use potentiometers from CMU for the steering. And then buttons for battery and shooting.

On the hardware/software interface side, I started the arduino code. I’ve looked a bit into what arduino libraries we will need. I’ve also written out pseudocode for what our program will need to do and initialized a github repo for us to work on.

https://github.com/amabraha/c3-aquamods-arduino

For next week, there’s some design changes I want to make to the module’s 3d designs. I also want to make more progress on the arduino code.

Posted on

John’s Status Report for 2/15

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.