Posted on

Gram’s Status Report for 02/25/23

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I helped prepare the slides for the design presentation and started working on the design report, incorporating some of the feedback we received from the design presentation.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

We’re slightly behind based on our original schedule, but also a lot of the tasks we had originally listed were allotted more time than they actually needed. We updated our Gantt chart to reflect this which puts us back on schedule.

What deliverables do you hope to complete in the next week?

I will continue working on the design report with the rest of my team and finish it by then. Additionally, I’ll work on assembling the ML pipeline so we can start testing and collecting training data.

Posted on

David’s Status Report for 2/25/2023

What did you personally accomplish this week on the project? Give files or photos that demonstrate your progress. Prove to the reader that you put sufficient effort into the project over the course of the week (12+ hours).

This week, I presented our design proposal in class with our updated key design decisions. We also started writing the final report on the detailed design of our project. However, we did not make significant progress yet since the design proposal feedback was only sent yesterday.

Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?

Our original schedule did not take into account the entire design review process, so by our original Gantt chart, we are behind.

As a result, I updated our Gantt chart to take the adjustments in schedule into consideration. I realized that some tasks I indicated on the chart will not require as much time as I expected like assembling the circuit, so I adjusted the chart accordingly.

Planning out the entire schedule was quite difficult since we did not properly look into the exact timeline of the design report. I also failed to take into account Spring Break, so I had to make some adjustments to the schedule. I expect that we’ll have to adjust the schedule again since some tasks may end up taking longer than expected in the future. The key is to perform as many parallel tasks as possible if the schedule needs to be adjusted.

What deliverables do you hope to complete in the next week?

In the next week, I hope to finalize and submit the design report.

Posted on

Team Status Report for 02/18/23

Risk Management

The most significant risks that could jeopardize the success of the project are if it turns out that the ML model we use is too slow or inaccurate to create a usable product. In case this happens, our backup plan is to replace the ML model with a heuristic algorithm that analyzes the time-series data as they come in. This would allow us to make certain gesture predictions using a basic decision tree that can easily run on the compute module quickly.

Changes/Updates

The block diagram was updated to include more detail about what specific sensors and communication protocols we will be using. This is still in line with our original proposed plan, just with more detail.

Gestures

While brainstorming what gestures we would support, we thought about how we might enable or disable activation of the gesture recognition/transmission. We originally proposed having another switch alongside the power switch to control transmission, however with further discussions with the professor and TA, we realized that it would be too unwieldy for a user to do that. Instead, we opted to come up with a custom gesture that could be used to enable or disable the transmission.

Further details on the gestures are described here: Gestures

Principles Used

  • Maintainability – we drafted our design docs to be easy to read so that if something breaks down the line, we can quickly refer to it to identify the reasoning behind certain design decisions
  • Modularity – Our device was designed with modularity in mind so that if a single part breaks, it will be easy to quickly swap it out with a working component
  • Testability – our system was designed so that it would be easy to test individual units as well as the system as a whole
  • Integration – we designed our system to integrate with existing infrastructure in the environment of our intended users. Examples of this are leveraging Wi-Fi and USB as communication protocols between our systems and with peripherals
  • Usability – usability is at the core of the design choices we made. This was evident in how we opted to go for a gesture to enable or disable transmission as opposed to a physical switch
Posted on

Gram’s Status Report for 02/18/23

Updates

Block diagram updates

This week, I identified more specifically what sensors and communication protocols we will be using for our device. I also worked on the wiring between the different components and microcontrollers — illustrating how many wires we would actually need between components. I updated our block diagram to reflect this:

Communication Protocols

For the accelerometer, we found from the MPU-6050 IMU datasheet that it communicates using the I2C protocol. For communication between the ESP32 (gloves) and the Raspberry Pi (compute module), we originally only said that we were communicating over Wi-Fi but we had not yet thought about what protocol we would be using to communicate. I researched into what protocols were common for high-frequency updates from IoT devices and found the MQTT protocol to be the best fit for our setup. MQTT works similar to various other pub-sub systems while minimizing communication overhead. Moreover, there are existing MQTT libraries we can use for the ESP which can connect to an MQTT (Mosquitto) broker on the Raspberry Pi server.

Gestures

This week, I also worked on refining the exact gestures we would recognize. I worked to help break down our conceptual actions (zoom, pan, and rotation) into concrete gestures that we could recognize. We managed to break this down into 5 specific gestures:

  • Enable transmission
  • Disable transmission
  • Zoom in
  • Zoom out
  • Rotate
  • Pan

The gestures are explained in more detail here: Gestures

Schedule

Currently, we are still on schedule to finish the project in a timely manner.

Upcoming Deliverables

This coming week, I will be working on formalizing these design decisions in the design report. Specifically, I will work on finding resources to back up our design choices and, if necessary, modify them if resources state otherwise.

Relevant ECE Courses

  • 18-100, 18-220, 18-240, 18-794,
Posted on

