Evander Batson
xinhe feng
FluffyLeecy
frankiezek
gaboratparsons
giang063
gracegotlost
lauriewaxman
Siwen Li
Xiaofeng Lin
Yury Gitman
mar28th
Max(TONG WEN)
Soohyun
sabotai
Susan Lin
Set backs and a chart
The last two days have not been amazing for me, but I have gotten some work done. Unfortunately, I am already behind on the schedule I posted two days ago.
I largely solved the serial problem I was having, which is good. In my test, I was just flooding the serial port by not waiting at all between messages. Upping the baud rate helped by letting the receiver come closer to being able to handle everything coming in, but it still wound up falling behind. This is probably why openFrameworks kept crashing.
Saying "hi" way too many times per second.
The solution was to have OF or whatever application needs the data actually make requests, so that information is only being sent when it needs to be.
Getting the transmission of data working wound up taking far, far longer that I had expected, but seems to be working. I narrowed down the important atributes for each ball into the following variables.
ID – int (0-6)- id number of the ball
velocity – int (0-1024)- speed of the ball
distance – int (0-1024) – distance to the next closest ball
collision – int (0-1) – effectively a boolean saying if the ball has been hit or not
(This last value is an int for the sake of transmitting it as a single byte, the same way everything else is)
These values are determined by the arduino paired with each ball based on the sensor readings in the ball and some simple on board calculations.
For actually sending things, I got some help from Christ (who recommended some very useful sections of Programming Interactivity) and Zach Lieberman. Each of these values are broken down into a byte or a series of bytes. ID & collision can fit into one byte each while velocity & distance each require two bytes (although an int is generally stored with 4). These bytes are sent individually when info is requested and put back together by OF. An arduino attached to my computer acts as the base station, mediating between the balls and OF.
Working with the data at this level was very informative in terms of figuring out how the flow of information in my project would work. I can’t imagine deviating very far from this chart:
This part was rewarding. but things went wrong from here on out.
I tried to re-create my self contained wireless unit for the gyroscope to put it in the ball and test for collisions, but I believe I burned out my gyroscope. I’m not sure exactly how it happened, but I am getting no readings from it, and it seems to be providing no resistance when it is attached to power and ground, which causes problems for the arduino. I have a few more being mailed to me, but they are not here yet, and this means I may need to buy more, which I’m not thrilled about.
This may have been the moment of death for my gyroscope
That leads me to my other worry: shipping. I have two sparkfun orders on their way to my house at the moment, the oldest one should have been here today but wasn’t, and the one with my lithium batteries was not even placed until just a few days ago. Also, my order of adrweenies from Solarbotics (which I orderred 4/8 is not even due to reach my place until 4/19). When I orderred it, I only bought 4 because I wanted to make sure they worked before buying enough for my whole project, but if shipping takes that long, it isn’t realistic to plan on buying more from them. I may have to run around trying to find ardweenies that people have or use Lillypads for some of them.
So it goes. Hopefully my new gyroscope will arrive today, and even if it doesn’t I can move ahead with the IR detection on the balls.
scottpeterman, 
Oylum and 
hilalkoyuncu, and 
Lee are discussing. 
Thom Hines are discussing. 
Chris Piuggi are discussing. 
Making Toys 
Reply