We've made some final edits to our design. Check out the "Final Iteration" tab to learn more about what we changed in our final week of the project.

We've been working a lot on the final mechanical design. As we've learned, prototyping takes time. Feedback from our design reviews said we should use a spring tensioning system to hold the small wheel to the bike. We've designed a system, and have been prototyping the pieces. We hope to laser cut pieces (the box, the base plate, the pivot bars) in the next week. This, of course, requires us to quickly procure material, which may be difficult. We are aware that, going into our last final week of PoE, we still have a lot to do.

We wanted to have our physical design finalized before we headed off for break, but things have not gone quite as smoothly. We're continue to design and prototype our physical design, and hope to have the design finalized and prototyped by the end of next week, so that we can have one week to polish our build. We switched to a photon microcontroller, and have successfully taken it out of and back into WiFi. The user interface has more options now and is generally more aesthetically pleasing. We're happy with how far we've gotten, although there's a lot to do in the next two weeks.

Lucy has been working diligently on the Chrome extension and options page of the web app. The user can no longer cheat the system by removing either the blocked sites and goal distance before they have reached their goal distance. This has been an issue presented in several of the design reviews -- what if the user somehow cheats the application, spins the wheel in some other way (such as with their hand), or removes the Chrome extension entirely. Lucy's additions prevent the first, the second would be more tiring than riding the bike, and the third is a risk we accept. Lucy also added an option to choose the day or week for the user's goal distance and to choose either miles or kilometers. She also added a wheel diameter section, so that the user can customize the experience for the size of their bike (which also gets them more accurate data). She made more improvements to the UI by switching to using some bootstrap components, and Arjun joined in on cleaning the UI.

Lucy and Arjun worked on other parts of the software as well. He worked to combat an issue we were having when we first entered a site to be blocked; the user would still be able to access that site one more time after adding it to the list in the extension. This issue, fortunately, has since been fixed. 

Dennis has been building a progress visualization tool into the web app. He added a simple chart to allow users to look through the history of their bike sessions on our web app. One thing he came to appreciate while doing this is that front end development is hard; getting a bar chart to display the way he needed it to took him way more time than he's willing to admit, and it still isn't fully functional on mobile. For charting he used the Chart JS library with some modifications. He also built a backend route to serve up chart data in a parsed, ready to graph format.

Dennis was also the main leader in switching from the Raspberry Pi-Arduino setup to the Photon microcontroller. The Photon is smaller, cheaper, and simpler than our Arduino and Raspberry Pi setup, but it has its own set of problems that we've been tackling, often having to do with a lack of community resources since the Photon is so new. However, this is very reasonable for a microcontroller that costs $20 and has WiFi and cloud capabilities. We've been pretty impressed by it so far.

Sending direct HTTP requests on the Photon is surprisingly difficult. There is a web request library available for the Photon, but it seems to work sporadically, failing to send POST requests to our web application routes when it comes in and out of wifi or wakes up from sleep mode. To work around this, we used Particle's Webhooks service, which makes POST requests for us when we trigger certain Particle events using Particle.publish(). Either way we're posting information to the internet when we make the calls, but the Particle.publish() function never fails while the community built request library does.
​
One issue we ran into was getting the Photon to behave the way we wanted to when it lost its WiFi connection. This was critical because we can't expect bikers to remain in WiFi range all the time while biking. The Photon has specific behavior when it goes in and out of WiFi; specifically, it runs blocking code that attempts to reconnect to WiFi and pauses execution of user written code. This is problematic because we need to continue running our sensor reading code while the bike is not in a zone with WiFi. We worked around this with interrupt handlers, which allowed for us to interrupt the blocking WiFi reconnection code. Our interrupt handler is triggered whenever the encoder wheel moves past a certain position, triggering a reed switch and causing a pin on the Photon to go high. This seemed to fix our issues with WiFi connectivity without us having to resort to manual management of the WiFi connection ourselves.

Jen and Maggie have been working on the mechanical design. They've been 3D printing mini wheels to ride on top of the bike wheel, but have been having tolerancing issues. They have gone through several iterations of similar wheel and box designs. The size of the box has been drastically reduced because we've switched to the photon microcontroller. They are currently designing a spring tensioning system to hold the small wheel flush to the big wheel. They are also working on waterproofing the system, although they have made less progress than they would have liked on this topic.

