In the first week of our project, we brainstormed the design for the chair, settling on a conventional office chair that we shall augment to house our electronics and contain the drive train for our motorized wheels. From there, we began researching the specifics or electroencephalography (EEG) technology to better understand what device we should use and how to interface with it.

Having settled on our project, our next step is to identify an EEG device within our budget that would allow allow us to differentiate brain activity to create 4 distinct outputs.

We met with a team that had conducted a similar project utilizing an EEG to discuss the challenges they faced in order to effectively use the device and prevent any issues from arising. Additionally, they allowed us to borrow their 12-channel EEG device for the duration of our project.

Our goal for the next week is to begin testing the device to familiarize with assigning brain activity to different actions.

We obtained our brain-computer interface (the EEG device), and began experimenting with it to see how it works and how we can effectively use it. We tested it on multiple people to determine how much of an impact hair volume has on the signal strength of the EEG.

Having now gained an understanding of how to use an EEG, we plan to begin experimenting with Node-RED, the software application which we'll be using to interface with the device.

Due to some technical difficulties, we were unable to progress too far, as we discovered that Node-RED and its underlying components were unable to run on any of the computers we currently have available. We spent the week researching alternatives and attempting to get around the incompatibilities, however were unable to come to any reasonable solution. As a result, we will have to wait for Adam to return from his research program at UMass Amherst and use his computer, which is compatible with the required software.

Our plan for next week, until Adam returns, is to begin constructing the physical parts of the chair, such as the housing for the motors, batteries, and other electronics.

Now that Adam has returned, we were successfully able to install and setup Node-RED. Following that, we were able to successfully connect the EEG to Node-RED and began researching how we could interpret the data received from the EEG. After some brief research, we were able to construct a node pathway that currently allows different programmable actions to take place based on the data interpreted from the EEG.

Next week, we hope to obtain a Raspberry Pi to begin the process of constructing the electronic components of the chair, and moving this project into a more physical testing state.

This week we were able to obtain the two DC motors and battery allowing the chair to move forward and back. Furthermore, we obtained the chair and built the applicable portions of it including the back and the cushion.  

Looking ahead, we decided to divide and conquer so that our focus was on assembling the chair and its electrical components and get the BCI up and running in our future meetings. This plan consists of retrieving a motor shield which will allow us to control the individual motor speeds and direction, further work on getting Node-Red up and running, increasing the accuracy of the EEG's results through the testing of various conditions and circumstances for our desired commands, and further improving on the idea and design of the chair's bottom. 

Next week, we hope to start or be in better position to assemble Nüromotus.

This week we 3D printed wheel to motor adapter and spray-painted our wheels a shinny silver. We also began writing code to interface with the EEG headset using Emotiv's API, Cortex. We discovered early on that the Raspberry Pi does not have reliable compatibility or performance with Emotiv's software products. Therefore, we shifted over to utilizing a separate laptop to connect to the headset and process EEG signals, with this laptop wirelessly sending the PWM motor controls to the Pi over a WiFi connection.

This week focused on writing the code to connect to the Cortex API and begin processing the mental commands. So far, our code is able to connect to the API, authenticate itself, connect to the headset, and begin receiving data. We also began testing different methods of interfacing with the output pins on the Pi, determining how we control devices such as LEDs and motors.

This week we focused on getting the parts of our circuit on the chair and the 3D printed components for the wheels, motors, and the microcontroller and battery on the chair. We added a foot rest to the chair. The footrest has some give to it, so we will reinforce it next week. We also added some lights on the undercarriage to bring some style to the chair. 

When we tested our motors with the wheels attached, we found that they would only start to spin at over 50% power. We started troubleshooting what the potential sources of error, checking if our motors were stripped, if the wiring was faulty, and our battery; ultimately, we concluded that our motor shield was severely lacking the required amperage needed for the motors.

We also completed the BCI code, allowing us to interpret mental commands from the EEG headset. As of now, there are no actions associated with these commands, as we are yet to connect the BCI software with the motor controller software. Before we connect the two, we need to ensure both are able to function properly. As such, we also began writing the necessary scripts for the motor controller, including speed control, safety limits, and implementing a standard protocol for us to wirelessly send commands to the motor controller.

We were able to use our EEG setup to turn on and off a LED. We still need to train our interpreter AI for the brain waves to get more accuracy with turning on the light, but this is great progress!

This week we tested our wheel-motor adapter by sitting on the chair and found that prolonged seating sessions results in the complete failure of the structural integrity of the wheel-motor adapter. We designed a new adapter, changing the infill to 100%. The new design could withstand substantial weight and continuous usage of the chair. Additionally, we reinforced the connection between the foot rest and the rest of the chair with metal brackets to make it fully stable. 

Next week we aim to research and acquire new motor drivers for the wheelchair.

The Talon SR motor controllers from the First Robotics robot were stripped and added to the wheelchair. These motor drivers can operate at 60 amps continuously but only have one output channel each. This is much better than our previous motor controller, the L298N motor driver, which had dual 2 amps outputs. We ended up using 4 Talon SR motor drivers. Adam soldered the Raspberry Pi, motor drivers, battery, and motors as well as adding power switches on the side of the robot to control both batteries. Terminal connectors were used to easily be able to separate different components from each other. 

Griffin worked on modifying the code on the Raspberry Pi PWM pins to work with the new motor drivers which operates with pulse widths between 1.0-2.0ms (with each extreme being full speed in one direction) with a neutral pulse of 1.5ms. This timing mechanism differs from conventional PWM control, and combined with the addition of two more motors, a full refactoring of the motor controller's code was required. Thankfully, due to the highly modular design of the code, it wasn't too difficult to swap out the old code for the new code.

We finally tested the new complete motor set up. We didn't get a response from the motors at first when simulating a BCI forwards command and had to trouble-shoot the problem. Errors in code and wiring were addressed to get the motors operational. We found out that using the same battery pack to power the Raspberry Pi and lights caused a voltage shortage for the Raspberry Pi, resulting in the motors sporadically moving during neutral signals. We got a second battery pack dedicated for the lights and made a 3D printed mount to attach it to the body of the chair. We got full control of all four motors from having WASD keyboard inputs simulate EEG data for neutral position, forwards, turning, and backwards.

The actual EEG headset that we are using has some random noise even with optimal training, so we added noise reduction to our code. This adds some latency but makes for a much smoother ride.

We started driving the robot around using simulated EEG data from a keyboard. The motors for the right wheel were outputting more force from the same PWM signal, so we modified the code to compensate the speed difference for the two sides. We modified the motor controller to operate on fixed speeds instead of variable speeds; this means a drive command prompts the wheelchair to smoothly accelerate and decelerate to predefined speeds depending on the command issued. We can precisely drive the wheelchair around now with the laptop keyboard.

Additionally, we found that our battery life was really low, partially due to the battery's age as well as its low Ampere-hour rating of 7.8Ah. We calculated runtime and found it was only around 10 minutes long, so we started researching batteries with higher Ampere-hour and settled with the Continental CB12260-NB, which would give us around an hour of runtime. After the addition of the larger battery, we fully finished our wheel chair and code and only need to train our headset.