Electric Longboard Weekly Log
February 12th
This week we finalized our project idea for an electric longboard. We decided what pieces we were going to buy and which ones we would make, in addition to producing a timeline and Gantt chart for our project proposal. Also, we needed to create wiki accounts which ended up being more of a pain than we realized. Once we had created our accounts we were able to learn how to create a wiki page and format it to our liking.
- till next week...
February 19th
For the past month we have been thinking about this electric longboard intently. We had a dream of making a remote that corresponded to the opening and closing of the rider's hand using a flex sensor and wirelessly relaying the information to the arduino board and engine. This week we found out our project was a bit too ambitious and was not going to work. A crushing blow to our spirits, self esteem and confidence, but soon we realized this is a part of engineering. Nobody said this would be easy so we are ready for the challenge! Bring it! After a long talk we discovered it would be too risky financially and physically in the time frame that we have. As a result we have been brainstorming new project ideas, and scaled down versions of the electric longboard. After many brainstorming sessions and one very productive meeting with Alden we have decided to make an electric longboard without a motor, that focuses more on gadgetry and enhancing the riding experience. We hope to figure out how to measure the speed of the longboard, position, and direction of its motion while adding headlights for a safer night riding experience. (but don't forget to wear a helmet!) At the moment we are thinking of using a raspberry pi (not for eating) to create a self sustained circuit that will be confined to the board. We want it to be able to intake data from a gps chip and convert it to a distance traveled, add a reed switch circuit to measure how many times the wheel spins(how fast we are going), and make headlights and potentially back lights which will switch on and off based on direction of motion. At the moment we are nailing down our project proposal and hope to have a very concrete idea of what we are doing by the end of the weekend.
March 10th
After our meeting we determined a number of things:
The magnets are not going to work for the encoder, and we are going to print an encoder instead.
Our GPS chip is on the cheaper side, but hopefully it is enough to determine or velocity vector, therefore distance traveled. We can write a filter circuit to clean out drastic changes in location and instead just use vector lengths.
Our headlights are going to be the last step assuming we get out GPS and encoder working.
We have purchased our GPS chip and Raspberry Pi so that we can start working on the coding and circuitry immediately after break.
Also, we cleaned the longboard so its ready for test runs once the circuit is built.
Our next step is going to be printing the encoder and setting up the code to determine speed and direction.
We're also going to need to become more familiar with linux and Ubuntu coding language so we can utilize the raspberry pi as soon as it comes in. The Raspberry PI runs linux on it out of the box meaning we can download an image onto a hard rive so we can run it through our computers.
March 25th
The week after spring break has been exciting largely due to the fact that we finally got our materials!
Now that we have our raspberry pi and gps chip we are able to really start cracking down on production.
We have set up rasbian and started writing some code for the GPS, but it has not been working thus far.
Currently the goal is to familiarize ourselves with GPS coding standard, finalize our GPS code, and start taking some tests.
Next on our plate is ordering the LED's and light sensors for the encoder, and 3D printing an encoder for the wheel.
We are still unsure how to use the 3D printer so that will probably be the focus of the ext week or so.
April 7
We've hit a bit of a speed bump this week. We've been able to download multiple GPS libraries but when we import it in our code on Python the computer is unable to find the module. We were skeptical that the computer was looking in the wrong place for the libraries (even though we used a standard sudo-apt get call in terminal). After much struggle with this we thought we'd try to just get a raw reading from the serial pin. To this we found out we needed to download wiringpi2. Terminal told us that we had successfully installed wiringpi2 but when we went into python to get a raw reading from our gps, we again got an error message: "No module named wiringpi2".
Though we plan to use our raspberry pi for the longboard, we thought we'd hook up the gps chip to an Arduino that we use for another class just to familiarize ourselves with the data the gps chip receives (we assume we'll get this library import problem fixed soon with a little help). Finally we had some success...the Arduino worked! We hooked it up to an analog pin and analogRead() values from it. We are unsure how to interpret this data but we got values ranging from 100-300. However we noticed we really shouldn't be reading the data from the analog pin, we should be reading it from the serial pin rx. When we tried reading it from this pin our board started having troubling syncing with the computer.
For the encoder we plan to design and start printing this week. We've ordered the LED's and photocells so they should be in sometime in the next week. Hopefully we can use the 3d scanner to scan a longboard wheel to more accurately design our encoder.
Once we have the GPS outputting useable data, and the encoder reading reliably it will simply be a matter of creating an enclosure for the electronics and analyzing some test data in excel.
April 14
We finally were able to clear the errors in our GPS program! We were making a very silly mistake: we were trying to connect to serial AMAO not AMA0 (let me be more clear, AMA(oh) not AMA(zero)). Anyways now the code compiles and we are getting values in the serial monitor.
After this we figured out how to write the output in the serial monitor to a text file. To do this, we had to create a method in our python code to create a text file and open it for writing. To do this you have to f.open("GPS.txt","w"). The "w" means you are writing to a new document. After this we have to close it. Once the text file is created you can append to it. So, we created another method for this purpose. In this method we f.open("GPS.txt","a")--the "a" stands for append, and initializes the text file to be written to and append data to it. After this we had a line f.write(The Data We were getting form the serial port). The final method in our program was a method to close the text file. This was simply a f.close() statement. We then created a main() method which first called the open method and then under an infinite while loop--while(true)-- we continuously read data from the serial port and appended the data to this newly made text text file.
And, this worked...to a degree. We are running this code under ground in the basement of Urbauer so our GPS cannot receive data. We are waiting for our battery to come in the mail so we can run the program, go outside with the raspberry pi and analyze the data. We will then figure out how to read the data from the text file and sparse out the data we do not need with regex expressions.
We also did a bit of 3D printing this week for the encoder.
