The following are entries that represent my thoughts while I was at certain points in my project.
October 17th: I've been looking at foreign instruments that could potentially be reproducible easily.
As I posted about before, the erhu looks promising. A quick trip to amazon.com shows that the cost of an erhu is about $250 plus shipping and handling. If I can replicate it for much cheaper that would be a large accomplishment.
One potential problem that I could run into is the fact that the sound of the erhu comes from the vibrating of a python skin that is stretched over the sound-box. The question is whether I will be able to print this film or will I have to get something else to put into the printed model. I am thinking of the erhu as a mix between a violin and a banjo, so I'm hoping that I can make the skin be more like that of a banjo and still have the erhu function.
October 23rd: I need to test what will work instead of the python skin. I have modeled a test piece that will allow me to test first the plastic itself, then different materials over the sound-box.
--- New Direction --- (note, I attempted to post these logs a while ago, but the page didn't update when I thought it did)
Log 1: Now that I'm making a small, fridge-mounted device, I have to decide what to use. I am thinking that I can use an arduino. I'll have to do more research into what I would use for a barcode scanner and how that would work.
Log 2: I found a bar-code scanner to attach to the device. It reads the code to a PS/2 keyboard input in the arduino. I also am starting to work on designing a casing for the device. I'm thinking that I will use magnets to attach to the fridge, but again, testing will decide what happens.
Log 3: Research has revealed more and more data showing that A) Food waste is a problem, and B) Solving it would have a hugely beneficial impact on the world.
Log 4: There is one thing that I need to figure out what I'm going to do. This is how the device will interact with the user. The device needs to communicate when something is going to go bad, and then be able to communicate what that is going bad. To do this, I'm thinking that it can have a piezo-buzzer to alert the user that there are things going bad, and then when the user recognizes the device, the device will put what's going bad on a screen.
Log 5: I am now scanning! I am able to store the barcodes of products in a program. Now, I have to create a structure that will be able to stay on a fridge and not fall off. It will have to fit all parts that I have to use and should be easily useable.
Log 6: The case for my first prototype is almost complete.
On a different note, I have an idea about how my device will pull expiration dates from products. The answer is that it won't. Whenever it scans a barcode that it hasn't seen before, it will ask the user what the expiration date of the product currently is. It then takes note of the present time to the time specified and uses that in the future when scanning that barcode.
Log 7: My barcode scanner is running into problems. Programs that had worked before are suddenly failing. This has lead me to believe that my problem is a hardware problem. I'll be testing with other devices to narrow down where the problem is occurring.
Log 8: Things are starting to work. The scanner is back up and running and the screen is working. The interesting thing is that it seems that the screen is interfering with the barcode scanner. In my code, I had to make sure that they were never running at the same time. Now, all I have to do is to handle the timing, and I've found the library to do just that.
Log 9: TIMING!!!
My device is now able to time a set amount of time from any given point to any other point. This will be essential in knowing when products are going to expire. I have a way to store the times that things will expire, and be able to trigger a buzzer and a light when they do. Once that part of the program is completed, I just have to set up the device and then I'm ready for my first trial run.
Log 10: Servers
The SmartFridge 9000 is moving to a new level. Now, the device will be communicating with a server when preforming operations. I'm currently programming a server to handle these requests and communicate them to and from a database. Not only will this allow me to use multiple devices with one server, but it will also put less computational load on the devices themselves.
No comments:
Post a Comment