Posted on

Matthew Kuczynski’s Status Report for 2/26/22

This week I continued my progress with the Python-Arduino interface and worked on routing the PCBs. Last week, I learned that the pyFirmata interface that we intended to use would not be fast enough to loop over all of the LEDs, so I spent a large portion of this work exploring alternative options. Eventually, I discovered that uploading the code that loops over the select line values to the Arduino is unsurprisingly much faster than using pyFirmata. In order to read the values from the Arduino, I developed a script using the Python serial library that did string parsing to get the digital values and the select value. The PCB routing task proved to be tough due to width of the PCB, and the Auto-router was unable to complete the task on its own. While some of the PCBs have been completed, the task remains ongoing. Overall, I think that I am on schedule since I am keeping up with the tasks in the Gantt chart. Next week, I plan to continue working on PCB layout and the breadboard-Arduino integration.

Posted on

Matthew Kuczynski’s Status Report for 2/19

This week, my main task was to develop and debug the Arduino software that could recognize the basic touch functionality. As explained last week, I chose to use the pyFirmata library to interface the Arduino with Python, so I started the week by preparing the software for actual testing later in the week. Once the parts order came in, Matt S. was able to build a circuit that we connected to the Arduino Mega, so that the software could be tested. As expected, there were many issues with the software that I had developed at the start of the week, so the later part of the week was mostly spent debugging. One struggle that I faced was learning how to use a pyFirmata iterator, which is built in to the pyFirmata library. At least to me, it was unclear that the iterator was necessary for the functionality that we needed, but once I properly added it to the code many problems were solved. The other large issue was that the time between writing the select line and reading the output was not large enough, so seemingly random values were being sent back to the Python code. For now, about 10 ms are needed in order for the values to be accurate, however we will need this to be faster in order to reach our MVP goal since we will need to loop over all of the LEDs. I feel that I am on schedule since I kept up with my Gantt chart goal this week. Next week, I will aim to help Matt S. with the PCB layout, work on frame sketches, and work on the Breadboard/Arduino integration.

Posted on

Team Status Report for 2/12

Overall, we feel that we made significant progress on our project this week. The most important update is that we switched from an analog approach for determining finger position to a digital one. This change affords us several advantages; for one, it eliminates the need for a preliminary simulation, giving us at least an extra week of slack. Additionally, it removes a lot of the complexity of an analog approach, as digital detection will be far more immune to noise. The largest drawback of this approach is that it is more brute-force than the analog, and we will need far more diodes, which could provide some challenges as to how we package the circuit into a limited form factor. However, we think the pros significantly outweigh the cons, as the digital implementation is less risky in the long run. Our block diagram from the initial proposal remains largely unchanged, since our initial idea was also a digital approach.

We have identified two risks that could significantly affect the outcome of the project. The first is that we have limited space on the bottom edge of the laptop to place the hardware. Before switching to the digital approach, this was not a concern since the hardware would have only been on two edges, but it now needs to be on four edges since we are creating a 2D grid. For the laptop we plan to design the product for, there is currently an inch of vertical space below the screen for the hardware to be placed, so we think it is possible that this is sufficient. However, since it is not a guarantee, our current plan would be to build outwards towards the keys if we need more space. With the shift of our schedule, we should have more time to focus on the design of the frame, so this hopefully help mitigate the risk. A second risk we have identified is that the cost of the PCBs may put us over our budget. With our new approach, we have decided that PCBs are probably necessary in order to hold the hardware components in place. We currently do not have a specific estimate of how much this will cost, but we our planning to figure this out in the next week. As a worst case scenario, we have decided that we could have a 2D touch grid on the side of the laptop if we become affected by these risks.

Updated Schedule:

Open photo

Posted on

Matthew Kuczynski’s Status Report for 2/12

This week I have been working on researching, testing, and prototyping the Python-Arduino interface for our project. Since we plan on controlling the screen functionality with Python, this interface is necessary in order to communicate the digital readings from the Arduino so that finger position can be determined. Additionally, we want to use Python to set the digital pins going into the decoder (see Matt S.’s diagram).

The most important part of my work this week was determining which platform/library was most suitable for our needs. Through my research, I determined the best interfaces were PySerial using Anaconda Prompt or similar, and pyFirmata. In the end, I found pyFirmata to be the best option because it is easy to use and felt more specific to Arduino in my opinion. The most important factor that I considered was if the interface would be fast enough to toggle through all of the combinations that we need. To do this, I tested how fast I could perform the standard Blink function on the Arduino by toggling digital pin 13 on and off as quickly as possible in a loop and recording the time that it took. A subset of the values that were recorded is included in the screenshot below. As you can see, the task usually took under 0.1 ms, although sometimes it took between 0.1-0.2 ms. Regardless, this should easily be fast enough since we are targeting a reading every 150 ms, and there will likely be less than 20 combinations per reading required in the end. This should provide sufficient time for the other calculations to be performed in each cycle. Finally, I was able to develop a small script that cycled through the combinations of D2-D4 pins that we plan to use (for now), as well as read from the D5 pin.

Overall, I am somewhat ahead of schedule on my tasks since we no longer deemed the simulation task to be necessary due to our switch from an analog approach to a digital one. We plan to adjust the Gantt chart to account for this, which will hopefully make our reach goal of multi-finger functionality more realistic.

Next week, I hope to combine my work with Darwin’s work in order to begin creating a Python code base for our project. Additionally, we hope to set up a basic physical circuit once our parts come in, so I will try to incorporate my work from this week into that.