Posted on

Alan’s Status Report 3/8

I tried printing out the current iteration of the module design. The 3D printing came out fine, but I need to make changes to the actual design. Currently there is not enough margin between the module piece and module holder for it to fit easily. I would attach a picture, but I do not have the 3d printed pieces on me at the moment.

I also wrote more code for the arduino. This can be seen on our github (https://github.com/amabraha/c3-aquamods-arduino). Most of the changes were refactoring toward generalizing the skeleton john wrote for our use case of interchangeable modules. I’ve also made progress toward our interrupt handler that will keep track of the state of the various rotary encoders that are used by the modules.

I also spent a lot of time doing work on the design report. I think that ended up being most of my Friday.

For next week, I am going to make updates to the CAD designs and print another iteration of the modules so we can see what we need to improve next. I also want to incorporate some of Gloria’s advice for the controller panels and get started on laser printing those. Lastly, I will continue working on the arduino code and integration.

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

Alan’s Status Report 2/15

This week I worked on designing  the controller parts. I did CADs of the modules and the panels. These are preliminary designs and will likely need to be reiterated, but they are functional and also somewhat easily adaptable.

I also did some brainstorming on the electronic design part of things. We’ve been having many discussions about this so it’s taken a while, but we are going with 7 pins per module. 2 for ground and Vdd, 3 for a binary identifier of the module type, and (at most) 2 data pins. Modules that utilize peripherals like buttons or potentiometers will only need 1 data pin, but more advanced peripherals like the rotary encoder will require 2 data pins.

We are a bit behind schedule for the hardware components, since we’re still finalizing the exact circuit schematics and what devices we are buying. On the bright side, we have already started and have finished a prototype of designing the controller parts. That ended up getting prioritized this week because we felt getting that down was necessary for our design review presentation. Which, speaking of, I also worked on.

For next week, I hope to finalize electric components so we can order those and then start getting the controller prototype assembled. Also we can start working on the arduino code since we got that shipped.

Posted on

Team Status Report 2/8

We’ve set up a Github for the Unity project and begun work on basic game mechanics. We have also done some preliminary research into electronics selection for modules and put in some parts orders.

Significant Risks

The most significant risk we see to our progress at this time is the complexity of the connections between the modules and the game panel. For our game to be enjoyable, it’s critical that switching the modules is fast, seamless, and reliable. This risk is being managed by handling this aspect of the project early on. As a team, we are discussing various ways to make solid electrical connections between the modules and the game panel. We are also looking at different ways to communicate between the modules and the panel. We are leaning toward mostly passive designs to keep the modules simple and minimize latency. A contingency plan we have is to focus on the simpler modules first and make sure that the MVP of our game works with them before moving on to more complex modules.

Significant Changes

We have not made any noteworthy changes to our overall system design but have made some changes to our module electronics. For example, we’ve decided to use an encoder instead of a potentiometer for one of our modules because it allows the users to freely spin the dial/wheel. This was necessary because it more closely aligns with our game design and how we’d like to control the submarine. It also allows the users to switch the module without it maintaining its state, since encoders do not output absolute position but rather direction and velocity. This will be slightly more expensive but still well within our budget so cost is not a significant concern. This is not a significant enough change to update our schedule.

Posted on

Alan’s Status Report 2/8

This week I made some thought toward the module design. We have agreed on having 6-7 pins per module. One pin will be gnd, one pin will be Vdd, 3 pins will be designated as the identifier of the module via binary, and the last pin(s) will be for transmitting data from the module to the arduino.

I also made the order for 2 arduino leonardos. I have started some preliminary research on the peripherals needed for the modules. I found this potentiometer    that has infinite rotation but it requires two data pins. We also might look into encoders but those are not passive devices..