Week Four

9/12/18 - 9/18/18

Day One:

It was a concern to many when Mr. Harlow discovered that exactly half of the pins on the breakout board of the SlushEngine did not work. There are two pins coming out of the SlushEngine, but they each split into eight more ports for a total of 16. All eight ports for one of these pins did not work. First, we assumed there must be some hardware issue, but the problem was the same on the all the boards. Eventually, we realized it was a software issue which entailed quite a long time of looking through pretty low-level code. We discovered that the programmer of the code for SlushEngine, Mango_Kid, wrote code for what to do if the pin is 0, but simply forgot to put the code for if the pin is 1. Sadly, the solution was not as easy as copying and pasting. It took me and some others going through the code line by line, understanding what was going on, how the bit-wise operators were being used, and writing new code for how to transform the data it was receiving.

images/IMG_9542.png

A logic analyzer showing all the pins working

Day Two:

We were all beginning to transition to be working on our own projects and Mr. Harlow decided it would be a good idea to check that all of the Pis and their attached boards were working. I helped him out by going to each and hooking up some tests components. I attached a motor controller with a small dc motor to one port, and an LED to another. On each project, I would pull some premade code from Github, and if everything works, the motor spins and the LED blinks. It only did this on one of the projects. Some Pis wouldn't do anything at all when the code was run, some would return errors, and one Pi didn't even boot in the first place. I spent the rest of the day trying to discover what was wrong with the Pis. We went through many theories ranging from incompatible code to a bad chip for connecting a battery. After quite a lot of swapping components and images, it was discovered that some of the Pis had the wrong resistor soldered causing the pins to now be able to output a PWM signal.

Day Three:

I began work this day on the Robotic Arm Project. I spent most of the day figuring out where everything needed to be hooked up and assembling the whole thing setup. Finally, when I finished setting up the hardware, I tried to run the code for the arm. I had to switch branches for the code and download a new package and change many of the import statements to get access to the right files. Just the day before, someone had gone through the package that the robotic arm depended on and had switched the type of case used for the names of all the variables and functions but did not change the corresponding dependencies in the robotic arm code. So, I ended up slowly, error by error, going into many different files to change the case back to what it was before. Eventually, I was able to get the code to run, and a GUI appeared. Success!

images/IMG_9543.png

The Pi configuration for the robotic arm

Day Four:

I continued to work on the project, but ended up sidetracked for most of the day. Very early on in the morning, a peer came over to see how I had plugged everything in so that he could copy how I had it all laid out. Unfortunately, he accidentally knocked a powered wire into a random section of the board, shorting it out and making a "popping" noise. The Pi kept running, but after a while, I discovered that I could no longer write to many of the pins. I wasn't sure if this was related to the board shorting out earlier, but after much experimentation of changing the code, and switching around hardware, I discovered that one of the components on the MIB had grown very warm and was not working anymore. Switching that component out resolved the issue.

Day Five:

Many parts of the robotic arm were functional, but there was still a lot more to get working. The arm itself was still not moving up and down as it should when the GUI button was pressed, but for some reason, the physical button on the motor controller would move it. What was also strange was that an LED would turn on, on the motor controller when either button was pressed. After some time, I came to the conclusion that the PWM values that were being sent as a default were not working. I experimented with a bunch of values in hexadecimal and discovered that by setting the PWM to 0xf000 when the arm should be down, and 0 otherwise, would make everything function correctly. I then worked on getting the sensors to pass on their data to the Pi. One of the sensors had to be replaced after I discovered it was not working at all, and near the end of the day, I, with some help, discovered that a resistor needed to be enabled for the slushEngine to read the data from the sensor.