Developing a Customised Assistive Solution: Philip’s Engineering Internship Experience
By: Sarvnaz Taherian Ph.D
Tags: Disability, Assistive Technology, Biomedical Engineering, Internships, Design

My internship with Thought-Wired started in May 2017, after I met Dmitry and James at the AUT STEMpreneur event, where they shared their experience starting their tech start-up.

My Background: From Psychology to Engineering

In 2011, I graduated from the University of Auckland with a Bachelor of Science, majoring in Psychology. I thoroughly enjoyed the course, but the classes were theoretical and I didn’t feel that they would help me in developing a career outside of research in an academic environment.

Therefore, in 2012 I enrolled into AUT’s Bachelor of Engineering programme and graduated with 2nd class honours last year. Currently, I’m pursing a Master of Engineering degree with AUT. My research topic focusses on developing a software robotic controller.

Combining my background in Psychology and Engineering, I have always had an interest in the fields of Brain-Computer-Interfaces, machine learning and biomedical devices to help individuals who live with physical impairments.

Focus of my internship: Developing a customised add-on solution for nous™

In June, I started my internship with Thought-Wired and I was given the project of developing an add-on for nous that is customised for a patient with a rare, neurodegenerative disease called “Multiple System Atrophy” (MSA).

At first, I was tasked to build a standalone graphical user interface (GUI) with the functionality of capturing and analysing data from a sensory device. The original purpose of incorporating capturing and analysing signals with nous™(which captures and analyses focused attention-based EEG signals), was to utilise the remaining physical and cognitive capabilities that the patient still had, to maximise her ability to communicate with her family and the outside world.

When I first joined the project I was informed that the only physical capabilities that the patient had was tilting her neck and partially lifting her forearms. However, due to her condition, while I was still learning and experimenting on ways to capture input from her, I was informed that the patient had lost the ability to lift her lower arms, thus eliminating this movement as a possible communication method.

So I shifted my research focus to building the GUI for real-time data acquisition and analysis of signals captured from her remaining physical capability, while keeping in mind that the code should be kept as modular as possible, such that it can be easily implemented into nous’ main architecture.

Challenges with building the add-on

Building the basic structure of the GUI itself wasn’t too much of a challenge because I’ve built several throughout my studies. One of the biggest challenges when designing the GUI was trying to debug the code when there were no apparent faults in the logic or design of the code! I was baffled for several days when the GUI didn’t display the captured data in the manner that I designed it to do. The design and implementation of the code didn’t suggest any flaws or bugs when it was being checked repeatedly.

This is when I asked for Thought-Wired’s senior software engineer, Sean Carmichael, for advice on how to debug the problem that I was experiencing. After he sat down with me, and listened to how I designed and implemented my code, he suggested the bug may not be due to design or implementation flaw, but maybe something to do with hardware design or inherent capabilities of the compiler in which the GUI was written in.

After our discussions, we went over some data-sheets, experimentation and documentation, where we found that this was indeed the case! The fastest data processing rate for the compiler was significantly slower than the fastest data handling rate the hardware could handle. When we ran the GUI and hardware at the fastest sampling rate, the GUI was unable to process all the data acquired from the sensory device.

Takeaways and lessons learned

From there I found a way to work around this problem - but the biggest learning for me was the difference in applying knowledge in a real-life situation, compared to knowledge learnt within classroom/lecture settings. This is especially apparent when it comes to fault finding and understanding the underlining situation when you have little information to go off of.

Another important lesson I’ve learnt is that it’s difficult for universities to teach the practical skills required for real-world situations - even for AUT, which is renowned for taking a practical approach in educating its students. A lot of the material that universities teach students (especially in STEM related fields) becomes outdated quickly, are inapplicable in real-life situations, or are not taught extensively enough for students to immediately apply them to their job roles. For example, throughout the internship there were several algorithms that I wanted to try to implement but quickly found out that they are either too impractical to implement, or the learning curve is so steep that it is improbable to implement- especially given the time constraints of an internship.

Before I sign off, I’d like to thank everyone at Thought-Wired for providing me this chance to do an internship with them. It has provided me with valuable experiences beyond measure. Most importantly, I realised the areas that I need to work on the most, and strengthened my determination to continue a path in pursuing a professional career in the fields of BCI and machine learning.