Carlos Armendariz, Jorge Tamayo, Ji Chang | Carnegie Mellon ECE Capstone, Spring 2022
This week we were doing the design report, both writing the report and slides, so not a lot got done on the design front. We’re still on track.
I contributed by writing the introduction and editing the use case. I also started on the Architecture and Trade-off sections.
This week, Jorge presented the design review for our team. Also, we started writing the report that goes along with it.
Jorge worked on modifications to our keyboard schematic.
Carlos managed to get the Pi to communicate keyboard inputs for the first time, which is a big step in our software implementation. We should follow this up by prototyping our keyboard on a breadboard and seeing if we can integrate our inputs with our outputs.
Our meeting with Professor Carrington was originally supposed to be on Friday, but was postponed to Monday.
Schedule:
In terms of schedule, we have made progress on all fronts, so we are on good pace. It would have been nice to have the meeting on Friday as originally planned but we have done well to compensate for any delays so far.
This week I worked on the design review Report with the team, I presented our design review slides on Monday, and made modifications to the schematic. The changes to the schematic are the following:
I added new header pins which we plan to solder some male connectors to, this is for the interface we are making from the keyboard to the pi
Included a Frame for the schematic, mainly aesthetic
Rerouted some wires in consideration of the software. By including four new rows for the specific combination keys, it will help make our software simpler to implement.
These are the final steps before getting started with the actual pcb layout. This part shouldn’t be too hard but I expect changes to be made based on the feedback from the professor in HCI. I am very familiar with the PCB layout portion of Eagle and don’t feel its necessary to layout an entire board ill probably have to change, so I will wait until after our meeting and then proceed making the PCB.
In the mean time, I can get started on designing a little layout for our planned de-activating toggle switches and make a schematic, but that part should be easier to do than the main Keyboard PCB.
This week I worked on setting up the keyboard emulation on the Raspberry Pi and helped with the design review paper.
Getting the Raspberry Pi to work as a keyboard was not very complex, but ended up being somewhat time consuming due to some details I was not aware of to start. The link I posted in my last report had all the material needed to figure it out however. The one oversight I had was that I had originally connected to the Raspberry Pi via ssh over USB, so some of the settings to enable that interfered with the settings to enable sending key presses over USB. Once I figured out the issue, running the setup script from the website I linked caused the following window to appear on my Mac:
This means that my computer detected it as a standard keyboard, and sending key presses worked fine after clicking on “Quit”. With this done, writing the code for detecting GPIO pin changes and sending a keystroke to any host computer should be relatively straight forward.
With this done, I am still on schedule. I mentioned in my last report that I would also write the code for preliminary matrix scanning, but setting up emulating key presses was more involved than expected. However, writing the remaining code should be trivial now that the base functions have been shown to work. So, I’ll write the preliminary code that uses matrix scanning to detect and send key presses next week. Once this is done, the hardware will be the only thing left to complete for implementing a custom keyboard.
We’re currently in the Design Review stage, and we currently don’t have many parts for prototyping. So we’re making do with components scavenged from the lab.
The circuit above is meant to simulate the circuit below; it is the matrix used for the keyboard. The purpose of the circuit is to test if the Raspberry Pi can detect if a switch is open (or closed), and if so, which row and column. That is, the circuit itself can’t do that; it’s a problem for the software to handle.
The blue wires are ‘real’ wires, while the other colors are pseudo-switches. The point of this circuit is to check if the Raspberry Pi could detect changes in switches, so you can pull (and replace) the non-blue wires to simulate a switch opening or closing.
This may violate some rule, but R1, R2, R3, etc. are the Vcc columns, and C1, C2, and C3 are the Gnd columns. Real Vcc and Gnd can connect elsewhere.
In other words, all LEDs on the top row connect to R1, or the leftmost Vcc. All LEDs in the middle row connect to R2, or the center Vcc. All LEDs on the left column connect to C1, or the leftmost Gnd. It may be hard to see, but they’re labelled.
We couldn’t test it this week because we need a part to connect the Raspberry Pi to the breadboard.
Next week, we can look at the mouse.
This week I worked with my teammates to finish the design review presentation. I also started some testing with the Raspberry Pi to learn how to read and write to the GPIO pins. The gpiozero library that comes standard with Raspberry Pi OS provides all the functionality that will be needed for this. The following test script I made using Python was able to detect when pin 2 and ground were connected via a wire:
This means that the code for detecting whether or not a switch is pressed will be relatively simple once we have decided on a layout.
On the other hand, sending key inputs to a computer will be a bit more involved. According to this link , it appears that there is a gadget system in place on Linux that has the desired functionality.
Since we didn’t schedule the software to be started until after the design report was due, I am technically working ahead of schedule. The meeting we have scheduled with Professor Carrington isn’t until next week, so we are limited in certain areas that we can start working on. The software for communicating signals is independent of the feedback we will receive from that meeting, so I started work on it sooner.
For next week, I plan to write a preliminary script to handle matrix scanning from the GPIO pins. I also hope to nail down exactly what the process of sending key presses to a host computer will look like.
This week we worked on the design review as well as got a lot of work done on the software and hardware side of things. We are trying to stay flexible since we know a lot of the hardware may change based on the feedback we receive, but generally we have a good go ahead to work on the software.
We created a survey that we may want to change later on, but it gives us a more quantitative way to measure comfort and ease of use. We also have a preliminary schematic for our board, but we know it is very likely to change after our feedback. There are also other potential changes to wire routing that may make it easier on the software side of things.
Here below is linked the Survey we made, which is also likely to change based on our feedback, but it gives us a good idea of how were going to measure quantitatively.
In terms of schedule, we are ahead on the hardware side of things. This is mainly to make it easier once we get feedback to change our design quickly if needed. Since we cant get feedback until after the design review from the Professor in HCI, we need to stay flexible and be willing to change things, so being comfortable with Eagle well beforehand is very useful. On the Software side of things we are also on schedule.
This week we worked on the design review presentation, while also working on our project so we had some more solid metrics for the presentation itself.
We created a preliminary Survey together, with two different texts, each with a different level of difficulty, which people who test our keyboard will be asked to type. From these texts we will measure the errors through either software or visible observation. Beyond that, the survey also has some questions regarding the comfort of the device and some other metrics. This will hopefully give us more solid ground for our testing process.
In terms of work outside of the design review. I started working on the Eagle Schematic for the layout of our board. The PCB itself however, will likely change once we get feedback on the design review and after. This along with some of the other things my teammates have done means that we are actually somewhat ahead of schedule, but in truth this is necessary since some of our work is subject to revision once we get feedback from the Professor in HCI who specializes on accessibility.
Above is the circuit schematic. Generally the layout is solid, but the special characters like Alt, Ctrl and Shift are likely to change to allow us to make the software simpler. Besides that, all thats left is a component so that when we go to make the board layout we have some location for male connector pins.
As stated before, we are somewhat ahead of schedule when it comes to some concrete work, but that basically means we are on schedule, since our chance to speak with a professor in HCI was only available after the design review.
On Monday, we looked at keyboard circuits. Basically, how does the Raspberry Pi detect each key when you press it?
The one my teammates proposed was a matrix keyboard, and I proposed a series of cascading resistors.
With a cascade resistor keyboard, each key in a row is mapped to a resistor switch, doubling each time. For example, the leftmost might have 100 ohms, the second on the left has 200, then 400, etc. so that the voltage difference across the row would change every time a key is pressed. The keys have different resistances so that the Pi can detect multiple key presses simultaneously and interpret the analog voltage drop as a binary bitvector.
Or at least, that’s what I remember. This is a digital to analog converter from Microelectronic Circuits, which does what I wanted. Every combination of digital inputs will change the voltage in a discretely unique way, which can then be interpreted on the Pi as a digital signal via an analog to digital converter.
This seems to work, but we haven’t seen this work in other keyboards, so we’re going with the matrix keyboard. I’ll leave this here as a backup.
To see how a matrix keyboard works, see the team status report.
I researched matrix layouts to see if I could build them, and I can say with several degrees of confidence that I can.
This week I picked up the Raspberry Pi that we will be using to emulate sending keystrokes to a host computer. I also started looking at how we might use it to send keystrokes to a host computer. It seems like there are already some libraries that perform this task, so it may be worth looking into which ones will best serve our needs. Finally, I also scheduled a meeting for the team with Professor Patrick Carrington, an assistant professor in HCI who studies accessibility (among other things).