Author: Donghun

We have a weird bug post-integration that we’ve been tracking down. I’ve mostly been editing the code so it’s easier to track it down. That’s pretty much it; except that happened for about 30 hours this week. Still haven’t finished the AI. What can I say except “integration.” Oh, there’s a cool tool to create Makefiles for you: (http://solver.assistedcoding.eu/makefilegen) that I used because I wasted so much time re-editing it.

Last week was Thanksgiving break (unfortunately I had to work in lab for 10 hours straight), but earlier this week I was able to find out that the IMU not working was due to a clock stretching error with the BNO055 when connecting over I2C with the Raspberry Pi. Decreasing baud rate from 100kHz to 1kHz solved the issue of random devices being detected at the very least, as well as the three-level logic issue. I am experimenting with various baud rates to minimize latency. I have also tried some suggestions from the RPi support forum  to figure out why one of the voltage directions has been flipped on the SCL and I should be good to go forwards.

Eric has managed to complete fabrication of the staff upper lattice. Unfortunately we did not account for the battery when we designed it, but it was an initial iteration and the next iteration will be roomier to accomodate the Raspberry Pi. Work is still being conducted on the communications system and bugfixing the IMUs. We finally have the issue that the LED strips cannot coexist with the sound system due to a conflict in software. Therefore, the solution would be to have all visual information to the player appear on the display. Audio feedback would be far more important when a player is immersed in the game, in any case.

The last week, I think I made the start of the breakthrough to the IMU issue. It is possible that the internal pull-up resistor on the RPi is not working. I tried a various combination of external pull-up and pull-down resistors, but the ones I’ve tried so far have not worked. Google gives a conflicting number of answers and the manual I found for the BNO055 didn’t clarify what type of resistor I should use, so I’ll have to look into the issue further.

When the project initially started, we purchased two BNO055 IMUs from Adafruit. I soldered the first two

so that it would be easier to insert and extract them into and out of the breadboards, as simply tying wires wasn’t the most reliable way.

But then,

the above happened. Normal operation would mean that we detect only one connected I2C device at address 0x28, and that happened for one IMU. For the other one, however, the addresses seemed to change randomly every time.

Following Jens’s advice I hooked up an oscilloscope. In the below image, the yellow signal is the clock (SCL) while the green signal is data (SDA) over the I2C protocol. Lo and behold, we have three-level logic: 3.3 V (the input power from the Raspberry Pi 3B+), ground, and 1.7 V. Dr. Kelly mentioned that it is possible that the 3.3V and ground were driving the data line at the same time.

I thought it was a defective product, so I bought another.

OK, 66% failure rate so far, so we returned the two defective items and got two more.

OK, that should not be happening. An 80% failure rate?

At this point the question became “how is one working?” rather than “how are the other four not working?” My conclusion is “i don’t know.” While getting more IMUs is an option, given that I soldered all five and only one turned out to work it may be an exercise in futility. The emergency plan going forward (unless I get another IMU to work) is to have a dummy staff controlled by an artificial “intelligence” going against a staff wielded by an actual human being. The dummy staff will not have an IMU, but rather receive artificial signals from an AI. The real staff will have the sole functioning IMU (whose magnetometer is still finicky about calibrating) and all the normal bells and whistles.

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.

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.

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!