Category: Team Status Reports

At this point, our project is pretty demoable and there aren’t any significant risks unless we break something. We are trying to prioritize safety for the demo by limiting speed, which should also mitigate risks of anything breaking. There haven’t been any changes to any designs, and we are still on track for demo day.

Tests:

• Motor RPM: We tested a safe motor speed by incrementally increasing our target duty cycle and carefully observing any changes. At around maybe 24% duty cycle we observed some slight slippage, which might be attributed to PLA warping. So, we will try to reprint in PETG before demo day. If that isn’t achievable we can simply limit speed to 20% duty cycle, which seems to work fine for extended periods.
• LED Display Time: This metric was measured because this is the hard physical limit for how fast we can update the display. We measured a mean of 184 microseconds and a maximum of 479 microseconds. This informed our decision to increase the angular resolution from 120 to 240 slices per revolution.
• End to End Latency: We decided the best way to measure the end to end latency was taking a video and seeing when gestures would be processed. In our video we measured around 500 ms of latency, which is a bit higher than we expected. This finding motivated us to do a bit more instrumentation to identify if there are any places we can optimize the computer vision pipeline.
• UDP gaps: We measured the difference between successive instances of receiving network information. We got around 280 ms, which informs us a lot about where our latency is likely coming from. Unfortunately, this number seems difficult to change because our setup needs to stay wireless and our hardware can’t really be changed at this stage.

We did not face any significant challenges this week. We successfully pulled off the interim demo and are now preparing for our final demo.

No significant schedule or design changes to our project at this time. Our LED panels have finally arrived and we’re now ironing out how to program the displays.

For full system validation, we’ve been testing while integrating to make sure everything would work well. For example, for power draw we have measured components individually and ensured that they pull around the amount we estimate. Once we have a more final product, we will also take the time to measure framerate and latency to ensure they are within reasonable bounds. We will also make some qualitative observations to see which aspects we will focus on improving.

Successfully integrated everything (except the display) this week.

One big issue we ran into this week was losing both of our displays. We realized that one of our displays was bricked, and shortly after, we proceeded to short our only remaining working display, so we’re currently working blind. We got the Pi working, so we can write the code, but we can’t verify if anything we’re writing is correct. We’ve since ordered express shipping on four new LED panels (we learned our lesson on redundancy), so that we can begin testing asap.

Other than the LED Display roadblock, we haven’t faced any additional significant challenges. One small component we may be redesigning in the near future is the chassis of the box. The individual components are currently a bit cramped inside our box, so we might redesign the box with a bit more room, as well as laser-cut a precision hole for the spinning metal rod to go through so it’s no longer rubbing against the plywood box.

As an update for our interim demo, here are some of our relevant figures and our updated schedule, which haven’t changed much since we began: Interim Demo Slides.

With all our components finally delivered, we spent the week transitioning from planning to active integration. Steven focused on the electrical subsystem, successfully verifying the power path from the rocker switch and PSU through to the motor control. Having the physical parts in hand has been important for Kendric, as he can now finalize the mechanical layout with exact dimensions, while Andrew has been balancing software development on the Jetson and Pi with the physical design. Our most significant risk currently involves several mechanical parts that don’t fit perfectly within our original chassis design. We are managing this by 3D printing custom adapters and using high-strength adhesives. If these adjustments don’t address our issues, we plan to find alternative mounting hardware locally to keep us on track.

There have been no changes to our system design, requirements, or block diagrams this week. While we are officially back on schedule, the “mid-semester” reality is setting in, and the final deadline feels much closer than it did before Spring Break. Although we haven’t needed to alter our technical specs, there is definitely a shared sense of urgency within the team to maintain this momentum. Now that the hardware is stable and being assembled, we’re in a good position to move into the final stages of integration without further delays.

This week, our overall status remains largely the same as last week. We have continued to experience shipping delays that are limiting our ability to move forward with subsystem testing. At this point, our primary bottleneck is still the arrival of a few key components required for full electrical integration. In the meantime, we have shifted our focus toward documentation and have been primarily working on completing and refining our formal design report.

Because we are still waiting on parts, we have not made major progress in hardware validation. However, we are using this time productively to ensure our documentation is thorough, technically consistent, and aligned with our implementation plans. This will allow us to transition smoothly back into hands-on testing once all components arrive.

We did not make any major changes to our system architecture or incur new costs this week. We received mostly positive feedback from our design review presentation, and as a result, we have continued forward with a design report that closely mirrors our presented architecture and justification. At this time, we do not anticipate significant structural changes to the system and will proceed with implementation as planned once testing can begin.

For product solution answers, A was written by Andrew, B was written by Steven, and C was written by Kendric.

As we anticipated last week, we are currently experiencing shipping and logistical delays that are bottlenecking our testing phase. Fortunately, because we ordered our most important components early and built buffer time into our schedule, we have more than enough time to manage these delays without falling behind our final deadlines. Since we are stuck waiting for a few key items, our biggest risk remains the possibility of those delayed parts arriving broken or incorrect. To mitigate this risk as much as possible, we are actively bench-testing all the parts we currently have on hand. By making sure our existing components work properly right now, we can prevent a pile-up of technical issues later when the rest of the system finally comes together.

We did not make any major changes to our system design or incur any new costs this week. We just finished presenting our formal design review and are currently waiting to receive official feedback. We plan to keep the system architecture as it is until we hear back, and we will likely make any necessary design changes next week once we can review that feedback and incorporate it into our project plan.

The biggest risks to our project right now are shipping delays or receiving parts that are dead on arrival. Since the semester is short, a delay of two or three weeks to get a replacement part could make us miss our deadlines. To manage this, we ordered all our important components early rather than waiting. About half of our parts have already arrived, and we are testing them immediately to make sure they work while we can still return them. Our budget is also very tight, so if we accidentally break an expensive part and cannot afford a replacement, our backup plan is to build a simpler frame using scrap materials instead of buying new materials for a polished enclosure.

We made a few changes to our system design this week to improve reliability and safety. First, we updated our electrical plan to use a specific, high-quality power supply instead of a generic one. This costs about $15 more, but it is necessary to stop sudden power spikes from shutting down our main computer when the lights turn on. Second, we updated our system diagram to verify exactly where the physical frame sits in relation to our electronics. This change didn’t cost anything, but it was necessary to ensure the wooden frame is strong enough to support the entire hologram system.

A was written by Steven Guo, B was written by Kendric Terry and C was written by Andrew Yu.

We have not made any significant decisions that could cause large risks yet. Our main risk is that the project will either work or not work. There is no partial success if the volumetric display breaks. We are mitigating this by being very detailed in our design decisions and talking them through. For example, we spent some time reviewing the parts list.

One design change we made was moving from an ESP32 for the display controller to a Raspberry Pi. This is due to the fact that the ESP32 only has enough GPIO pins to control one display. One slight downside is that without RTOS, it is possible our display driving logic could have slight jitter. However, looking at previous volumetric displays, using Raspberry Pi’s did not cause any visible image tearing.