Month: November 2019

This week I have been working more on how to work the NRF radio chips & SPI protocols, but have also pivoted to some other ongoing tasks. The search for a displacement display is ongoing, but i reached a decision on the knock sensing (we are now using a simple accelerometer to detect a sudden vertical deceleration rather than ordering a whole new sensor whose sensitivity we can’t set). I have finalized the artwork for the game, and have been looking over the particular values / parameters of spells to ensure that they are in line, but further testing will have to wait until our first physical prototype is built.

Much of my time this week has been dedicated to learning blender / CAD software in preparation for physical construction. I am currently editing a file that we hope to 3D print to form the head of our staff. I have several size specifications at the ready, and should be able to resize, edit, and print the staff head soon. My predicted obstacle here is working out hinges and clasps that would allow us to access the RPi, battery, and other systems easily.

This past week, we had a preliminary demo for our project. During the demo, we were able to successfully show that our device receiving data and “sending out” data like attack spells thanks to Eric, who has also shown we can start a multithreaded approach to the project to handle synchronization issues. Dan has pretty much completed the artwork for the game as well as the numbers for attack, defense, and healing, although exact balancing is a continuously evolving issue. He has been working on finding a solution to integrate the NRFL01 communications chip, as well as picking up CAD software for printing the staff head, and Donghun has been working on resolving the issue with the IMU module. Possibly due to soldering, one of the IMUs has been damaged beyond repair and the other’s magnetometer won’t calibrate, forcing us to order a replacement. As always, see the individual posts for more details.

We have received a new IMU unit and two battery packs for the raspberry pis, and tomorrow we are meeting to work on deciding how to fabricate everything. We have already put in purchase requests for parts like dowels, so hopefully when we finalize things tomorrow it will be smooth sailing from now on.

This past week, we had our preliminary demo. While the directional part of the IMU module was working properly, last weekend we discovered that the other IMU was not working, so our idea of having two IMUs ready to demo did not work out. The other IMU had problems with the magnetometer, leading to a “garbage in garbage out” situation with the motion classification as well as issues with IMU accuracy due to the accelerometer. Maybe my soldering skills were rusty, so I ordered a new IMU unit to test without soldering to see  if that was the issue. In my defense, I shall invoke the time-honored tradition of blaming the equipment. Most of the soldering irons in the lab were complete garbage and could only melt solder at certain angles after a certain amount of time instead of melting the solder instantly. Anyways, tomorrow we’ll go into some basic fabrication so we’ll see how that goes.

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.