Author: emendez

We’ve been working tirelessly to integrate all of our subsystems. The imu module and the listener control loop are almost integrated. The physical parts of the staff are all completed, but we still need to put it all together after we finish adding the communications and integrating the code modules. We have also been working on the Final Report intermittently.

Our schedule is now reflected by the schedule presented in the final presentation on Tuesday.

This week has been a grind to finish up. We initially started by making sure the presentation was done by Tuesday. We also have been working very hard to finish up the integration of our code for our IMU module and our main listener control loop. I’ve also finished up soldering everything to a gpio topper for the Raspberry Pi. I also finished 3D printing the 3rd iteration of the staff topper, which now has enough space to fit our pi, battery, imu, and all of our circuitry.

This week being Thanksgiving week, I could only work on software stuff because I left for break on Friday. I worked on debugging the sound output on the raspberry pi because for some reason, after trying to get the LED strip to work with the pi, I was unable to play the sound. We’ve decided to drop the LEDs in favor of the sound because we think the sound would be better for the player’s game experience. Also, the raspberry pi does not support the use of the 3.5mm AUX output in addition to the LED strip. With more time and resources, I would switch to using a USB speaker and the lights, but now that it is getting down to the wire, I don’t think I’ll have time.

This week I got the staff fabrication done! I did two iterations of CAD designs that I 3D printed in the ideate lab, and I took the wooden dowel to the woodshop to have one end on each cut into a square end, so I could easily fit the 3D printed part on it securely. The rest of my week was dedicated to trying to figure out the light and sound output on the Pi. For some reason, the library that controls the LED strips we want to use can’t be used with the 3.5mm jack on the raspberry pi. We’ve decided that sound is more important to the player than lights, so we’re going to drop the LED component that would have been used to display current spell cooldowns. Since we’re going to have a screen onboard the staff which is going to display the health and shield levels, we are going to use that display to show the cooldown timers.

We’ve gotten behind schedule due to several key factors that we did not anticipate. We only have 1 out of 5 IMU chips that work, and we can’t exactly keep buying them because they’re about 33 bucks a pop. We’re working on a plan to have a regular staff with the working IMU that plays against a dummy AI staff. This way we can show proof of concept of our initial design, but we won’t be able to have an actual multiplayer game like we previously wanted. We’ve talked with our Jens and Professor Kelly about this possible alternative solution, and they seem receptive after watching us struggle to debug the IMU this past week. Also now that we have enough Raspberry Pi’s to successfully develop our communications systems in parallel with developing the IMU and the game progress code, we should be able to accelerate our timeline.

With just a little over 2 weeks left before our in-class demos, we want to create the full staff construction by the end of this week. This way we will only have to finish building the circuit and finishing off the final touches of the code.

This week I worked mainly on getting the staff construction together. With Thanksgiving break coming up, we don’t want to get caught without the able resources to fabricate our end product. I created the 3D CAD design in TinkerCAD of the staff topper and Raspberry Pi Chassis. I got the prints started, and I’m waiting until Monday to pick up the prints from the IDEATE lab. The staff itself is here as well so I will be woodworking it either today or tmr depending on when my friend, who is a shop monitor, is on duty. We are going to shave the top of the staff down to a square shape so the topper of the pi can be attached firmly on top. I made the design with this goal in mind.

This week I got the sound to finally output correctly when called as a background thread. Also, we had our midpoint demo on Monday where I showcased our game processing logic. I’ve got almost all the i/o pipelines figured out in terms of the basic game. I programmed it so it would be easy to add more game logic on top of the pre-existing code. I was able to return our previously ordered LED strip because they would have needed a 12v power source, which seemed a bit much for a project like ours. I got some old strips I had from a previous Arduino project. These LEDs are going to be used to signal spell cooldowns as well as current spells being stacked and ready for attack. This week we plan to nail down the physical construction of the staff as well.

This week we’ve been ramping up for the demo as a team. We have been integrating our separate parts to create a basic circuit that will demonstrate our game logic and spell processing code which takes input from the IMU sensor. We still need to get working on the comms working, but once we’ve got our Individual staffs logic working, then we can work on cross-staff logic. The goal for the midpoint demo is to be able to use basic buttons to control the game while being able to create a spell payload using the IMU input processor code.  We will use the terminal output to demonstrate that our code logic is sound.

This week I’ve successfully added forking and child reaping to our code, but the sound player is still buggy. I’ve added more game flow logic and created functions that handle the imu data that’s being created in Dong Hun’s code. The spells are stored in an array initialized at 0 for each spell element. That spell array is passed to the other staff, and that damage is processed by the other staff. For the demo, we are going to just send the spell payload to ourselves and show how the game would process that. As for the schedule, we’re about a week behind because we need to get this preliminary circuit working. Programming in C is definitely a lot more tedious than we previously predicted.

This week I tested the Bluetooth of the raspberry pi and found it to be rather difficult to use. Especially if I was going to use it to connect the speaker. We are now using NRF24L01 chips which communicate through radio frequencies instead of Bluetooth, and hopefully, that will help simplify our staff communication code. I also got the display and gpio extenders for the raspberry pi so we have access to 80 pins instead of 40. We ordered this because the screen takes about 20 pins on the gpio. I also worked on creating concurrent programming for the speaker, so the code would fork(), the sound would play, and the main loop would keep searching for inputs until that sound process exited. The main process then cleans up the code using a sigchld_handler similar to the one I implemented in my 15-213 shell lab code from a previous semester. I haven’t quite worked out all the bugs, but I’m going to be debugging the baseline game code so we can start messing with the circuit Dan is going to create for testing. I also cleaned up the game flow code so that we would be able to receive inputs from buttons in the circuit and would be able to create an abbreviated output using the vibrating motors.

This week I got the Raspberry Pi setup with raspbian and learned how to control the GPIO pins. Using the library wiring.pi, I can control the GPIO pins in C code much like an Arduino, and the library comes preinstalled with raspbian.  I’ve also been updating our code with more output handlers and adding more easily testable code for the input handlers which will be able to process our spell cast and enemy attacks according to our input processing logic flow diagram that I’ve attached.