Category: Team Status Reports

Right now, our risk is meeting our user requirement of allowing this device to work on any table. We are tuning the configuration to the table and lighting set up of the conference room we are using, so it is unknown how well our system will run on other tables. Right now, we are more focused on getting our initial configuration to work, and then we will focus more on generalizing to other tables. If we do not have enough time to do this, we will just reduce the scope of the system, possibly still working on different tables but maybe tables more similar to the one in the conference room. We will also have to tune to the room and table where we are doing the final showcase, which would be the next step.

No changes made to system.

Implementing the software on the AGX was pushed back due to hardware constraints. No other schedule changes.

Our biggest risk this week is integrating all of our code into the AGX Xavier. We don’t anticipate this to be a terribly big risk , but it is something we have yet to do. It is a high priority this week and we hope to finish integrating all of the current code onto that. This will also give us the opportunity to test the camera with the AGX which we anticipate will give us a significantly higher performance. We’ve already begun working on this process from Friday. We have not had any other changes to our timeline and we anticipate being on track.

Validation:

• User Acceptance Study: Our primary method of validation will be via the user acceptance study because it will allow us to assess how the design flow suits the user experiences. This study will encompass factors such as ease of UI, taste of product, training time, intuitiveness, etc. This will ensure that we can meet our basic use case requirements.
• Total Error Rates: Total error rates on the number of hangups, crashes, and general errors that occur throughout the user’s experience are key to understanding how we can process errors better. Part of this is also accounting for cases where error is detected and where it’s not. This will ensure that we can meet our engineering design requirements.
• Multi-Recipe Functionality: Our system should be compatible with multiple recipes in our library. This will prevent the danger of hard coding to a specific recipe which is not at all what we want. This will ensure we can meet our engineering design requirements and our general use case requirements.
• Latency: Our latency validation is important to test at the higher level with all of the subsystems working together. Since several of our subsystems are computationally expensive, running them in parallel should not result in a notable latency while the user is interacting with the experience. This is key to our engineering design requirements but definitely impacts our use case requirements.
• Expected vs. Recorded time: This validation is with regards to the expected time a recipe is marked to take and how much time it actually takes with the user’s ability to interact with the device. This is a major use case requirement because it conveys the actual effectiveness of our product.

There are two significant risks – one is the projector, which has been an ongoing risk. The risk of knocking down or dropping the projector is still a concern because we have not finished this portion of the project. However, we have figured a way to somewhat mitigate this risk, which will be discussed in the system design changes paragraph. Another risk is the object reidentification. It might not work as well once implemented due to lighting conditions. Right now, the implementation uses the UI wireframe, which has less uncertainties as in a real kitchen. We will have to do testing to see how much of a problem this will be – if it is one. To manage this, we will experiment with different lighting conditions.

One change that we have made is simplifying the projector mount. Instead of having the user set different angles during calibration, we will instead fit the projection to any angle – within reason (the projector still must be pointed at the table). We are doing this by computing a homography between a sample image taken by the camera and the image on the screen. Now, we do not need to make the projector mount rotate up and down. The change will make the mount cost less because we do not need a rotation mechanism.

No changes to schedule. We are on track.

The main risk to our project is the projector mount. If not designed properly with the correct material, the projector could fall and break which would compromise the entire system – especially given our budget. In order to prevent this, we have to doubly engineer our system to ensure the safety of the projector. Additionally, we have to design hard stops to indicate our presets in order to make the user experience more intuitive.

Slight changes were made to the mounting after receiving a larger tripod.

No changes to schedule. We are on track to integration.

The most significant risk is still mounting the projector. We still plan on placing the projector on a tripod angled downwards on the table. We are currently looking for stable tripods and secure attachment options to manage this risk. Potential options include making a CAD model and 3D printing attachments like we are for the camera case or buying off the shelf options. We are still testing the homography and seeing if the warped image is high quality enough to completely use this method. Our contingency plan is still placing the projector at a 90 degree angle if this does not work. There have not been any major design changes since last week. There are no changes to the schedule. We will be planning system integration this week and will implement it after spring break.

Status Report

The most significant risk for this week is with the change in mounting for the projector. Rather than having the projector be oriented to face down from above the cooking surface, it will be angled down from a position off to the side. We have a contingency plan in place to fall back on an overhead rig should the warping of the images fail. Both can be worked on concurrently and with minimal extra effort so there is no change to the timeline. This change was decided upon to avoid the need of flipping a heavy projector by 90 deg. This will additionally allow for easier setup and reduce the necessity for expensive mounting hardware. Another design change is that we will be using MediaPipe for gesture recognition rather than OpenPose in order to reduce the amount of computation required.

Product Solution Meeting Needs

Caroline Crooks: TableCast will encourage people to cook. People may be deterred from cooking for several reasons, such as an inability to read small text on a phone to read a recipe or just the mental hurdle of starting to learn how to cook. The projected content makes cooking more accessible because projected instructional content and tools will be across on the countertop in an intuitive and easy to read way. Our user interface is designed for a smooth and accessible cooking experience. Encouraged to cook using our product, people can live healthier lifestyles. Safety is an integral part of our design. Many of our components will be placed high above the table because we are projecting our content. We are designing a stable, secure system to ensure that components will fall or have the potential to be knocked down. We plan to carefully test our mounting mechanisms and install our components carefully. We also recognize the cooking itself can be a hazardous activity. Our instructions and video content will be clear and caution users to be vigilant during several steps of the recipe. 

Sumayya Syeda: TableCast will allow users to easily access and create recipes across cultures. Many struggle to find the correct ingredients and follow the unique steps required to create dishes from different parts of the world. With a product like TableCast, it is much easier to follow intricate recipes with the help of images and guiding widgets projected onto the kitchen counter in addition to voice commands. As a result, there is strong potential for better cultural appreciation. Furthermore, TableCast can increase one’s confidence to cook in the kitchen, especially when one requires an organized process to cook. Users will no longer have to switch between their device and the dish while having to constantly be conscious of multiple tasks occuring at once. TableCast is a clean and streamlined solution to making cooking more accessible across the world. 

Tahaseen Shaik: TableCast is designed to be a lower cost alternative to the current market solution of table displays. Rather than replacing an expensive kitchen countertop, our solution allows users to use their existing resources. Assembling TableCast is fairly straightforward as well. All it takes is to set up the tripod, make the appropriate connections and begin use. Individual component-wise, we are using cheap components to assemble and display the user interface. We also leverage the user’s laptop in order to simplify our hardware. For distribution, we will be able to condense all the components down into a relatively lightweight package, which would greatly reduce further economic costs. Consumption-wise, TableCast is an innovative product that is not readily available on the market and would fulfill an open market need. Users have historically turned to new technologies to supplement their learning process in the kitchen. Overall, we have taken great care to ensure our product is not unnecessarily expensive and left room for upgrades.

A significant risk we are currently considering is the mount for our hardware components. We need a large projector with strong light projection (similar to a projector used in classrooms) for our application similar to . The projector combined with the Xavier AGX will heavy components in our product that need to be secured to a ceiling. As a result, we will be putting extra efforts into designing and building a bracket and mount to secure the projector, AGX and camera module. We plan to work with faculty and peers to get advice on design specifications and will be using CAD software to design the bracket and mount. If the overall device cannot be mounted to the ceiling, we will create another structure that can hold the weight of the device. This may include a mount to a different wall.

There have been no changes to the existing design, and no update to schedule.