Posted on

David’s Status Report for 3/28

This week, I worked with Aidan on assembling the Dawggles. After displaying example words and pictures we noticed warping so I investigated possible reasons for such an occurrence. It seems as though changing the angle of the beam splitter and the distance between the display and the lens and the lens and the beam splitter can resolve these issues. While it is not something that needs to be immediately fixed as it only occurs on the edges it is something to keep in mind moving forward.

We are on schedule.

Next week, I plan to continue working with Pat on the software and have an outline going for our server that exemplifies simple functionality, such as using the button to take a picture.

Posted on

Team Status Report for 3/28

The most significant risk to the project is the optical system being unable to reach the specifications that we outlined in our requirements document. As mentioned in our individual progress updates, we finished a 3rd iteration of the goggles and tested writing a single word to the display. However, we could only see 1 word, and the word was warped on its edges. In addition, you need to move the position of your eyes in the goggles to see the word instead of simply wearing the goggles and seeing the word. Luckily, there are several changes we’re making that should address these issues. However, it’s concerning because if we can’t see enough text through the display, then it won’t be possible to fit translations on the screen. To mitigate this issue, we’re considering other fixes beyond design changes such as a better biconvex lens. In the worst case, we’d abandon the transparency effect and move the entire display in line with the user’s line of sight to guarantee that text fits in the display.

No changes were made to the design of the system besides the previously mentioned refinements of the CAD to improve the optical system.

There aren’t any changes to our schedule.

 

Posted on

Aidan’s Status Report for 3/28

This week, I finished making changes for the 3rd iteration of our goggles. Pat and I printed and assembled it, and we tested writing a single word to the goggles’s display. After that 3rd iteration, I made more changes to the goggles’s design (especially the goggles’s optical system), and we are expecting improvements to the display quality with the upcoming 4th iteration.

Our progress is on schedule.

Next week, we’ll have the 4th or possibly 5th iterations completed, and we’re hoping that the optical system reaches the quality that we specified in our requirements (i.e. the ability to write several words at a time). I’m also working on a 1st version of the iPhone app that pairs with the Dawggles. The iPhone app will have a working first version by the end of the week and hopefully for this week’s demos too.

Posted on

Patrick’s Status Report for 3/28

This week I worked on assembling and testing the Dawggles. We were able to run a script to display basic text and change the contrast to so that it is comfortably overlayed. One thing we noticed was the text was getting pretty warped at the edges, so we are going to work to change the mechanical design by moving the OLED closer to the lens and the lens closer to the beamsplitter.

Along with this, I also did basic testing on the server. I was able to  start a TCP connection and send and request text from the server.

Next week, I hope to test some of the other software on the Pi, including the button callback functions and camera client class. Overall, we are still doing well with our schedule, but we do need to make some changes to the CAD to perfect the display alignment.

Posted on

David’s Status Report for 3/21

This week, I finalized the last couple parts we needed to add on to the goggles. We realized we needed a piece of foam on the front part of the frame for comfort as well as straps to keep the goggles in place on the user’s head. Moreover, I began exploring the details of the software we will need by investigating the simple functionality of the raspberry pi, camera, and monitor.

We are on schedule.

Next week, I will assist in the next print of the goggles and assembling the components to have a working prototype, and continue testing software for simple functionality such as comfortably displaying text for the user.

Posted on

Team Status Report for 3/21

The most significant risks to the project are software based. Specifically, we’re worried about whether or not we’ll be able to achieve our desired 2 second latency from user input to result. This week, we’ll try to achieve the latency requirement through lots of work on software. Luckily, if it’s not achievable, we believe that a similar low latency will be possible such as 3 or 4 seconds.

We didn’t make any changes to the system. Instead, we further specified it by including straps and foam for the user’s comfort.

There aren’t any updates to the schedule.

Posted on

Aidan’s Status Report for 3/21

This week, I started another 3D print after finding some changes to make with the initial 3D print. I also did a test of the optical system of the Dawggles and correctly saw the expected results of the display’s output in transparent space in the user’s field of view. Finally, I placed orders for what we expect to be the final parts of the project, consisting of a spare beam splitter, another Raspberry Pi, and straps and foam for user comfort.

Our progress is on schedule.

Next week, we plan to assemble everything in the Dawggles with its 3D print. We’ll probably need to make some changes when the goggle strap arrives so that it fits with the print. We’ll also complete the software pipeline of camera on the goggles to iPhone and then back to goggles.

Posted on

Patrick’s Status Report for 3/21

This week I refined and added to the software framework on the goggles. I created a base implementation of the server and display classes and added all four classes (server, display, camera, and button) to the shared class. I also reorganized the translation and gps functions as two separate application files, in a shared apps folder.

This new framework allows us to start up the goggles and easily switch between applications–by triple tapping the button on the goggles. The app manager handles switching data when this action is selected by swapping the proper data-handling, button-callback, and display functions for the application being switched to. The user will also be able to switch applications on their phone, which the server will notice by receiving a different application name than the current application in the request.

Overall, our progress is slightly behind. We had a small hiccup with some of the hardware, but I feel good that we will be able to start testing software next week.

Posted on

David’s Status Report for 3/14

This week, I assisted in finishing the CAD and 3D printing our initial prototype. There were some final touches that were necessary to discuss, regarding mounting the pieces, before we deployed our first run. Additionally, given the ethics assignment was due this week, I spent a good amount of time on that.

With our first print of our goggles done, we are on schedule.

Next week, I will continue to refine the goggles. After the print, we realized that the goggles could be more comfortable and have more space for certain pieces such as the beam splitter, for comfort reasons as well.

Posted on

Team Status Report for 3/14

The most significant risks to our project are shifting from mechanical risks to software risks, as we’ve now addressed many of the mechanical aspects of the project. For example, one of our largest risks was addressed this week when our beam splitter from AliExpress arrived in perfect condition. It functions exactly as expected and, as discussed earlier, is superior to anything we could find from other vendors. Furthermore, with our first 3D print completed, we can now do a complete test of the optical system to make sure everything functions as expected. By then, we’ll expect our mechanical work to only revolve around improvements to user comfort. Our risks will move from mechanical to software risks because the Dawggles will be mechanically complete. Our software risks are significantly less severe than hardware risks, but our current highest-priority software risk is our ability to reach the 2-second latency requirement that we’ve outlined for a user who presses the translation button on their Dawggles. As previously mentioned, we’ve mitigated this risk by designing a system that combines both Bluetooth and WiFi for user-friendliness and high-speed data transfers. Now, we’ll implement the design to ensure that it truly mitigates the risk of high latency.

A few small changes were made to the design of the system to improve user comfort while wearing the Dawggles. Specifically, we’ll be ordering foam padding to fit around the outside edge of the Dawggles so that the user’s face presses against foam rather than rigid printed PLA. We’ll also be ordering a strap that fits around the user’s face to hold the Dawggles in place. We’ll experiment with comfortability and decide whether to use a ski-goggles style strap that fits around only the back of the head or a VR-style strap that fits around both the back and the top of the head.

There aren’t any changes to the schedule.