We're really pushing to get our final physical design.Thanksgiving is of course coming up, so the pressure is on. The Chrome extension is coming along and we are focusing on creating a web app, we're using the reed switch instead of the Hall effect sensor, and we've decided to keep using the Raspberry Pi and Arduino.

This week, Lucy worked on the options page and Dennis worked on the dashboard. The plan is that the Chrome extension will redirect to the dashboard page and the user will be able to set up their options (which sites they want to block, how far they want to bike etc.) there. Switching to using a web app instead of handling most of the data in the Chrome extensions allows us to create a more complex interface and more easily handle multiple users. Now the Chrome extension is mainly used to block sites via redirecting, something we have already figured out how to do! Arjun has been working on building API routes -- this allows us to store all of the users data on our web app instead of in the extension, which will now query the web app. He has also helped with the web app and with wheel design.

Maggie and Jen worked on the mechanical setup. After all, the goal for this week is to have a finalized mechanical design. They have gone through several mock prototypes and have discovered many things (the cords on the Pi are long and unwieldy, the battery needs two cords and one of these needs to be near the end, the caster wheel they bought is too heavy and too big to fit underneath the bike rack), and they are now 3D printing parts. They also tried out the new reed switch, and discovered that the reed switch must be one centimeter away from the magnet at most. The current setup, they believe, will consist of two thin wheels separated by the magnet, using a caster that they make. The caster and wheels will probably be laser cut.

We want to finish designing and prototyping our mechanical attachment by Thanksgiving break. That way, we'll be able to spend the remaining time after break finalizing and polishing our system. To do this, we've had to clarify some things. What exactly does it mean for us to have a "nice," "polished" final project? We want our mechanical attachment...

• to be just one piece
• to easily attach to a bike
• to fit onto (most) standard-sized bikes
• to not interfere with other rack attachment (such as panniers)
• to be weatherproof (hot, cold, wet)
• to be easy to charge and turn on/off
• to stay charged for a reasonable amount of time
• to not let the important things (such as sensors and microcontroller(s)) bump around

With all that in mind, we're designing a box to go on the underside of our rack. This would hold our microcontroller(s) and sensors. We also bought a caster wheel so that Dennis can have his longboard wheel back. The new wheel is the same diameter as the old wheel but slightly thinner.

We've also reevaluated our sensing mechanism. We originally were using an IR sensor (like we did in lab 3), but we had issues with that. Our optical sensor only worked in the bright light of the PoE room -- in different lighting, our sensor thresholds were no longer relevant. We will be using magnetic sensing from now on. We researched different magnetic sensing mechanisms and decided we would use either a reed switch or a Hall effect sensor. Because this is not our area of expertise, we called Digi-Key and spoke with a technician. He recommended either the Standex-Meder Electronics MK06-4-B reed switch or the Honeywell Sensing and Control SS49E Hall effect sensor. We decided to order both, but we think we'll be using the reed switch. We also bought two Standex-Meder Electronics ALNICO500 4X19MM magnets, which were recommended for use with the reed switch. We spent almost an hour debating different sensors.

Dennis conducted a battery life test with the Raspberry Pi and Arduino setup. We can power our current microcontroller situation for 8 hours. This is a reasonable amount of time to be charged, although we still are looking into using a photon microcontroller. One drawback of the photon microcontroller, however, is that it has very limited storage capabilities. This is something we will look into in the next week.

Finally, we've made considerable progress with increasing our Chrome extension's functionality. We've decided to post data to the webapp that we could use in the redirect to make cool data visualizations. 

​We're working on integrating our system. We have a prototype that attaches to a bike, and the Chrome extension is being developed. Our prototype can read rotations and send those rotations to the web app, which in turn sends them to the Raspberry Pi. We're excited about the progress we're making, but we're also considering several modifications.

Our chrome extension now blocks Netflix by redirecting people to our team website (where you are now!) depending on whether the last recorded distance biked on the webapp is greater or less than your minimum distance goal.

We have a prototype that affixes to Lucy's bike. We bought a bike rack last week and attached it to her rear wheel. We used an extra longboard truck and wheel that Dennis had and attached the truck to a piece of scrap wood. We covered the end of the wheel in aluminum foil and then drew a black stripe along one segment. This way, we could use the sensor to detect the black stripe every time it came by. This small wheel rides snugly against the bike wheel. We will be able to calculate the distance traveled by the large wheel (and therefore the rider!) by counting the number of times the sensor detects the black stripe. We placed the wood, truck, wheel, and breadboard configuration upside down on the bike rack so the small wheel could fit against the bike wheel. We have built this physically as well as in SolidWorks (with help from GrabCAD).

