Author: dsaad

This week has so far been part of the home stretch. I have been working on the NRF24L01 chips with mixed results – while the chips are all wired up and much of the code is written, there appears to be an addressing / initialization of values issue that results in the transceiver and receiver never communicating.

I have gotten some recommendations for a new library and some other approaches and will be working on the issue over the next few days.

Due to this week being Thanksgiving break, we were mostly out of town. However, we’ve still made some progress. A notable advance was figuring out why the IMU wasn’t working – a clock stretching error occurred when the BN0055 was connected to the RPi over I2C. This has thus far been solved by decreasing the baud rate from 100kHz to 1kHz, and we are looking into various other solutions.

We had to sacrifice our plans for including an LED strip, as unfortunately the RPi does not support the use of the AUX output along with the strip, and we felt that the audio feedback would be a more valuable point for the experience (and the project).

Otherwise, we are working on getting our communication chips and display up and running – integration will be down to the wire but all our physical pieces are in place.

This week we all went on break, but as the demo is fast approaching, we’ve still been at it.

This week I have been working with some spare RPis and the NRF Radio Chips to get basic communication codes up and running. Much of my time here is in how to organize the communication – deciding who gets to speak and when, who gets priority, what to do in the case of a data collision, etc.

Next up is to get this up and running and integrated and to work on the display.

This week was particularly  busy (the confluence of several major assignments) so this was a slack week for me. I have been attending to the NRF chips and will be working on that for the next week.

This week involved a whole lot of CAD work. To start off, I took a number of measurements (staff diameter, to double-check, length of support neck, dimensions of RPi and estimated fudge space for wires and sensors, etc.). Then I started learning how Blender worked, but quickly saw that it was likely too complicated for the types of simple drafting we wanted to do for our project.

While searching for a replacement program, I found a 3D print-ready file and started working with FreeCAD (which could open .stl files). However, basic object manipulation in FreeCAD is both lengthy and difficult, and even resizing the existing structure took hours (most of which the program spent not responding).

Eventually, Eric and I teamed up and got something rolling with TinkerCAD, and now have a 3D printable staff head.

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

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.