Team A5

This week’s efforts have primarily been directed towards preparing for the demo. We have been undergoing integration of our various systems and contributions, and ran a few more complications in that field than we expected to find.

Our goal for the demo is to demonstrate the basic circuit, our game logic, and our spell processing code, which will take input from a few hardware buttons and from the IMU module once it has been debugged. We will use terminal output to demonstrate that our code logic works.

Our current target is to get a single staff working, but we are ramping up our efforts in the communication department, and will begin work on communication between staves and integration of the NRF24L01 chips. In the meantime we plan to use a team member’s spare RPi 2 until we can secure a second RPi 3 B+ either through the ECE program or through purchases.

On the code side, we have had a number of advances – our code has working forking and reaping of threads, our game flow logic is more developed, and we have more functions for processing data being handled to the main loop from other modules, namely the IMU module. Core data structures include our spell payload (an array containing the spells cast), which will be sent via comm line to the partner staff, which then executes the contained spell on itself, and an internal struct containing a list of our various spell effects and severities. Our sound player is mostly done, but there are still a few bugs left to root out before it performs as desired consistently.

The IMU motion classification module has had issue with accurately categorizing motions. We took measures to try to mitigate this issue – using the GNU Scientific Library to integrate, ensuring minimum movement lengths are respected – but these will unfortunately not be ready by the time we have to demo.

We additionally had a few unexpected hardware issues – the SD card we had been using with the RPi appears to have broken. Various partition management programs have only been able to locate 30 MB of RAW format space on the SD card when it should have 8 GB of space. After extensive attempts to find information on the issue and repair it via software, we have come to the conclusion that the card has to be replaced. On the bright side, that replacement SD card is currently on the way, so debugging efforts shall resume soon.

Various unforeseen bugs related to running code on the RPi, including a fair number of errors on our part, delayed our physical integration process, and we are unfortunately behind schedule on this front.

We also realized that both the NRF24L01 communication chip and the display screen we had planned to use needed the Serial Peripheral Interface (SPI) to operate. We have begun a search for a replacement screen of a comparable size (3.5 inches) that uses the built-in display port on the RPi 3 B+ rather than the GPIO pins, but that search has yet to yield rewards. On the other hand, we have identified a shock switch that we can order, integrate, and test to fill the role that we once expected the pressure sensor to fill.

This week I dedicated my time to reading through a wide variety of datasheets, tutorials, and forum posts for managing the NRF24L01 chip (especially paying note to pins and wiring and tutorials for communicating between two chips). However, we will need two RPis to test and debug the code – as a stopgap until we can either get a second RPi 3 B+ through ECE or order one, I plan to use an RPi 2 as the second communication node.

Unfortunately, we ran into a number of unforeseen bugs and issues related to running code on the RPi. As a result, we have fallen behind schedule on circuit fabrication, and have not yet been able to test a number of our components.

We also had an unexpected issue wherein both the communication chip and the display we had planned to use needed to use the RPi’s Serial Peripheral Interface (SPI), as the display screen we had found was designed to fit over the RPi like a case. I have been, and am still looking for, a small (~3.5 in) screen that can connect directly to the RPi display bus. Most of the available options in this domain appear to be RPi proprietary large screens, but the search is ongoing. If we do not find such a screen, we may need to figure out some form of workaround to ensure both of the systems that require the SPI can function rapidly and consistently.

I have also identified a shock switch that we can use to test with our system. We should be able to place in an order soon.

The past week, the team has been undergoing integration efforts. Currently the IMU motion classification module I am responsible for has issues with getting accurate motion classification. I had been trying to use the GNU Scientific Library to perform integration to ensure that proper minimum lengths are respected, but that feature will unfortunately not be ready in time for the demo. A further setback is that the spare micro SD card I inserted into my Raspberry Pi seems to be not working-tools like the Windows native partition manager, Partition Manager, and EaseUS Partition Master can only find 30 MB of RAW format space in the SD card, far less than the 8GB it is supposed to contain. After three hours of searching Google and downloading software of varying degrees of sketchiness, I came to the conclusion that the micro SD card has to be replaced: it has been damaged beyond the point of repairing via software. Still, tomorrow a new micro SD card will arrive and debugging efforts will continue.

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, 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.