After an unproductive couple weeks surrounding Thanksgiving Break, it was crunch time for our project. We had a meeting specifically to talk about how we were going to use our time most effectively and to set deadlines for the rest of the project. The next meetings went as follows.
Meeting 1, Saturday: Test the existing system and plan modifications. Divvy up responsibilities for the next meeting.
Meeting 2, Monday: Have the new design CAD before meeting. Do a design review for the CAD to make sure everything fits together.
Meeting 3, Tuesday: Have the parts fabricated. Put together and test the new system. (This did not get done due to printer failures and early machine shop closures. Instead we did a code update so the entire team could get up to speed on what is going on with the software side.)
Meeting 4, Wednesday: Parts were actually fabricated by this date. We put together and tested the new parts, as well as worked on live beat detection.
Overall, we had a very productive last week. Perhaps if we had set deadlines and goals for meetings sooner, we might have been more effective in previous sprints. As it is, the team worked hard to come together for a functional prototype. Stay tuned for updates on our final product!
The team went through several iterations to find a suitable wheel. First we tried a fully 3D-printed version, with PLA as a frame and TPU for friction. The TPU did not provide enough friction to a piece of paper, so we briefly used rubber bands to provide it. That worked reasonably well, but the team decided it was too large; it might get in the way of the person trying to read the music. Additionally, the rubber bands looked unprofessional. We downsized the diameter of the wheel and attempted to remedy the friction problem by adding "teeth" to the TPU wheel. Unfortunately, this still did not provide enough friction. For the latest iteration, we bought rubber wheels and integrated them with our old frame. This wheel does a much better job of grabbing onto the paper.
Author: Athmika Senthilkumar
For sprint 3, we decided to focus on getting the mechanical side of the project finished. One of the main risks we identified is multiple pages turning at a time. To address this risk, we enclosed the plastic wheels with rubber and experimented with placing the motors at different distances from the center of the binder. After the testing, we established that placing the motors a distance of around 7.5in away from the center of the binder ensures that the page turns one by one (If the motors are too far away from the center then multiple pages turn at a time, and if they are too close then the pages don't turn fast enough).
Another problem we encountered in the previous sprint was with the structure of the box. The 3D printed parts were designed to stand in place by sliding into the box. The 3D printed parts were pushing out on the sides of the box and this compromised the structural integrity. To address this issue, we decided to add slits to sides of the box as shown in the picture below.
We also removed the ledge that was intended to hold the binder in place. The ledge was getting in the way of the servo swiper and the binder stayed in place without the ledge.
Another refinement of the mechanical setup was with the 3D printed parts inside the box. We changed the shape of the motor holders to allow them to slide into slits. We also added extra supports for the spring to allow for adjustable spring holding.
On the electrical side, we transferred all the wiring from the breadboard to the protoboard. We also added the physical pedal to our setup.
Author: Maggie Pak
In terms of the software we have figured out the beat detection software and have integrated it with the Arduino button. We've tested the software out on music played on our laptops and the system responds well to the calibration. We intend to conduct subsequent testing with live music with real musicians.
The second sprint review went well. We stated our new MVP, reevaluated our risks, and recapped our learning goals. We had our stepper motor and pedal working with our software, but we didn’t have time to calibrate the swiper. We were also able to film a demo of our system working for our presentation, which was one of the changes we wanted to make from our first sprint. From our feedback, the first few things that we’ll tackle will be the addition of the mechanical arm, improving our wheels, and putting our circuit on protoboard.
Author: Emily Lepert
We presented on Friday October 23 about our first sprint. We recapped our MVP, personal learning goals, our current progress, challenges we face/expect to face, and our goals for the next sprint. From the review, we decided to pivot away from blink detection to music beat detection. The feedback from the professors were overall positive about our progress and decision making. They noted that while we all identified the speed and efficacy of the page turning as the biggest risk, our next spring goals did not reflect that and suggested we align those goals with the biggest risk to tackle those head on.
Click here to check out our presentation!
Author: Emily Lepert
Hardware and mechanically this week was spent evaluating our motors. We talked with Stan about the pros and cons of different stepper motors and DC motors. The stepper motors we were using for our prototype turn pages well, but slowly. As such, we decided to switch our MVP goal of flipping through a stack of papers to flipping through binder paper. We also decided to create a reverse function. In order to actuate this in the binder format, we decided to add two servo motors to our model. These motors would rotate the wheels and steppers out of the plane, which will allow the flipped pages to rest flat. New CAD models for the wheels, with better grip, were made and printed. We were advised during our first sprint to dissect a used printer to investigate how the mechanisms were built and what kind of wheels were used. From this, we also decided to add some springs into our prototype. These extension springs would ensure that the wheels are always pressed firmly against the paper.
On the software side, we started the week by evaluating our blink detection software. After some discussion about the poor reliability of the detection we decided to pivot to music recognition. We were initially going to do recognition of the identity of different notes so that the controller would simply listen for a set of notes and turn the page upon hearing them. After more research and testing we decided that the sound processing knowledge required to do so is greater than what we currently know and we decided to investigate beat detection. We’re currently working on writing Python code using the Aubio library to count how many beats have occurred and then the controller turns the page after the right amount of beats. This is advantageous because we’re not restricted to a specific tempo which makes our program more flexible. The method by which we plan to remember and calibrate the turning trigger was also implemented using an Arduino. We plan on integrating the Python and Arduino code this week.
Author: Kristen Behrakis
After our last group meeting, we had come to a bit of a deadlock. We couldn’t agree on whether we wanted to work on a page-turner or a safety jacket for biking. Last night, however, we finally reached our decision. We will be creating a page-turner for musicians. Personally, I was originally leaning toward the safety jacket. The element that made me change my mind was identifying a clear user for our page-turner. When playing an instrument, both hands are usually occupied. This makes turning sheet music pages difficult and stressful. Additionally, sheet music is generally of a standard size and comes in specific forms (i.e. a stack of papers, a binder, or a paperback book). If this were a generic page turner, there would be many more variables, specifically. the size of books. We also believe that having a specific user in mind will help our design decisions as we move forward.
Another major aspect of this project is deciding when the pages will actually turn. One idea was to scan the sheet music, listen to the musician play the notes, and turn the page as the musician reaches the end of a page. This idea seems promising, but it may not be appropriate in an orchestra setting (where multiple instruments are all playing at once). Issues could also arise if the musician plays the wrong note or needs to repeat a section of music. For this reason, we decided the user should actively control when the pages turn. The simplest way to do this would be to construct a foot pedal that the musician could hit each time they want a page to turn. Despite being quite practical, this option lacked the opportunity to explore much software. We plan on implementing a pedal/button as a first-cut model and then moving on to more software-involved options. In particular, we plan on exploring eye tracking technology. By looking or blinking at a specified area on our device, the musician will be able to indicate when the page should turn.
Click to check out a summary of our project: Project Proposal
Author: Kristen Behrakis
Today marks the first day of our final Principles of Engineering project. Last night, I found that my team consists of myself (Kristen), Athmika, Emily, Hannah, and Maggie. We have three Software Engineers, one Mechanical Engineer, and one Physicist. This seems like quite a solid spread of skill-sets, and considering that I almost chose Electrical Engineering as my major, I feel confident that we will be able to accomplish electrical aspects of our project as well.
To kick off our meeting today, we had an ideation session. This consisted of passing out a stack of sticky notes to everyone and writing down any project ideas we were interested in for 7 minutes. After the 7 minute time block was up, we explained each of our ideas and grouped similar ones. Then came the fun part – narrowing down the ideas. During the meeting, a common phrase that came up was “there’s a lot of mechanical engineering in that idea but not much software” or vice-versa. The interesting thing about this class in particular is that our final product needs to integrate different skills. Being someone who is interested in software, I tend to be most excited about software-focused ideas. This seemed to happen to most/all of us in the group, which made our decision-making process a bit challenging. We needed to find a project idea that could encapsulate all of our skills and interests.
Another interesting dynamic is that we had some different priorities for our final product. Personally, I wanted to create something that was user-focused and could be sold/marketed. Others in my group wanted to explore certain mechanisms that they weren’t familiar with. Others just wanted to have fun and make something cool.
By the end of our meeting, we narrowed down our choices to two ideas: a page-turner or a wearable jacket with bike lights. Our conversation had reached a standstill as half us of wanted the page-turner and half wanted the jacket (and one just couldn’t decide). We decided to take the night to sleep on it.