Month: October 2019

This week, we ordered a few more pieces of hardware that we need: our display screen, a GPIO extender (20 pins to 40 pins), and NRFL01 communication chips.

On the software side, we have been parallelizing the code we have, writing code for operating our speaker, debugging the IMU classifier module (the RPi connection with the IMU has a number of issues that we are currently working out), and filling out more details in our player class.

On the hardware side, we have most of the circuit read, and are prepping for integration (and the next time all of our components will be in the same place). Next week we will finish up our physical circuit and make sure our code (and all of those sensors) work.

This week I did some research into alternative solutions that could simplify some of our final fabrication work (using a knock sensor instead of a pressure sensor) that would avoid the issue of running a wire along the entire length of the staff. We have temporarily decided to include the pressure sensor in the mock-up to ensure it works, and are considering using the IMU for this purpose if no better option presents itself.

I did some programming work in adding our designed spells to our player class structure, and will continue with adding functions that execute on their function.

I have also constructed  much of the basic circuit, which is unfortunately incomplete as another teammate needed to use the RPi for sensor testing and we did not sufficiently coordinate our schedules. We plan to finish this work, integrate our systems, and start getting real data for our sensors and running our current code when we meet next.

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.

We are wrapping up software integration (as in integrating the modules we split up) and will be meeting next Tuesday in person to handle it. I myself have been subject to the wonderful compile time and runtime errors that are part and parcel of coding C without fully understanding its quirks. One particularly stupid mistake was a segfault caused by declaring a struct pointer in the header instead of a struct instance. Others include returning in a branch before freeing memory, and so on. Still, actions (or rather Git commits) speak louder than words, so head on over there if you want to find out. Or you can look at this pastebin entry for some understanding in our code. Note that I’ve exchanged macros for global constants because I wanted specific types, which as far as I know macros do not support.

https://pastebin.com/bUX2hL6d

This week we are in that fuzzy phase where individual software module’s bugs are being ironed out as we look into integrating. We have individually begun pairing software with hardware as the software is useless unless mounted on a Raspberry Pi and connected to sensors. Individual software modules are being tested and polished, bugs are being squashed, and preparations like prototype sharing are being made to ensure we can integrate the modules without too much unnecessary hard work. 

On the individual side, Dan has been working on more game design and software. Donghun has done work on the motion classification, and will be wrapping it up this week before integration. Eric has done a lot of work on handler functions, and has been a great asset in helping everybody else figure out how to iron out the kinks in connecting the Raspberry Pis with the software. Because of the limited number of GPIO pins, Dan and Eric have looked into purchasing a bus to expand the number of slots, as well as figure out how the physical construction will work. More details can be found in the individual posts!

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.

Progress

This week I have continued my work in making adjustments to the balancing of the game, including testing reasonable timings for how long it would take to cast the various spells.  In addition to the nitty-gritty numbers work involved in this, I have been working out the program flow of how we should process incoming spells and the expected cases we will encounter with regards to spell interactions on the software side.

I have contributed to the Design Review document, along with my teammates, and helped reconstruct and smooth out our Finite State Machine, as well as the general software structure / how it relates to the embedded elements.

Scheduling

So far, we are still on track with our schedule, which is heartening as we will no doubt run into bugs that we’ll need to dig into our slack time to fix. Next up is to build the staff prototype and build / attach our circuit.  This will allow us to test our code and ensure that our data is being processed correctly.

This week was the design review presentation, and as the presenter I have received a lot of valuable feedback. The team sitting next to us (sorry I forgot to ask your name!) suggested that instead of using Bluetooth communication, we should look into using a dedicated chip like the nRF24L01 transceiver for communication. Some preliminary research shows that people have already integrated it with both Raspberry Pi (which we are using) and Arduino. It’s about $12 for 10 modules, so while it would be nice if we can scrounge around or borrow it, purchasing it is also within our budget. Of course, I also received feedback about my presentation skills. My posture, small volume, and using my phone for speaker notes was pointed out, so I will work on incorporating the feedback before the next time I present.

Having been responsible for the IMU coding, I’m still working on it and should be able to complete it some time next week. Given the performance benefit we ultimately decided against using languages like Python over C.

Progress

I have been creating the structure of our Input/Output handler code that will be uploaded to the Raspberry Pi this week and tested with the circuit that Dan will be making. The I/O handler code will be relying on a sort of Object-Oriented coding structure that we’ve made in C. We chose C over Python because C code was measured to be about 110x faster than python code (http://www.spazztech.net/python-vs-c-on-rpi.html).

I’ve also been working to complete the Design Review Report in parallel with my teammates. We have gotten all the rough content down and now are going to bring it all together with correct formatting. The process of writing out explicitly what we want to do seemed tedious at first, but now I can confidently say that I’ve thought through a decent number of design issues we may run into that I wouldn’t have considered before. I am optimistic about this coming week and I look forward to using the Raspberry Pi more extensively.

Scheduling

So far our schedule is on track, we may need to revise our code once we start uploading to the raspberry pi, but we’ve allocated time to do that in the following weeks.