We are still considering using a magnetic rotary encoder rather than an optical system. Maggie ordered three rotary sensors that detect changes in magnetic fields to measure distance traveled from ams AG, an Austrian semiconductor company. The AS5043 rotary sensors could prove challenging to integrate (we would need a specific PCB board in order to use them), but would possibly give us cleaner results (and be unaffected by outside light or dirt accumulation).
​
We also decided against buying a WiFi shield. We figured it would be the same amount (if not more) money, and we also thought we would lose functionality. We are still using the Raspberry Pi to connect to the web app and thus Chrome.

We're starting to buy more supplies -- we are working on a much more concrete prototype for the Design Review on November 6th. We're making progress on the Chrome extension, and are reevaluating some of our earlier assumptions

Lucy has made impressive progress with the Chrome extension. She can take text from the web app and read it into Chrome. She can also block websites, although the Chrome extension button on the toolbar is not fully functional yet.

We had several discussions today in which we reconsidered some previous decisions. For example, while we had been planning on using a shaft encoder to measure distance traveled, we did some calculations that suggested this wouldn't be the greatest plan.  A 27" bike travelling at 10 mph is undergoing approximately 125 revolutions per minute, which translates to 10,602 inches per minute. If we were to use a 2" wheel to house the shaft encoder (this wheel would rest on the bike's wheel), that wheel would need to spin at 1,688 revolutions per minute. While many of the shaft encoders we found were capable at spinning at this speed, many of them had operating lives of, at max, around 200,000 revolutions. This was not enough for our project, so we decided to reevaluate the possibility of creating an optical sensor (one that would count the number of times a line on the wheel passes by, similar to the optical shaft encoder) or a magnetic sensor (one that would count the number of times a magnetic field passes by). We have not yet decided which, if either, option we will choose, although we will be running tests to determine if either method is practical for what we want to test. 

We also reevaluated our decision to purchase a Raspberry Pi. We believe we may be able to accomplish all that we need to with an Arduino WiFi shield. While these from Arduino cost around $80, there are other options not made by Arduino available for a fraction of the cost. We have to decide whether we want to sacrifice the potential increased functionality of the Raspberry Pi for the smaller size of an Arduino with a WiFi shield. 

We purchased a bike rack from Amazon today.  We chose between three racks. In choosing this one, we considered adjustability, cost, and the presence of a spring in the rack. The model we chose was by far the most adjustable, and it also has a spring in the back to potentially hold down our pieces. This was not the cheapest, but it was not the most expensive, either. 

Going forward, we need to work more on the mechanical component of our project. We need to design the method of measuring distance, and we need to create an attachment to the bike with a small skateboard wheel that will spin with the bike wheel. We will continue to work on the Chrome extension and will consider the Arduino/Raspberry Pi debate. Things are coming along well, though. We are focusing more on thinking ideas through rather than acting impulsively, and this is leading to better informed (and potentially better!) decisions.

We're making a lot of progress already. For the past few days, we've been experimenting with our new systems -- with our motor encoder, with Google Chrome, and with, starting today (!), our brand-new Raspberry Pi.

Update: After working more with the encoder, Jen and Dennis realized that a different and more straight-forward proof of concept would be using an IR sensor instead.

To test this, they built a pinwheel out of cardboard and added a strip of electrical tape to act as a marker so that each time the tape passed over the sensor, the counter would increment.

The original pinwheel had a small difference in output between the cardboard value and the electrical tape value, so they lined the cardboard with white paper first and added the tape after for more contrast.

After testing that out, Jen worked on interfacing the Arduino with the Raspberry Pi while Dennis tinkered with the Pi to figure out how to have it auto-run a Python script to post the data on a simple web app host that he set up using Node.

Lucy and Maggie have been exploring the Google Chrome extension developer space. They have made some annoying popups and icons (including one of Nicolas Cage's face). Lucy is working on reading a text file into Chrome.

Arjun now has a Raspberry Pi to work with! He is working on using a button push to transmit information from the Pi to a server.

We set our goals and planned for our first sprint review next Friday. We ordered a Raspberry Pi, got a shaft encoder, and looked at started our website. By next Friday we hope to have a mock prototype of our attachment system, we hope to have our Raspberry Pi and a server communicating, and we hope to have our Chrome extension started.