Xuan’s Status Report for 2/18/2022

This week, we spent time refining our design. One thing that came up was the actual gestures that we were going to use. We translated our three general gestures, zoom with a pinching gesture, pan with a swiping gesture, and rotate with a rotating gesture, into specific gestures described in three aspects: flex sensor output resistance, accelerometer measurement, and gyroscope measurement. For example, this is our more detailed description of a zoom-in gesture:

Pan

  • Grab: partially closed hand as if you’re grabbing an object (half curl)
  • Pan: Move your hand while keeping the same finger positions

Flex: all constant mid

Acc: changing x

Gyro: Constant

 

We also realized that our zoom-in gestures and zoom-out gestures have to be different because we don’t want the gesture to be reversible. We wouldn’t want the user to zoom in, then when they let go of the gesture, the detection might trigger a reverse if we’re using the same gesture. Along with a more detailed design, we also worked on our design presentation.

I think our progress is still on schedule because we have already received our Pi, and the original deadline this week was to put in the bill of materials. Next week, we hope to receive our other materials and start building the glove, along with initially writing up the gesture detection mechanism.

Relevant ECE Courses: 18-290, 18-220, 18-349

Gestures

Posted on

David’s Status Report for 2/18/2023

This week, I spent my time working with Gram and Xuan on finalizing some key design decisions. We discussed the the specifications for the gestures that we intend to implement in our project as well as determine if these gestures are intuitive. This part took a bit of thinking because we wanted to make the gestures distinct that users would not accidentally perform a gesture they did not intend. In addition, we are also considering an alternative design for a non-ML-based system which would end up having smaller latency.

Aside from discussing these design decisions, I also assisted in creating a more detailed block diagram for the entire system which elaborates on the protocols between each of the modules as well as enumerates all hardware components in each module. We can then tie all the things we purchased back to this diagram.

So far, I think we are on time in terms of our schedule and the next part of the work would be to finalize all of the design decisions formally in the report.

Gestures

Block Diagram

Relevant ECE Courses: 18-100, 18-220, 18-349

 

Posted on

Xuan’s Status Report for 2/11/2023

I spent the beginning of the week finishing the proposal slides, and practicing and delivering the presentation. We first revised our initial proposal submission based on the comments provided by the Professor and proceeded to draft the slides. To be honest, I was a little nervous about finding out that I had to go first on the same day the order was revealed, but I think I  was able to present just fine.

In our original timeline, we were supposed to discuss and order the materials by next week. However, we decided that we had a lot of time left, so we were able to finalize our Bill of Materials this week. In particular, we swapped out our proposed solution for a Jetson in favor of a Raspberry Pi 4 because of the Jetson’s incompatibilities with HID and the need for an extra Wi-Fi module. Gram was able to send in the order, so hopefully, we would able to start working on the actual project next week.

Posted on

Team Status Report for 02/11/23

This week, we worked on preparing for the proposal presentation slides as well as presenting it during class. In line with this, we planned out the schedule and timeline to

Later in the week, we finalized discussions related to the components of the Compute Module. Afterwards, we were able to refine our block diagram, replacing the originally proposed Jetson with a Raspberry Pi 4 and Coral TPU combination.

After finalizing the list of materials, we put in our orders through the request form for all the components except for the Coral TPU. Currently, it appears that the Coral TPU is out of stock everywhere, so we will postpone the order for this part until later in the semester.

Our project includes considerations for society. By tailoring this product for educators and presenters, we can help improve the effectiveness of education around the world which will have downstream effects across all aspects of society.

Posted on

David’s Status Report for 2/11/2023

On the first week, I helped out with the presentation slides and constructed the Gantt chart for the entire team. Along with creating the Gantt chart, I discussed the work times required for each section and assigned tasks to each of the members of our team.

Aside from the presentation, I also discussed the Bill of Materials with the other members of the team. Prior to this discussion, I suggested that we could use the Coral TPU USB accelerator as a cheaper alternative to a Jetson. In addition, I researched the requirements to use a Raspberry Pi 4 as a USB peripheral device and determined that we can use the USB-C port for data communication. The problem now is that we need to power the device while transferring data, so I added a data/power splitter to the BoM.

Posted on

Gram’s Status Report for 02/11/23

At the start of the week, I worked with my other groupmates to prepare slides for the proposal presentation presented by Xuan. We refined our requirements based on feedback provided from our initial proposal submission.

I also refined our block diagram this week.

After discussion with my group, we decided to modify our original design. Instead of using a Jetson as the controller for the compute module, we decided to make use of a Raspberry Pi 4 with a Coral TPU accessory instead. This works better because of many reasons:

  • Raspberry Pi + Coral TPU is significantly cheaper than a Jetson
  • Raspberry Pi supports Wi-Fi out-of-the-box
  • Jetson doesn’t appear to support HID behavior

Later in the week, after finalizing our block diagram, I helped draft our Bill of Materials. After we finalized our list, I put in the orders on the Google Form.