Darwin Torres’ Status Report for 4/30

This week, I worked on making our taps and drags more responsive. Before working on double taps, we felt it was best that the we improved the performance of our single-tap interactions. Overall, things were fine for our MVP, however there were a few hiccups, mainly with taps sometimes being registered as small drags and drags not appearing very smooth. Matt K and I came up with a solution where we would ignore additional position updates that occur within a small radius around an initial touch. This makes it less likely that we detect a small drag when the user is really trying to tap. We found that this solution was able to fix our first problem. To make drags smoother, we averaged every couple of position updates before sending a request to the OS. This meant a slower refresh rate, but smoother interpolation of coordinates along a drag. We tinkered around with how many position updates should be averaged, and we found 5-7 gave the best results. Overall, I feel I am on schedule, especially since the tasks that we have remaining are in addition to our MVP. Although I wanted to have a simple double tap test done this week, I felt the changes we made this week were more important to the user experience. Next week, I will work on implementing double taps so that we can hopefully be able to showcase it during our poster session.

Darwin Torres’ Status Report for 4/23

This week, I helped the team in performing the initial tests of completed integration of all subsystems. Initially, there wasn’t much I could do related to my subsystem as I had to wait the frame to be completed and tested. In the meantime, I worked on the final presentation and report. Once the frame was completed and Matt S and Matt K were able to confirm successful integration of their subsystems, I jumped in to test the integration of my subsystem. As always, a few bugs got in the way, but with the help of Matt K, we were able to get them out of the way. Eventually, we were able confirm the successful integration of all of our subsystems, allowing us to finally use Matt S’ laptop as if it were a touch screen device. However, for the time being, we are limited to single touch commands. The entire team got a good amount of progress done, and I would consider myself on schedule with my tasks. Next week, I will work on adding support for double taps.

Team Status Report for 4/23

This week, we connected all edges of the frame and spent most of our time debugging the hardware and software, as well as collecting data for measuring our performance against our use-case requirements. Beginning with the hardware, one issue we encountered was a misprint in the bottom PCBs. We were able to hack around this by soldering wires onto the board to fix the broken connection. Before we started testing our software with the frame, Matt S conducted some final debugging and checks to make sure there were no issues with the hardware.

Once the hardware was ok to go, we attached the frame to Matt S’ laptop and began testing of Matt K’s updated Arduino code, which controls the LED/Photodiode pairs and sends data about which pairs are activated to the python backend via USB serial. We encountered some bugs, but eventually after some squashing we were able to confirm that the control signals and output data were correct.

Afterwards, once we confirmed the Arduino subsystem was well-integrated with the hardware, we began our first true test of our entire system through a python script that used the data sent over by the Arduino to calculate coordinates and send commands to Darwin’s updated Touch Control subsystem. At first, a few bugs had came about due to a small miscommunication about the updated interface, but we were able to quickly fix them. Once we were passed that, we finally got our first glimpse at Touch TrackIR in action! Physical finger taps, holds, and drags on the screen were successfully translated to the expected touch inputs in the OS. We were able to click on links, close tabs, move windows, and scroll through webpages. The smoothness of the experience is acceptable, but we still feel there is room for improvement.  For example, we can reduce latency by increasing baud rate, removing print statements, and by simplifying the structure of the data that is being used in our coordinate calculations to eliminate unnecessary loops.

Overall, thanks to the progress this week, we put ourselves perfectly on schedule. Next week, we plan on constructing a cover for our PCB frame and adding support for double taps to allow us to perform “right clicks”.

Darwin Torres’ Status Report for 4/16

This week, with progress finally being made with our PCBs, I worked on updating our touch control interface and tests from the interim demo to be compatible with the final hardware. I also helped Matt S with soldering the final surface-mounted components on the remaining PCB boards. The tests that I developed have yet to be used with the hardware as I need Matt K’s updated code, which he is also updating to match our new environment, to be fully working so that we can check how physical inputs translate to touch controls on the OS. We are currently in the process of debugging our work so that we can proceed with physical testing on the final hardware, and we are aiming to have this done by Monday. With the conclusion of the week I am well on schedule, and overall things have been ramping up recently since we are finally back on track after receiving the decoders. Next week, I will work with Matt K in squashing our final bugs so that we can start testing to not only check the robustness of the software and hardware, but to also record relevant data to compare against the requirements we set in our design review. We will start by testing physical input along one dimension, which we already have the hardware ready for. This is essentially a scaled up version of our interim demo tests. Once the second axis is ready, we will test touch controls along both axes, which would be a major milestone as this will give us the capability to interact with any point along the 2-dimensional space of the screen.

Darwin Torres’ Status Report for 4/10

This past week, I helped the team in preparing our interim demo. The integration of subsystems B and C has been going well so far, so Matt and I designed some visual tests to showcase in the demo. Unfortunately, our decoders have not arrived, so subsystem A has yet to arrrive, but we were able to perform some initial “physical” testing with a breadboarded circuit. This allowed us to test our code that sends signals to the LEDs and processes signals from the photodiodes. Tests were successful, and we were able to set up a simple demo showcasing how interacting with the LEDs results in onscreen manipulation through emulated touch inputs. It was good to know that my code had integrated well with Matt’s. There are still a few bugs and problems present, most notably with the precision of our setup, but it will be hard to measure this accurately until we have the PCB completed. In terms of my software-related tasks, I am on schedule. Unfortunately, we have delays with the hardware, but we should be up to speed soon. Next week, Matt and I will work together in debugging our code. Once the decoders arrive, we will work together in completing the PCB so we can test subsystem A and get it ready for integration with our software. If I have extra time, I will start investigating multi-finger functionality within Windows.