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. We began with a basic cube design to be stuck to the top of the wheel but the printer resolution was insufficient making the holes for the wires collapse. After a size increase and no improvement a ring design was implemented. A ring around the truck will secure the photocell while an attached tower houses it. After a few iterations the mount for the photo cell seems as if its going to work. We are going to make slight variations and print a light mount, which will be on the other side of the encoder disk outside the wheel. Once we have the ADC hooked up and programmed we will be able to mount and test the encoder.

April 21

The printing did not work out as planned. Our measurements were slightly off so a new design is in the works, which will include spacers and resized ring diameters. Once we have the pieces fitting the mounting should be relatively simple It should be printing in the next few days and afterwards we can tune the code to our measurements from the board.

The photo cell and analog to digital converter came in the mail. It was pretty hard to wire but we figured it out. Once it was all wired up we wrote code for it. We imported spidev and open and read values received from the adc. We hit a road block for a bit because the computer however can only have 1000 of these open at a time so we had to close them too. Once we were able to read values from the photocell continuously with out the program crashing we noticed that there was noise in our data so we created a filter for it. In our code we collect 200 readings from the photocell and store them in the array. Then we iterate through the array and add up all the values and take its average. It seems like a value of .05 means that the green LED light is shining on the photo cell. At first we thought that the photo cell would return higher values when the light was shining on it but that was not the case. When we covered the light we ended up getting higher values so we realized we had the flip the conditional statement. Once the if statement knew to look for values below a certain point the code worked beautifully. Unfortunately it seems when the light is near the encoder it is very hard to block. Once we have readings from the board hopefully it will become more clear. Also the battery came and is working beautifully. Unfortunately the GPS code has experienced some bugs for inexplicable reasons. We have been working on potential remedies but as of now the data is largely unreadable. When printed on python idle shell the values are displayed but get cut off on the left side of the screen. On the text file some lines are readable but most characters are unrecognizable (they come out as a box with a question mark inside of it). We think it might not be converting the bits into chars correctly but that logic also doesn't make sense because some lines do come across correctly.

The case for the pi is in the mail so mounting should be done early next week. Also, a larger enclose may be necessary to house the breadboard and wires which would be a job for the 3D printer early in the week. The only concern with the case is that the GPS requires clear lines of sight.