TUSIC
  • Home
  • Process
    • Sprint One
    • Sprint Two
    • Sprint Three
    • Final Sprint
  • Budget
  • Systems
    • Mechanical
    • Electrical
    • Software
  • The Team
  • Blog
  • Home
  • Process
    • Sprint One
    • Sprint Two
    • Sprint Three
    • Final Sprint
  • Budget
  • Systems
    • Mechanical
    • Electrical
    • Software
  • The Team
  • Blog

The Team

Picture

Emily Lepert

Software Engineer
Emily is a sophomore at the Olin College of Engineering studying Computer Science. She worked on the software and integration of the project.
Picture

Magnolia Pak

Physicist
Magnolia is a junior at Wellesley College majoring in Physics.  She worked on electrical aspects of this project.
Picture

Kristen Behrakis

Software Engineer
Kristen ​is a sophomore studying Computer Science at Olin College.  She worked on software, integration, and some of the mechanical systems for this project.
Picture

Hannah Kolano

Mechanical Engineer
Hannah is a sophomore studying Mechanical Engineering at Olin. She mainly worked on the mechanical systems. 
Picture

Athmika Senthilkumar

Software Engineer/Top Master
Athmika is a second year student studying Computer Science. She worked on the software components of the project.

Lessons Learned

CAD twice, cut once
Over the course of the project, we often had several team members creating CAD models simultaneously. The parts to be laser cut and the parts to be 3D printed were sometimes in different assemblies or not always updated in the right spots, and we only realized that they didn't fit together after they were printed. This caused us to spend too much time reprinting, sanding, and otherwise trying to fix these errors. This could have been fixed with a 10-minute CAD review before fabrication. In the last sprint, we purposefully put a CAD review in the schedule so that we were absolutely sure our pieces would fit before fabrication. As we hoped, we had far fewer issues when we put the final parts together because of it. 

Set deadlines for pivots
There were several points in our project that we were thinking of potentially moving away from a particular feature or process. On one hand, if you pursue something hard enough, you might get it working really well. On the other hand, if it is too difficult, out of scope, or laboriously time-consuming, you don't want to spend precious time struggling down a dead-end path. Because of this, our team often set deadlines for when we would pivot away from an idea. The most prominent example was our switch from eye detection to beat detection. When the software team was having trouble with the finicky eye detection code, we weren't sure when to give up and try something else. To solve this conundrum, we set a deadline. If they couldn't find a solution by that day, we should pivot and figure something else out. This worked remarkably well and often started us on a better path. 

Test, test, test!
It's easy in CAD to arbitrarily place a sketch somewhere. It then might get fabricated with this arbitrary location. There are two connected solutions to this: modularity and testing. Modularity is preferable, because then the part can be tested in different positions to determine where it should be permanently placed. For example, when we were attempting to determine how much the spring should be stretched when it is resting against the paper, we made the placement modular by placing several holes on the part. Then we could test at each position and find out what the best length was. This information was then used to have one hole in the final design with the optimal position.  We tested without modular parts to determine how far from the center the wheel should be located to best roll up the paper by holding the motor without a mount against the paper at different locations. 
Create a free web site with Weebly