Pato MontalvoWhile discussing the scope of the project, we had different ideas about the functionalities the device would have. We had been considering multiple features until that point, but nothing was really set in stone.
That is why we decided to evaluate the potential the device could have. Through research and discussion, we attempted to define its capabilities.
We settled on the following functionalities:
- MIDI Instrument: A mouthpiece simulating a harmonica will be built to control a Musical Instrument Digital Interface (MIDI). The device will have 13 airways with built-in air sensors, each of which can be configured to execute different commands. As a musical instrument, it would be able to play numerous octaves and notes through the interface.
- Gaming Controller / Mouse: The device will also work like a computer mouse and a gaming controller. It will support numerous additional outputs including left and right-click to game function buttons that are on typical gaming pads.
- Keyboard: The13 air sensors will also have a “key” functionality allowing users to “type” using the harmonica.
Our next step was starting a critical to quality analysis (CTQ) where we defined the critical aspects of each functionality. Initially, we did this separately, with Shu and I making our own analysis. Then, we evaluated each other's work and created a definitive CTQ analysis by aggregating the individual ones. The diagram below is our final CTQ showing the requirements for each functionality.
The full diagram can be viewed from the link below:
Creating this diagram was an important milestone. It opened the doors to the exploration of the components that would be needed to make all of these functionalities possible.
I know that getting an idea of our full CTQ is difficult from the diagram alone. For some of the requirements, we had long discussions to clarify what each of us meant. I’ve listed the details we discussed for some of the key requirements that are worth mentioning below.
“Must also be able to function as MIDI pad and knob controller”
We initially only had a MIDI keyboard in mind, but we realized that by adding a potentiometer to the device, it could also function as a MIDI knob controller and MIDI pad like in the image below.
Figure adopted from the image cited below.
(B&H Photo, 2020)
“The controller must be as universal as possible and support many users with different needs”
We know that cerebral palsy has a wide range of effects on motor controls, and this is different for everyone. Although we know that this device alone will not be able to support every user with cerebral palsy, we want to do our best to help as many people as possible. One way we’re planning to do this is to make everything, including hardware, electronics, and software open-source. By making everything open to the public, we believe that a community of users and developers could come together to share hardware and software customizations.
As we design our product, we will also keep in mind about universality. For example, we’ve already decided to use 1/4-20 UNC threads, the most common type of thread used in consumer-grade cameras. This will allow various camera accessories such as flexible tripods or stands to be used in conjunction with our device.
We believe that small design choices like this can add up to make our device as universal as possible. Additionally, we know that making this device truly universal is not possible, and perhaps this is the most challenging aspect in designing adaptive devices; however, we believe that creating a user and developer-driven community will give the best chance for this device to reach its full potential.
“The device must give some sort of live feedback → i.e. haptic feedback”
We added this to our CTQ after we had a mentor session with people from the UCPLA. One of the mentors, Aragna Ker suggested that having some sort of feedback to indicate that the device has taken action would be useful for the users. Instead of just hoping that the result will show up on the computer, it would be more helpful if the device gave out an indication that the device was used. As of now, we are considering adding haptic feedback similar to vibration motors in mobile phones.
“Must be easy to program, to change settings on what each airway do”
We plan on making a dedicated software to allow users to fully customize what each of the airways in the device does. We will have a “default template” of what each of the airways does, but should the users want to customize the device for different programs, we want to give them this option. For example, in many of the common web browsers, pressing CTRL + W closes the active tab. Typing this command through our harmonica unit would be difficult. Using the dedicated software, the user would be able to program the device such that when he puffs into the 13th airway, it would type out CTRL + W at once. Of course, this is just an example and the possibilities are endless. This feature would be especially useful for professionals that need to use programs that require shortcuts such as Adobe Photoshop.
“Must support multiple devices to be used simultaneously”
We know that the physical airways, joysticks, and the potentiometer built into one device may not be enough to fulfill the needs of every possible application. For example, in composing music in DAW (i.e. Garageband or Logic), many musicians like to have a MIDI keyboard in the front and a MIDI drum pad or MIDI knob on the sides.
(SAE Institute, 2020)
We want to allow multiple of our devices to be used together at the same time. For example, the device in the front could function as the MIDI keyboard while the device on the left side could function as a MIDI drum pad or a MIDI knob controller.
“Must allow other developers to support more external devices → i.e. open-source library”
We mentioned this briefly before, but we want to make our device as open as possible to allow other developers to expand the applications of this device. For example, there are many electric wheelchairs in existence. A user supported by a developer could customize the device so that it could also control the wheelchair as well. The source code or additional hardware required to do so could be shared within the user community so that others with the same wheelchair could make this modification as well. This of course not only applies to wheelchairs. It could apply to smart home appliances, other types of MIDI instruments or other everyday home appliances. A strong developer community behind our device will allow new functionalities to be added over time continuously while adapting to more consumer appliances that users with cerebral patients may want to use.
References
B&H Photo. (2020). MIDI Interface
https://www.bhphotovideo.com/images/images2500x2500/arturia_230501_minilab_mk_ii_1299531.jpg
SAE Institute. (2020). Image showing a typical MIDI setup
from https://dr4s1fmfmn4kr.cloudfront.net/images/facilities/sae-leipzig-midi-studio.jpg
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.