About this blog
Of game and graphics programming, cryptography, and electronics.
Entries in this blog
So I've been working on a little Android game for a while now. Mainly as a first effort, small scope, learn the technology sorta deal. So it's pretty simple in concept.
Anyway it's getting to the end of development now, mainly just polishing and tweaking, so I decided to take a crack at making an ad supported version. Generally Ad Mob is meant to integrate with standard Android UI elements, and not just an all encompassing OpenGL ES canvas, so it look a little shoe horning to get it in there, but it's in now.
I had been loading it up and trying it out, clicking the ads and testing how well my app resumed and such. And then I looked at my Ad Mob account... I had made $0.02!!! That's real money! I mean not a lot obviously, but man! I was expecting like $0.00000001 or something! I mean after all it had only been me messing around for a few hours testing my app!
Now up until this point I had been taking care to only show ads in non-intrusive places, like on the menus, or only after you died in the game. But man! For a moment I had a flash of "holy cr@p! I could make real money off of this! Lets put ads EVERYWHERE!!!!"
I started rationalizing to myself how I could display ads during the actual game play, and I could use Ad Mob's feature for interstitial ads ( for those of you that don't know, an interstitial ad is one that takes up the whole screen and is usually placed in the middle of a flow between screens and must be manually skipped to continue on to the next screen, they are terribly terribly annoying ) to get even more ads in there!
I began tweaking some things and then stopped myself. I know how I feel about ad supported software to begin with. And especially software that's just crammed with intrusive ads all over the place. Usually doesn't stay installed on my phone too long.
I want this to be software that I would want to use. I want it to be a quality (if small) game that can still make at least some money. I plan on releasing the ad supported version along with a $1 ad free version. I feel like that's the best compromise. And one that I would be happy with as a consumer & gamer.
But man... wouldn't it be awesome to see that # in Ad Mob go way up
Well this project didn't go as I had planned. Every part of it took about ten times longer than I expected. And in the end, it still didn't function exactly the way I wanted.
First some fun media to show what did work :)
Also a short video of it:
" target="_blank">YouTube: Distributed Planar Key Encryption
Now let's start where I left off in part 1.
My first task was to come up with the method I would use to intersect my 3D planes. This was actually a fun exercise for me, and this is what I came up with:
Given 3 planes (Pa, Pb, Pc) first intersect Pa and Pb, resulting in a linear equation, giving any point on the line of intersection generated by Pa/Pb. Then using this linear equation, intersect that line with the third plane Pc, and generate the unique point of intersection.
I coded this up using floating point math, and the whole thing only took two or three sessions to get implemented and debugged, but it was actually pretty fun.
Next up, I needed to port my Planar intersection algorithm to fixed point math. To do this I had implement a minimum number of fixed point math operations... this took a while.
I read up on Fixed Point math and began implementing the most basic operations. But then, I realized I needed to implement others such as sin, cos, square root, and that's where things got messy.
For those of you who don't know, Fixed Point math (also referred to as Scaled Math) is simple enough in theory. Take for instance the number 3.14, if we wanted to represent this using integers and not floating point data types, we have to get rid of the decimals. Well the easiest way to do this is to just multiple it by (in this case) 100, making 3.14 into 314.
Now lets say we wanted to add 1.0 to 3.14, but in fixed math, we would need to move 1.0 into our new fixed point math space, again, by multiplying by 100, so 1 obviously becomes 100. Now we add them: 314 + 100 = 414
All pretty logical and easy. And now, if we want to go back to decimals, we just divide by our base (which is 100 in this case) making 414 / 100 = 4.14, so as you can see, things worked out, and we did all our calculations (only addition in this case) in integer math, instead of floating point math, meaning it's 100% deterministic! (aka: the whole reason I'm doing it this way)
So why is it called "Fixed Point Math"? Well when we use 100 here, we are essentially saying that our number will have two decimal places. A Fixed Point "1" in our system here is represented by 100. A Fixed Point 0.5 is represented by 50, like wise a 0.01 is represented as a 1. So how do you represent 0.009? You don't. That's the draw back of Fixed Point math. You have a Fixed number of decimal places, and anything below that is simply lost.... It gets worse.
Let's take a look at Fixed Point multiplication: 3*3 in our system this will look like: 300*300. Now we all know our answer should be 9 (or 900 in Fixed Point), but what happens when we multiply our Fixed Point representations? 300*300=90,000! It's off by a factor of 100! Well that number is familiar, isn't it! See our Fixed Point base number is in the multiplication as well, if you break it down: (3*100)*(3*100)
The fix is simple enough, just divide it out when you are done, so our fixed point multiplication now becomes two operations: (300*300)/100=900
Bbbuuuttt... You don't get off that easy. Let's take a more real world example. I used 64bit ints, and I needed much greater then 2 bits of decimal precision. When you are making a Fixed Point math system on a computer, you need to take into account your actual data type, and realize that each bit of decimal precision reduces the whole number range of your variables. Let's take a look:
Let's use 8bit ints here. This is what a 1 looks like normally:
Now lets say I want 4 bits of decimals, my one is going to sit here:
That's the binary representation, but it's still the same thing, our scaling factor, instead of being 100, is now 16 (in base 10).
Now back to the problem of multiplying our numbers which contain the scaling factor. Here we only have 4 bits of whole number precision. The largest whole number we can represent is 15. So, if during the course of multiplication we ever exceed 15, we will over flow our data type, and lose very significant parts of our number. We must prevent this, if at all possible.
It doesn't take much number crunching to realize, that because our multiplication will be off by a factor of our scaling factor, relatively small numbers, when multiplied together, will overflow our data type before we ever get a chance to divide the scaling factor out.
Luckily there is a generally accepted solution to at least try and mitigate this. Since we are using binary instead of base 10 to define our scaling factor, we can use simple binary bit shifting to attempt to alleviate this (this could be done with division, but this is simpler since we are using binary anyway). If we shift each operand in our multiplication to the right a few places, we can reduce the size of the scaling factor that goes into the multiplication, and thus reduce the likelihood of overflowing. So in this example, let's shift each operand 2 places:
00010000 becomes 00000100 (aka 4 instead of 16) here we've halved the scaling factor. Now in an equation:
2 * 2
in Fixed point:
(00100000 >> 2 ) * (00100000 >> 2)
00001000 * 00001000 = 01000000
And there you go! We pre-shift half of the scale value from each, so that when multiplied together, the scale value repairs itself, and we avoid an overflow in many cases.
SO! Why have I dragged you through this? Because this is the part that ruined my encryption!! Obviously, the pre-shifting knocks off 2 bits of decimals here, so whatever their value was, is lost! This is an accepted drawback of Fixed point math, but not for me!
In my actual implementation I have 64bit ints, with 16bits of decimal precision, and 48bits of whole number range (clearly range was more important to me then precision. My scaling factor is 65,536) which means I pre-shift by 8bits during multiplication.
Here's the problem: if I multiply 3.141592 by 12.345678 I will get a different number than if I multiply 3.14 by 12.34 ( 38.78508323 vs. 38.7476 ), that's a difference in the hundredths place! That's fairly significant! Now if I take that result and feed it into another part of an equation (as happens many many times in my equations), that difference will propagate through along with other inaccuracies, and the final number will be greatly effected by each inaccuracy.
You might say "Why is this a problem, Adam! you knew Fixed Point math was inaccurate when you started this!" and the answer is, because I didn't have the foresight to realize this wrecked the communicativeness of equations!
Using the example above, let's say the result is then multiplied by 8.765432, in theory:
3.141592 * 12.345678 * 8.765432 == 8.765432 * 3.141592 * 12.345678
But because of how the inaccuracies propagate through from one operation to the next, they don't equal each other!!!
So what exactly does this destroy for me? Well if you pass my Planar intersection algorithm 3 keys, it will generate a 3D point (the encryption key).
If you give the algorithm Pa, Pb, Pc, it will create a linear equation for the intersection of Pa/Pb, then intersect that with Pc. The point generated from that will be used to encrypt the file. NNnnnoooowwww if I want to decrypt the file, and I provide the keys in ANY OTHER ORDER (such as Pb, Pa, Pc) the inaccuracies propagating through the equations will result in a significantly different point! Thus when it is used to decrypt the file, the decryption will fail!
It gets worse! Another central tenet of the algorithm is to be able to generate more than 3 keys, and use any 3 of the keys to generate the parent encryption key, but because of this problem, using ANY KEYS OTHER THAN THE ORIGINAL, in ANY ORDER OTHER THAN THE ORIGINAL will never generate the proper 3D point!
I didn't realize all of this right off the bat. I wrote my Fixed Point math, I even implemented the more complex functions: sqrt(), sin(), etc... And moved on.
The encryption itself is actually just a simple XOR. I take the 3D point, parse each component to a string, concatenate them together, and then use CryptoPP to create a secure hash (high randomness, low redundancy, low collision rate), which I use as the bit stream for my XOR encryption. Not terribly secure, but the whole point was the key generation, not the encryption itself. So I was ok with it.
Then I went on to make the 3D view of it all, so it would have "Hollywood style" graphics. I added a "lookat()" function to my camera and learned quite a bit more 3D math in the process of creating and orienting the 3D Planes. All in all, I learned a ton on this project. But when I realized the problem with the math, I became very disheartened, so the 3D View is a bit unfinished... I had intended to do more. But I don't want to now.
Now I'm sure, that given enough time, I could eventually solve these problems. But this is a project with absolutely no practical application. It's demo-able, and I've learned a ton. So it's time I move on.
Time to get back to some actual game development :)
If you'd like to try it, you can see the project page, and download it directly here (source is included, it's ugly).
[ My first real post, it's a bit long, sorry about that :D ]
[ I'm more accustom to writing for less technical audiences, so if this comes across as too much hand holding, I apologize, I'll try to tech it up more in the future ;) ]
So I have had an interest in Cryptography for a while. Now let me stop you right there, no, I'm not a crazy math genius, so I'm not going to regale you with formulas and number theory. No my interest is more... playful.
My first ever Cryptography related thing I wrote some years back was a super simple cipher tool. My girl friend at the time was giving me notes in a cipher she created (it was a straight forward, 1 for 1, substitution cipher), so I wrote a program to decode them more quickly. I then expanded the program to some other simple ciphers.
Later I wrote a simple XOR encryption program, and also a steganography program which can hide ASCII text in 24bit Bitmap images. (Both projects can be seen here)
Finally I wrote a web based cryptography game called Decrypt that teaches people how to decode ciphers by hand while unveiling a story to them. (Though as browsers have changed and improved, it has falling into a bit of disrepair, though it is still playable I believe.)
Fast forward to a few months ago:
I have been milling around on cryptography sites again, pretending to understand what I'm reading. I can't see the day when my pseudo understanding of asymmetrical encryption will pay off, but hey, you never know ;)
So with thoughts of lovely encryption algorithms dancing in my head, I turned to another topic I had been mulling about, it had to do with some 3D math I had abandoned in another project: Calculating the intersection points of 3D Spheres (It's not redundant, look up 4D Spheres, AKA: Quaternions). This oddly enough lead me to a silly idea for an encryption key generation scheme: Distributed Planar Key Encryption
( Or at least that's what I'm calling it. I don't know if it's something that has been done before. It's kinda pointless, but cool :P )
Let me stop right there, I'll come back to the math in a moment. So the idea for this encryption scheme came (as many ideas of mine do) from the movies. You've seen those movies where a super important vault, or missile launch system, or whatever has multiple key holes, and both keys must be inserted at the same time to be able to unlock it? It prevents any single person from misusing their key, as multiple people are required to agree on accessing it.
Well maybe it's just me, but I think that's kinda cool :P
Ok so back to Distributed Planar Key Encryption, that's exactly what this scheme aims to be. You see, several Child Keys will be generated at encryption time. These keys, Child Keys, will combine to form the single unique Parent Key which is the actual encryption key. That of course will be used to encrypt the data.
Then the encrypted data can be sent to each concerned party along with a single Child Key. Or the encrypted data can be kept in a single place, whatever, that's not the point. The point is that no single user can decrypt the data with their given key. They must bring together enough keys to pass the Key Threshold. Once that Threshold is passed, the Parent Key can be generated, and the data can be decrypted.
The important part is that ANY combination of Child Keys, as long as you have enough of them, can generate the Parent Key. So you can't just take the Parent key and break it up into pieces. If you did that, you would have to have specific Child Keys in order to reconstruct the Parent Key. It would also mean that given one Child Key you could begin to solve for the other Child Keys. Needless to say, this would be a bad thing...
OHKAY... So. How do you go about making a scheme that satisfies these requirements! Actually it's a lot easier than you'd think. And this is where we come back to the 3D Spheres I mentioned earlier. Given 4 unique Spheres (they ALL must overlap) you can calculate a single unique point in 3D space where they all intersect. And use that point as the basis for your encryption key (aka: the Parent Key).
So this was my first attempt at a Distributed Key Encryption Scheme, dubbed: Distributed Spherical Key Encryption
But there were some problems. The first was that the math to intersect Spheres is quite complicated. Though I got that working finally. The next problem is what killed it however. See, on the surface of a sphere, there are, in theory, an infinite number of points, because 1.3 is a different number then 1.33, and so on. (Of course, a computer is a finite machine, so it's not quite infinite, but still pretty good.) The problem came in how modern computers store decimal (aka: rational) numbers.
They are called "Floating Point" numbers, and computers actually suck at storing them exactly. You can read up more on why that is on Wikipedia if it really interests you. But here is why it's a problem: when I run these complicated equations to calculate the point of intersection, I get slightly different numbers every time. That is to be expected with Floating Point arithmetic. And we, as computer scientists, have ways of dealing with it. Generally, we look at two numbers that we want to compare, and if the difference between them is under some threshold (epsilon) then we consider them to be the same number.
So the difference between 1.45555 and 1.45556 is less then the threshold of 0.001, we would consider them the same number. I'm pulling these numbers out of you know where, in reality epsilon (aka: 0.001) is much much smaller, but you get the idea.
So it should have worked, right? Wrong. See, the equations are complicated enough, and each time a floating point operation is done (+, -, *, /) there is a slight bit of error. Since so many operations are done in the course of determining the point of intersection, all the different errors add up to quite significant fractions so that the epsilon test would fail ~9 out of 10 times, making it quite unreliable.
What this means is... Given however many Child keys, 9 out of 10 times, you would NOT generate the proper Parent Key. And the Decryption of the data would fail.
My only option was either to round off to, at MOST two decimals, or to use fixed point math and drop decimals all together (sort of).
Neither solution was preferable. The first one, would probably make it reliable to 99 in 100, but that 1 in 100 times when your secret data didn't decrypt, wouldn't be a happy day.
The latter method can be refereed to as "Discretizing" the math. Or, making the math use Discrete numbers. The problem with this is that, instead of having theoretically INFINITE points of intersection on the surface of your sphere, you now had a discrete, known number of possible points. Now remember, the point of intersection of 4 Child Keys IS the Parent Key. Thus, the complete Parent Key actually and truly exists on the surface of every single Child Key sphere.
When there were an infinite number of points of the surface of each child, it didn't matter. But now, by making the numbers discrete, there are a known number of points on each sphere. Thus, given a single Child Key you could brute force through the points on that Sphere alone, and find the Parent Key.
(While there are ways to mitigate this [using particularly massive spheres], it actually reduces the search space in other ways, but that's for another article.)
Just to reiterate, one of the key points of this encryption scheme is to not be able to determine the Parent Key with any fewer then N Child Keys. N being the Key Threshold as defined by the algorithm.
So this was clearly not an acceptable solution as it violated one of the core tenants of the encryption scheme.
(As a side note. The spherical keys were flawed from the start. See, N (the Key Threshold) for the algorithm was 4. You need 4 spheres to generate a completely unique point. But given just 3 spheres, you can in fact generate exactly 2 unique points. Well you don't need a computer scientist to tell you that brute forcing 2 possible solutions won't take you very long... Thus with only 3 of the 4 required Child Keys, the Parent Key could easily be deduced.)
Quite a bit discouraged, I stepped back from it and had some dinner. And it struck me. I was only fixated on using Spheres because it was what I had been working with previously in an unrelated project. And that in fact, as I just mentioned, they are quite poorly suited to the task anyway.
3D Planes however are perfect!
For those who forgot their highscool geometry:
3 Dimensional Plane: A theoretical surface which has infinite width and length, zero thickness, and zero curvature.
Planes have a theoretically infinite surface area, thus they don't suffer the same problems from using discrete, fixed point math
Planar intersection testing is much simpler then Spherical intersection testing.
It only required 3 planes to determine a unique point of intersection (Thus the Key Threshold is one less then for Spheres)
Given 2 keys (AKA Planes) an entire line of intersection results with theoretically, infinite points on it, even with discrete math, the security of the algorithm doesn't degrade as you approach but do not meet the key threshold.
So while 3 keys are the minimum that must be generated, you can generate any number you wish that all intersect at a single unique point, and any 3 keys can be intersected to unlock the Parent Key.
This was exactly what I had been searching for. So I began coding in earnest. (It also occurred to me, that a Linear Key system could work as well, reducing the number of Child Keys required down to 2. But I stuck with the Planar Keys.)
Now. That's all well and good. Mission accomplished and all that. (No really!) But encryption can be a very boring subject to many people. And it sure doesn't look as cool as it does in the movies, crazy blocks flying every which way to unlock the secret file. Which got me thinking. I am actually using 3D constructs in the math, so there really is no reason I couldn't visualize this in a 3D app. Ya know, actually show the different planes (keys) in a 3D view, and show them intersecting, and then highlight the common intersection point. I could even do a little animation with it to make it snazzier.
So that's what I'm currently working on, and I will be sure to post here about it when it's done!
As most techies I know, I have a set of websites I check up on each morning, and throughout the day. I get to the office in the morning, and first things first, I "make the rounds." And thanks to my handy dandy RSS reader, I never miss a single thing. I'm hyper-informed about the narrow set of topics that the sites in my usual rotation cover.
One of those sites is The Verge. A splinter group formed from former Engadget editors, it's quickly becoming one of the best tech and tech culture news sites on the web.
Recently, one of the editors that I follow closely, Paul Miller, came up with an experiment he wanted to run: go internet free for an entire year. And I mean completely internet free. Not just browsing websites, but email, streaming video, music, everything. He even ditched his smart phone and got an old Nokia, and won't even text on it.
I actually kinda get it at a basic level. The internet is completely integrated into my life, it's always there. Any lull in a conversation, out comes the smartphone. Any down time at the office, up comes the browser. So limiting one's interactions with the internet to a more balanced amount sounds perfectly fine to me.
I began following his updates from the disconnected world with some interest. My first reaction was one of: Why so extreme? So many little tasks would become orders of magnitude more difficult for him.
But the more I read of his dispatches, I began identifying with a lot of what he was saying. He talks about the "phantom limb syndrome" of the tech world. Like when you Ctrl+X a piece of text, you almost feel its unpasted ghost in your fingers until you Ctrl+V it back into existence. Or phantom leg vibrations that make you check your phone.
Or worse still for me... the phantom RSS stories left unchecked in my feed. I get a high filtering through my RSS feeds, saving the interesting articles to Pocket (formerly Read-It-Later) for more dedicated consumption later. I've got it down to a science, I'm hyper efficient at it. Clearing out my RSS feeds in the morning is a cathartic experience. For a few minutes... and then I start to get the itch... What new stories have been posted... What am I missing. I better check now so they don't pile up and require even more time to sift through later!
It kinda sucks actually. Something I really enjoyed has become a compulsive need. I tell myself it's both enjoyment (I do genuinely enjoy tech news) and important to stay up on the industry for professional reasons. But it's almost a chore now. This must be how OCD people feel about checking the lock on their door twenty times before they leave. They know it's bad but can't help themselves.
Now I'm not saying the internet is bad. It's a piece of technology. And Technology isn't inherently good or evil, it's how we as human use it that give it import and meaning. I think in terms of inventions that have most profoundly impacted our species, it goes like this so far: Fire, Wheel, Internet. So don't misread my next statement.
In his most recent dispatch, he talks about the signal to noise ratio on the internet being askew. And it really struck a chord with me. It's something that's been burning in the back of my mind for a long time now, and this put a name to it. I instantly seized on it. This was my problem with my RSS feeds. Out of usually around 200 articles sitting in my feed in the morning, I usually only save out about five to read later. I glean tiny fragments of information from scanning the rest, but it's mostly worthless.
For the last year or so I've been trying to cut down on the worthless noise that I usually click on. I've seen enough people walking into signposts and cute kittens to last me a lifetime. It's absolutely a waste of time. So I've been making a conscious effort, before I save something out to read later, to ask myself, is this really worth spending time on? And it's helped. Some. But I'm still filtering through hundreds of articles a day. The internet has lowered the barriers on content creation so far that the noise is now the pervasive standard. And finding the signal in it requires this OCD level of effort, filtering through it all if you don't want to miss something.
My RSS addiction is just one of my "phantom limb" problems though, which cumatively add up to a very distracted life style. So I'm back to reading Paul's dispatches, and being kind of jealous actually.
For my part, I've got a backpacking trip coming up to the Grand Tetons in Wyoming, and from the moment my plane lands I intend to turn my phone off, throw it in the trunk of the rental car, and have my own week of extreme disconnectedness.
Read Part 1 here
The next day at work it was all I could think about, and around lunch time, it hit me. They are in series! I'm dividing the voltage between the two servos! If I hook them up in parallel they'll EACH get 9V!
That night after a flurry of cutting, de-soldering, and re-soldering, it was ready. Popping a 9V on it made it leap forward! Excited, I set to work hooking the logic boards together, but when it came time to affix them to the chassis I encountered another problem. It wasn't really meant to host a board like this. The screw holes were probably intended for something else, but certainly not for my Arduino. Additionally, I have a bare circuit board I'm trying to attach to a metal chassis! I looked all around in my spare parts for some sort of fastener or holder or something to mount my logic boards with to prevent them from shorting out on the chassis, but couldn't find anything. Finally I settled on cutting an anti-static bag from an old video card and screwing the boards awkwardly through that bag and onto the chassis however I could make them fit.
I then set to testing out some stuff with the Arduino. Read up on the docs for the motor driver, wrote some test programs making it move and turn. Then did the same with the wireless chip, tested hosting a webserver on it and allowing you to control the motors by clicking links. It worked! It wasn't very responsive of course, reloading the page after a link click was pretty slow and all. But it worked! So I called one of my friends via Skype who lives in Texas, and using the webcam on my laptop gave him a view of the robot on the floor. Then I setup some port-forwarding so he could access the server hosted on the robot, and it was ready to go! I stepped back, couldn't see the laptop because of how it was positioned for the webcam. And all of a sudden this little robot starts moving on its own, via commands from my friend in TEXAS! (I live in Boston) I mean c'mon! We really take the internet for granted I know, but the series of events that are transpiring to make his actions in Texas manifest themselves in the real world in my apartment in Boston... I mean c'mon!!!
As Tesla once said: "I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success... Such emotions make a man forget food, sleep, friends, love, everything."
Over the next several days I fast iterated. I ripped out the webserver and wrote a proper socket server for the robot, and socket client that ran on my home server. It was MUCH more responsive. Then I wrote a webpage that used AJAX to send "real-time" control commands to stub PHP script, which in turn sent them onto the socket client. And finally, after much research, I found a webcam that worked with Linux, had auto-focus, and great video quality (glass optics, no plastic crap), and a software package for streaming the video to the control webpage (no X11 or GUI of any kind, which restricted my options quite a bit).
This was a blast, you could log onto the site, see the robot from the webcam mounted in the corner of the room, and drive it around using WASD or GUI controls on the webpage. And I did some input wrapping so key down & key up worked the way you'd expect. It was fun. But it was lacking something big. I wanted to drive this robot in first person perspective.
I began researching wireless webcams, or really wireless cams of any kind, and there weren't a whole lot of options. I know you're reading this and saying "Oh c'mon, there's GOT to be some wireless webcams out there!" But really! There aren't! Try Googling for them! There's one or two that were prohibitively expensive and had other problems. Using a regular camera and streaming the video over the robot's WiFi connection was not an option. The Arduino has 2KiB of RAM, and clocks in at 15MHz. That's not a typo. One, Five MegaHertz. Ya, you're not doing video processing of ANY kind on that
The last option I had was home security cameras. But they were prohibitively expensive. The CHEAPEST were well over $100, most up around $300. To give you an idea, I was into this project for about $150 so far, so this camera would cost more than the rest of the project COMBINED. Not an option. But lo and behold, I found a home security camera meeting all my criteria for HALF OFF on a Black Friday sale! So for $60 I was in business.
I got it, chopped up its power cord so I could run it off the robot's internal power, and was off and.... crawling? Ya... and that's where this project kind of ends... After all of that, the wireless security camera was too heavy for the servos. It could BARELY crawl forward, and could only turn about 50% of the time. And this was one of the smaller ones I had seen while doing my research (size was one of my criteria when selecting a camera!). Anti-climactic, trust me I know.
But still, it was a great project, and I learned a LOT. I would post a demo or pictures of me controlling it, but the robot has since been dismantled. I'm scavenging parts for my next project which I hope to be much more successful!
I probably should have posted about this when I was actually doing it. But C'est la vie.
Anyway I had been messing around with some Arduino stuff a while back, and got pretty far but never finished a project. Other things came up so I shelved it all. Then we got a kitten and I thought it would be fun to be able to play with the kitten while I was out of the house.
So I came up with the idea for a remote control robot with a kitten toy attached to it that you could control from a web page. Already having an Arduino, the natural choice was to extend what I had.
I looked into the different parts I would need and settled on this build:
SyncLabs WiFi Shield (802.11b)
1amp dual motor driver shield
4 wheeled chassis kit
Now being, at least what I consider to be, a fairly adept programmer, I was not worried about the software side of things.
However I was also not worried about the hardware side of things... This was stupid.
Since the control side of the hardware was merely 3 boards that fit neatly together, I started by focusing on the chassis construction. Now I went into this wanting it to be a fun learning project, not just a robot in a kit. And boy did I get more than I bargained for.
The Chassis kit consisted of a 3 zip-lock bags. 1 contained several tiny metal pieces that clearly were meant to be the chassis frame. 1 contained assorted screws and other hardware necessary for assembly, and the last contained 4 small-ish servos.
I've done some electronics stuff, and we had covered circuits in my college physics classes, but any useful knowledge from those past experiences fell out of my head when I was presented with this unorganized, unstructured bag of parts. There was no manual, no instructions, no numbered pieces. Just a bag of constituent components that could, in the right and knowledgeable hands, be assembled into a robot chassis. Though truth be told they could also be assembled into a doomsday machine for all I knew. Each seemed equally possible from where I stood.
But this is what I had wanted! I wanted to embark on untrodden ground! I wanted to INVENT! Not to follow in the path of countless others! (Of course this isn't really Inventing, it's more so playing with Legos, assembling pre-made pieces into a semi-unique configuration, but give me a break )
So I dug in. Not knowing where in particular to start I began sizing up the metal parts that would make up the frame. Fitting them together didn't take long to figure out. I ended up assembling them, promptly realizing that the order I did it in presented me with problems, and reassembling it again, several times in fact, until I found the optimal method. Attaching the servos again made me disassemble and reassemble the frame (with the frame fully assembled the space was too small for me to work in to attach the servos).
So Finally, after longer then I'd like to admit, I had the chassis assembled and servo's installed inside it.
(I'd like to apologize to my past physics professors for this next part. You really did teach me these things! I just forgot for a few hours...)
I played around with my circuit boards a little, and mulled the problem before me. My motor drivers could drive 2 motor independently, but I had 4 servos. It's not a complex problem and the solution may seem obvious, but exactly how to go about it, and the fear derived from being "untethered", made it a contentious decision. After some rough sketches of my wiring harness, I did some Googling and found some one else's rough sketch that looked exactly like mine! That was enough confirmation for me that I was right. No thoughts back to my physics class about circuits, I forged ahead...
The design I had come up with was intended to keep things as simple as possible. Each motor driver had a + and - terminal on the shield, thus I only wanted 4 wires total coming out of the chassis bound for the control board. I would hook up the 2 motors on a given side in series. This kept wire clutter to a minimum, and kept everything as simple as can be.
I could regale you with tales of soldering through the plastic that held the leads, and cutting the wires too short after one end was already soldered, or how I realized the leads on the servo's were thin cheap and breakable, or how I forgot which lead was + and which was - on the servo because one was the revere of the other. But I won't, suffice it to say it's only the 3rd time I've soldered something. And I learned a lot.
At this point I had been at this for HOURS. It was a monster session. I was burnt out. My girlfriend who had been by my side for most of it, was passed out on the couch at this point, stirring only when I would get a face full of solder smoke and make a pained nasal sound.
I was DONE but couldn't go to sleep without seeing it move. Actually hooking up the logic boards was not an option so I just taped a 9V battery to the chassis and connected the leads to it. The results were less then spectacular. While holding it in the air, the wheels barely moved, and when sitting on the ground it couldn't overcome friction it seemed.
Blurry-eyed, frustrated, and tired. I called it quits for the night and passed out.
We're in the early planning and prototyping stages for our next project. So I worked up a little prototype of the core tech we will need.
The core mechanic is based around one important assumption: That it's fun to kick over someone's sand castle
To this end we need good free-form terrain destruction! So here is my first effort:
This is about 4 hours of work.
The is tech is inspired by two main games. One should be somewhat obvious. The Worms series.
But the other was a lesser known game that I played YEARS ago called Pocket Tanks (or P. Tanks)
It was an artillery game with a few twists, the most interesting of which (in my opinion anyway) was the terrain destruction!
So after playing quite a few rounds of it, and then a few more rounds (for research I swear!) I went ahead and implemented it in C++ using SFML
Next I'm looking to implement this on Android in libGDX. Some discussions with the libGDX team leads me to believe I'll have to implement the actual pixel pushing using the Android NDK in order to get the unfettered access to the pixel buffer that I need. I've never worked with the NDK so this should be a fun learning experience to get my hands dirty with it!
[ A bit late on this post, but as the guy in Ghost Busters 2 said when the Titanic arrived in New York... Better late than never. (What? too obscure?) ]
So my friend and I have released our first Android game!
[Android Market Link] Oceans Unleaded
[Android Market Link] Oceans Unleaded Lite
It is small in all respects. We intentionally picked a very simple game so we could focus on refining our process of working together, and the tech and idioms specific to Android, and how the release & advertising process works.
However, while small, we still wanted it to be a quality and polished effort.
And I'm happy to report that I think we succeeded gloriously in all areas
It's a fast paced "whack-a-mole"-esque game set under the surface of the ocean. There's a circuitous mess of oil pipes which... low and behold... begin springing leaks! You must rush around and fix the leaks as fast as possible. As the oil content of the water rises, the poor fishes who are swimming around die and float to the surface Poor fish.
And no matter what you do, you always lose. (It's sorta like the helicopter game, you always lose, but you're trying to beat your previous high score for how long you stayed alive).
There are a few extras thrown into the mix, like a supply plane that drops power ups randomly. And a rescue boat you must find when you run out of bandages for fixing pipes. But like I said, it's a small game in all respects.
There are a few interesting things (at least I think so) technically that bear mentioning. The game is written entirely in Java, based on a great library called libGDX. GDX abstracts away the platform specific stuff (Think SDL, or SFML) and provides back ends for PC & Android. The great thing is that you can develop right on your computer, run and debug right on your computer (much nicer than debugging over the USB link) which makes iterations MMUUCCHH quicker.
As GDX develops it's starting to provide a robust set of base classes for game development. Which is even nicer than it sounds because the GDX author is a performance Nazi! (You know... the good kinda Nazi) Always benchmarking and improving. So if you go that route you really will get the best performance possible out of Java. And the heaviest lifting is done in native Android back ends.
For this project, the team was just me (programmer) and my friend Mike (artist/anything creative). We have already started pre-production (doing a much more robust planning stage this time around) and have brought in a long time friend of ours who works in the AAA industry to do art and game design. We're learning a ton from his experience and adapting some of the process he has seen that work well. (Still keeping the process pretty light weight as this is just a 3 man side project.)
With both of these artists though we officially have WAY more asset bandwidth than technical bandwidth. And our next project is a fair bit more ambitious which worries me. So I'm mulling over the idea of a 2nd programmer. For side projects I've found it exceedingly difficult to find competent programmers who have both the desire, and time to devote. Which is to say I've never found a programmer with those 3 elements Also if there is going to be money involved (which we sure hope there will be lol) then it gets more difficult bringing in someone you don't know. There can be some sticky legal issues down the road.
Well anyway, I'm really rambling now, so go give our game a try if you have an Android phone!
I've had my Droid for about a year and a half now (got it the day it came out) and all though it has treated me well, it's getting quite old in "phone years".
I'm not due for an upgrade until July, so it's not a pressing issue at the moment, but while musing on what I might get when it's time, I have come to the conclusion that there really isn't any Verizon Android phones in the near future that look compelling.
Probably the most interesting phone currently is the Motorola Atrix 4G, but of course that's AT&T.
HTC's up coming phones are decidedly last-gen, lacking the hardware sensors that 2.3 brings to the table, and shipping with 2.2.
The Sony PlayStation phone (Xperia Play) is fairly interesting to me for it's performance and how up to date it is with 2.3's hardware features, I feel like it will be kept up to date as new versions of Android roll out, but that's admittedly based on nothing.
And then there is the news that Netflix simply won't ship apps to phones with out hardware DRM support. Meaning ALL current phones will never get Netflix streaming. And more than likely all the phones currently in the pipe line will similarly never get Netflix. This is actually kinda a big deal to me, I'm a Netflix addict!
On the same vein, the Motorola Xoom, while very sexy from a lot of stand points, will NEVER get Netflix! And at least for me, it's primary use case would BE streaming movies!
Now Qualcomm has recently announced a new rev of the Snapdraggon line that included hardware DRM, and Netflix has given it it's blessing, so thats great news, but they are only now shipping samples to manufacturers, which means we most likely won't see handsets with it till NEXT YEAR! Suck!
And none of the other SOC manufacturers have even announced a similar solution yet. NVidia already release their road map through early next year, none of which included hardware DRM, and that's just the SOC release schedule, not end user devices including them. TI to my knowledge has not released a road map showing so far out, but we can assume they have at least the rest of this year planned out. All this means is we probably won't see wide spread Netflix support till the end of 2012! SUCK!
As a small side note, I'd been down on Qualcomm for their less then stellar GPU they saddled their Snapdragon SOCs with, but the new rev of their GPU is a whole different ball game, it's goes head to head with the Tegra 2 and holds it's own, so I'm very interested in the next generation of phones based on this SOC.
But I digress...
The last thing that weighs in on my decisions is both UI customization (I don't want any!), and time-to-update when new versions of the OS come out. Google's own handsets get updated very quickly, but they never come to Verizon. Both HTC and to a lesser degree Motorola manage to update their handsets, but pretty much every other manufacture has a MISERABLE track record.
So where does all this leave me...
I guess what I really want is a Nexus X, Google made, Verizon loving, stock UI, always updated hand set, with Motorola's industrial build quality, and hardware DRM for my precious Netflix... Let me know if anyone sees one laying around
Testing the accuracy of my device has been quite an interesting ride, and it has lead me to one conclusion: Breathalyzers are far from an ideal way of testing Blood Alcohol Content (BAC).
This must be why in real serious cases, Police Departments use blood or urine tests as they are directly measuring the concentration of alcohol in your blood.
Breathalyzers however, are a one-off test. Quite simply, they are measuring the amount of alcohol gas in your mouth. Thats an important distinction. There is the obvious factor that could throw off the test, that you could have liquid alcohol in your mouth. Some of this will be in gas form, and thus what you will be measuring is the concentration of that liquid. Which has absolutely ZERO to do with your BAC.
It's obvious, but let me really drive this point home: you can take a mouth full of Vodka, spit it out, even rinse your mouth, and still blow a deadly level on a Breathalyzer, mean while your BAC is still zero.
While this was apparent to me, I wasn't sure at first how much I would have to control for it. For instance, if I take a drink of beer immediately before testing, I knew that would skew the results, but how long between drinking and testing was long enough? One minute, five minutes, thirty minutes? In my first set of tests, this proved to be an overwhelmingly important factor that all but invalidated my results. However they were useful in that they taught me how to test in the future.
My second round of testing, I controlled for this by having everyone wait at least a minute between drinking and testing, and having everyone thoroughly rinse out their mouth with water immediately before testing. This clamped our values to much more linear and sensible readings as we went on. But we still had outliers throughout the night. And I discovered that:
Burps produce readings similar to drinking right before testing.
When you're drunk, you burp a lot without even thinking about it.
This was much more difficult to control for as the night went on... (also of note, data taking became increasing difficult toward the end of the night ;) )
The other thing I found, which may or may not seem intutive, is that Breathalyzers essentially need a male/female setting. Example: when my girlfriend was blowing an 18 (don't worry what that means, I'm just using it as a point of refrence), we calculated her BAC to be ~0.123%. (Also imperically verified her as: pretty drunk). Mean while, I blew a 19, and calculated my BAC to be ~0.034%. Even after controling for all of the skewing factors, her readings simply needed to be interpreted differently than mine or the other male subjects.
After discovering all of this I did some searching and found Breathalyzers are actually contested based on these exact grounds. They are bias against females, and there can be strongly mitigating factors during the test.
Oh well, I can still get rough approximations, and it's still been loads of fun
[cross-posted from: darkrockstudios.com]
Still waiting on Arduino to release their WiFi shield... So the drinking continues! Er... I mean the MQ3 project continues!
So I've put some time into looking for parts and methods for more making this handheld. Ordered some bits, and I'll update more on that once those parts come in. But the more immediate and all important challenge, is continuing to iterate on the over all implementation of the circuits and software that turn this into a Breathalyzer.
Accuracy is important if this project is going to be successful. There are limitations to the MQ3 sensor, but I want to get the most out of it. So after increasing the accuracy 4.5x last week, we tested again. (All these tests occur when my friends come over to watch The Walking Dead on Friday's). The first test we saw values ranging between 0 to 6. (Remember these values are just voltage readings from an Analog to Digital [A2D] converter provided on the Arduino). Now that wasn't good, over 10 beers, the values only increased 6 points. That's not nearly enough resolution in the signal to be useful. My second attempt after the 4.5x bump in resolution, produced values between 11 and 23. (Note the oddity there of nothing below 11. In my next post I'll go into my testing procedures, and why there are oddities in these readings, as well as almost certainly in commercial breathalyzers used by authorities.)
[warning: technical details ahead!]
The general idea here is that the MQ3 is essentially a variable resistor. When no alcohol is applied, it is entirely resistive, letting no electricity through. As you apply more and more alcohol gas to the sensor, it's resistance drops, letting larger and larger amounts of electricity through. That current is piped into one of the Arduino's A2D pins, where it converts it to a digital number that I can then use in my code.
The A2D takes a signal between 0V and xV and converts it to a number between 0 and 1023. Where xV is the Analog Reference Value: a voltage that the Arduino uses as the top end. By default 5V is used. There for if you put 5V into the A2D you get a reading of 1023. If you put in 2.5V, you get 512, and so on.
The problem with "resolution" as I've called it here, is that even with what our bodies consider to be very large amounts of alcohol (like deadly levels) they are still relatively low levels to the sensor. Example: after 10 beers, my BAC is ~0.104%, aka: pretty darn tipsy. But the resistor is still only letting through 0.029V out of 5V.
The solution? Shrink the range that the A2D is using for conversion. My first attempt at this used a built in function of the Arduino, to change the top end Analog Reference Voltage from 5V t0 1.1V. This is what gave me the roughly 4.5x improvement in resolution. But it still wasn't quite enough. So I began looking further into how to reduce the top end so the range has a closer fit to the values we are actually producing.
I found a feature of the Arduino that allows you to supply a voltage to a special pin (AREF), and what ever that voltage is, will be used as the Analog Reference Voltage by the A2Ds. So the next step was to find the correct voltage and reliably produce it!
I turned to voltage dividers.
Very simple circuits, you just do some math based on the input voltage and the target voltage to determine what resistors to use in it. And it will always output the desired voltage. I calculated from my previous tests that the desired top end, for maximum resolution, would be ~0.24V. Maybe a little more to pad for outliers. In practice however this ran into real world problems. And I ended up hooking in my 10kOhm potentiometer to find the lowest voltage I could use.
So far it looks like 0.5V is the lowest I can reliably use. Which is still pretty good. That will give me about half of the A2D value as usable range. Between 0 and 512. Which is a bit more than a 2x improvement on top of my first attempt.
With that determined, I can begin working out the actual BAC calculations based on my readings which should finally be of sufficient resolution.
Welp, JUST over a month, and I've got it pretty much completed. I have it all together, working, packaged up in it's enclosure, and mobile. (I'll do a proper video of it soon and post it)
(Reading from a Vodka bottle, not a person ;))
It's currently using an external 9V battery for power. Though I'd like to devise an internal battery solution, it's difficult. There is much less room in the enclosure than I expected once all the components and wiring were in.
(Lots of wires to route and cram in there.)
The BAC calculation is pretty simple currently. I took the data I compiled from my many tests over this past month, and calculated a magic value that I simply multiply the voltage reading against. There's certainly room for improvements. For instance, according to my data, it's not a perfectly linear relationship between the voltage readings and actual BACs, so the magic value should modestly scale up as the voltage increases, but I haven't found a good fit yet.
All things considered, my magic value method is producing surprisingly accurate readings, and if you just focus on the Summary I output (Sober, Buzzed, Drunk. Very Drunk, ect...) it's more than sufficient for what I was trying to accomplish with this project.
Also I got to have some fun with my Dremel in order to customize parts of my enclosure:
(35k RPM Dremel with solid carbide drill bits. Overkill? Yes. But sure was fun!)
In other quite serendipitous news! On this very day, Arduino has FINALLY announced the imminent release of their official Wireless module and 1.0 library which brings wondrous high level networking support This is what I've been waiting for to get back to work on my C3 Alarm Clock. Unfortunately it took so long that I'm just about to begin development on a fairly sizable game project. So C3 will be on the back burner. Hopefully I'll find time here and there to push it forward, but it certainly won't be a quick project.
I'll post more on C3 and the new game project as things progress. Anyway for today, it's just nice to have a working, finished project
Still waiting on Arduino to release their official WiFi shield for my C3 project. So my mind began to wounder. And I started an Android app to help post articles to www.talentopoly.com. But got stalled due to waiting on 3rd party API support. So my mind began to wounder.
About two weeks ago I was browsing www.sparkfun.com checking out some of their Sensors and day dreaming about fun things to do with them, and came across this, the $4 MQ-3 Alcohol Gas Sensor. I immediately straightened up in my seat and all my synapses that had been on vacation began firing again.
You see, all my hardware projects so far get to a point of some sort of moderate success, and then get promptly torn down to produce another project. Mainly because their components are expensive and I don't want to re-buy them all. But also because those projects weren't something I could easily show someone. With the project now swirling around in my head, it was something I could put together, and keep together. And it would have obviously and meaningful applications to anyone I showed it to.
The project of course, is a Breathalyzer.
And after two nights of putzing around with it, I got it hooked up to a simple circuit, along with a 10 segment LED bar, and have it working.
This past weekend I put it to the test but came up short. Even after 3 beers it was still not able to detect anything. By the end of the night after 10 beers, the highest reading I got was 5 (out of 1023). The effective range of the device it turns out, is MUCH smaller than the absolute range I was reading it in. So the next day I adjusted the AREF (Analog Reference) value to greatly shrink the range I was reading. This boosted the sensitivity 4.5x. It can now readily detect just a single beer on your breath.
In addition to this I added in continuous sampling of the base line readings, and factor them out in order to get more constant and reliable values. My ultimate goal here is to make this as accurate as is possible with the MQ-3 sensor (there are certainly some very real limitations to this sensor), and to make it hand held. With a side goal of making it awesome ;)
This week I ordered a 16x2 character LCD display to display the calculated BAC, and more 10 segment LED bars to increase the resolution of the bar graph. Once that is all tested and working, I want to package this up in an enclosure and make it handheld.
[cross-posted from: darkrockstudios.com]
Well for my first post I think I will keep this short, and tell you a bit about my self.
I am, among other things, an avid gamer (FPS,RTS,Puzzle/Adventure,Horror) and game programmer. I've made a few game engines, and a few games. I worked at a small, independent game company where we made a game for the Nintendo Wii. It's called Gravitronix and it's on WiiWare (the Wii's digital distrobution platform). For better or worse, we made the engine from scratch, and if nothing else, it was a massive learning experience.
Since then I have been working at monster.com doing web programming. That's about it as far as my professional life goes, but what I will be focusing on much more in these posts will be my personal projects. My personal interests center largely around game and graphics programming, but I also have a hobbiest's interest in cryptography and electronics. Both of which I intend to cover here.
I currently have two active projects which I will begin posting about soon. So if it sounds interesting to you, check back soon!
As I mentioned in a previous post, I'm beginning a new game project that I'm pretty excited about. Me and the artist I always work with have been mulling a new project for some months, and have been waiting for other things in our lives to clear a way for it to begin.
About a month ago we started to put things together. Setting up internal servers and services for tracking and coordinating the project. As well as putting together a slightly larger team. We've brought on a programmer that I've worked with before, and a new artist/game-designer who we've known for a few years. Effectively doubling our bandwidth in both assets and engineering.
After discovering that Unity 3D had changed their pricing model, offering a much cheaper non-pro version for Android and iOS, I began doing some research and have since selected it as the technology to base our project on.
This is exciting, because in all our previous projects, we had been starting from scratch, technology wise. Developing the engine tech and tool chain (if you could even call them that) as we developed the game. For even our simple games, this involved a huge time investment.
Now with our doubled bandwidth, and a proven technology base, we're all pretty excited about the possibilities.
Lots of stuff is still up in the air, we're still heavily in discussion about game ideas, and names for our team, and so on. Though some points are beginning to gel. We're settling on a few "Guiding Principles" that we can use to evaluate each game idea as they come up, but I'll talk more about those in a later post. Just as a little sneak peak, our game will likely focus on AI driven game-play. Having autonomous actors in the world that the player works with to accomplish game-play objectives.
That's all for now!
So a small diversion from my Arduino efforts today, and a focus on warm winter apparel.
I bought a Motorola Droid when it came out last year and haven't looked back to my LG 77C (the C is for crap) or what ever it's stupid model was.
But now that winter is firmly upon us, grinding us down 'till the last breath of hope and life escapes from our frigid, sun starved bodies, as nothing more then a fart in the arctic wind... I got to thinking:
"Boy my hands are cold, wish I could answer phone calls with out having to take my gloves off."
So I began testing a few materials around my house, trying to find something non-abrasive that would create some capacitance on the screen (since they are capacitive touch screens). Nothing worked, not well anyway, so I tried tinfoil which worked of course, but covered it with some thin plastic, as to protect the screen, and it worked!
So without further ado, I give you the DIY Capacitive Touch Glove, or as I like to call it, "The one glove to rule them all":
">Video: DIY Capacitive Touch Glove
I've been making good progress since receiving my IOIO. Got it up and running over USB, tested it all out, and then had to wait for my PICKit3 to upgrade it's firmware. Once it arrived, it took some time for me to grok it (I've never used a PIC programmer or anything like it before) but finally got the Firmware upgraded and got the IOIO talking to my phone over Bluetooth.
The next step was to recreate my sensor circuit and get back to where I was with the Arduino, and now I have it all soldered together in a more permanent fashion.
For now anyway, that pretty much wraps up the hardware side of things. I'll create an enclosure later, and maybe add a few more sensors (temperature, humidity, etc).
The other side of the coin, my Android app, has been coming along in between hardware work. I have it communicating with the sensor, and have a nice setup process to calibrate the sensor for any bed (measuring the dead load of the mattress). And I'm about 60% of the way toward using Google Calendar to set Alarms. Though Android's Calendar provider is rather... rudimentary. So I'm having to write a bit of a wrapper library in order to utilize it.
Anyway, that's it for now, I should have a working prototype very shortly!
Over the weekend, many weeks of research culminated in the first concrete progress on my new hardware project. First let me give a run down of the idea for this project.
The core idea originated from the fact that I'm a bit like Jekyll and Hyde. Except instead of a murderous monster living in my psyche, there is a sleep loving monster who shuts off my alarm clock instead of snoozing it. I know. It's ridiculous. I'm determined to be victorious, however, which brings us to my latest weapon in this battle:
It's an alarm clock that solves the problem using a pressure sensor. The sensor will be between my mattress and box spring, so it will "know" if I'm still in bed, and simply not allow me to turn an alarm off until I get out of bed and stay out. Though I will still be able to snooze alarms as usual.
Now in order to interface with this pressure sensor, I will of course be using my trusty Arduino. And given that, a whole world of possibilities open up! So in addition to the Arduino, I've also pilfered the Wifi board from my robot. So here is the short list of features the C[sup]3[/sup] will center around:
Time always accurate using NTP (Network Time Protocol), never set it again after losing power!
OLED touch screen for simple input, vibrant graphics, no back-lighting for good night time viewing.
Alarms scheduled using Google Calendar. Never have a work alarm go off on the weekends, vacations, or days off.
Pressure sensor to ensure alarms are not turned off while still in bed.
Current weather conditions displayed on screen.
WAV or MP3 playback for more pleasant alarm types.
I'm also investigating a speech synthesization chip (SpeakJet) to allow it to talk And obviously there are many more possibilities having an internet connected alarm clock that I will explore once the base features are implemented.
So stay tuned for more updates as I progress on this!
So it's been a bit since my last update, and that's because things have stalled.
The bad news is I've hit a bit of a wall in terms of long term stability with my existing WiFi module. I've addressed issue after issue gradually improving stability of the WiFi stack and my own code. But in the end I just can't get it to stay alive long enough. Even a few days of stability isn't good enough for an Alarm Clock that I'd be relying on to get me to work on time. I could pursue the issues further into the WiFi stack, but it would take a fairly big time investment. Since the stack and hardware are no longer supported I'd be investing all of this time into what is essentially dead hardware. If I ever wanted to upgrade or make another one of these clocks, all of this time would be wasted since I couldn't buy another one of these WiFi modules.
The good news however is there is a ray of hope! Truly excellent news out of Maker fair: Arduino (the company) announced several new Arduino's (the micro-controller) which is great and all, but most excellently, they announced an official Arduino WiFi shield! The library and hardware will be officially supported going forward! They are due to release some time in October, so my project is stalled until I can get my hands on one of these, but this is truly great news for all of my projects which usually have wireless connectivity at their heart
Good news everyone! I've reached prototype stage! And I've got a video to prove it!
And with that I set to some real world testing.
Night 1: The alarm went off as expected! I snoozed it (as I am want to do). But 30 seconds later it went off again! I had left in my hard coded debugging value of 30 seconds for the snooze time :/ Realizing this in my half awake state, I got out of bed in order to turn the alarm off... but nothing happened... with the alarm still blaring out at full volume, I inspected the app closer, and noticed the pressure value was not updating. I close and reopened the app in an effort to reconnect to the sensor, but to no avail. I ended up having to go under my bed and power cycle the IOIO.
Debugging first thing in the morning is not my idea of fun.
Night 2: In preparation for night 2, I decided to connect to the IOIO over USB to ensure the connection remain steady for the whole night. But 8am come and went with no alarm. I didn't have time to collect any data on what went wrong because I was in quite a rush when I finally did get up.
I had a nagging suspicion however that the volume may have been at least partly to blame. So I modified the app to hard set the volume to max every time it went off, and I improved some of the data smoothing related to the pressure sensor to avoid false positives for getting out of bed.
I also discovered that, with the current firmware on the IOIO, it won't provide power to the phone over USB, so that's not really an option at the moment.
Night 3: Connected over Bluetooth again for this night of testing (due to the charging issue over USB), and added in some more debug logging. This time the Alarm went off at full volume, exactly when it should, and snoozing worked beautifully. But the Bluetooth connection was lost again. I got up and plugged my phone into my computer and dumped the logs. They don't go back far enough to see the disconnect, but I got some data out of it anyway.
I've modified the app now so that when the connection is lost, it dumps the Log to disk right then and there, so Night 4 should produce some more definitive results as to whats going on.
Onward and upward I say!
The next real step forward was to begin working on the networking and time keeping. But those steps were the beginning of what is to become a real software project. Still small to medium sized compared to PC projects. But it will have a level of complexity that Ardunio projects don't usually achieve. What this means is the Arduino IDE would be wholly unsuited for developing it. I ran into this a bit with the Robot project. Towards the end of development as some complexity emerged with the socket communications, it got fairly difficult to manage in the Ardunio IDE.
My solution was to fall back to my trusty C++ IDE Code::Blocks.
I love this IDE, so light weight, cross-platform, and infinitely configurable. C::B has some high level support for AVR projects (that's the architecture of the micro-controller that the Arduino uses), but it's really a thin veneer. All of the guts, GCC-AVR and others, must be setup on your own.
I was following spotty tutorials written for much older versions of every piece of software in the chain. I had to extract AVR-libc and the Arduino Core lib from the Arduino IDE, get headers, do all sorts of fun stuff that Arduino clearly never intended for you to do. But in the end, I got it all compiling, burning, and running from within C::B. I even got C::B auto-resetting the hardware prior to burning! (Something none of the tutorials managed to do!)
I'll tell you, when I got my own code without any of the Arduino auto-magical trickery running on that chip:
// Insert celebration here
That was a gooooood day.
So with everything ready to go, all set for serious software development, I began looking into the networking. Dusted off my old networking WiFi shield (Arduino speak for daughter board) and began loading up all the libraries. I got a basic web server test running, and then went on to compile in more feature in the library. And all of a sudden, cla-thunk! My program wouldn't upload. Scrolled through the build log and found "Memory out of range". Crap... opened up the /bin directory of my project and saw the .elf file's size at 33KiB. The Arduino only has 32KiB of program memory...
After playing with stripping & size optimization options, and weighing if I really needed those library features that had pushed me over the limit. I concluded that I needed a new micro-controller with more memory. Luckily Arduino's come in several flavors! After a quick look-see, I decided on the new Arduino Mega 2560. It's based off of the newest Arduino, the Uno, has 8 times the program memory, and MANY more I/O pins. But other than that, it's identical to my current one. Which means it can be a slot in replacement, and I don't have to change any of my plans
So I'm waiting on that to be delivered before I can continue.
LLOONNGG week of packing, moving, and unpacking. Still not done unpacking. Probably won't be fully unpacked by the time we move again Oh well.
ANYWAY! Onward and upward!
[sub][ I really like my little Paint.NET logo, so thought I'd throw it in again ;) ][/sub]
So since my last post I began working on NTP (Network Time Protocol) synchronization. As with EVERY part of the project so far, there were a lot of snags along the way, but I got it there. It's a truly crippling problem having the maker of my WiFi chip defunct. It leads to all sorts of problems with documentation and community support. But "Damn the torpedoes!" I say! FORWARD!
I had to implement the NTP protocol on my end. I simplified it quite a bit by not taking advantage of many features [40 bytes of hard coded zeros in the middle of my message ;) ], so it was actually pretty easy. Sending and receiving the UDP packets, however, was a bear because of the poor documentation for my WiFi chip. Took quite a bit of fiddling, but I got it working.
Then I found the great little Time library for Arduino that allows for easy manipulation of time and time keeping, and set that up to use my new NTP code for synchronization.
Putting it all together, here you can see the current boot sequence for the C3:
With this working, I set it up for a soak test. I wanted to see how much time the Arduino would lose after it synchronized only once, that way I could figure out how often I would have to re-sync with the NTP servers. After 24 hours I had lost just under a minute, and after 48 hours I had lost just about 2 minutes, which looks pretty good because it doesn't seem to be accelerating. It's a pretty minimal, and a pretty linear loss. I could probably sync with NTP as little as once a day, but to be safe I'll probably start by syncing every 12 hours.
So that's all good! But during the soak tests I did discover yet another problem with my WiFi software stack. It doesn't automatically reconnect when it's connection to the WiFi AP is dropped. It's a fairly minor problem in the software stack that I already found someone's patch for. My version of the stack is already pretty customized however.
So my next goal will be to setup auto-syncing at 12 hour intervals. Merge the WiFi auto-reconnect patch with my customized stack. And finally further customize the stack in preparation for working along side the display shield I will eventually be integrating. (I need to move some pins around in the code)
With all of that I should have a rock solid NTP clock, which of course is the necessary basis for everything going forward. After that I can focus on Google Calendar integration and other "fancy features" like audio output and a display
So I got my brandy new Arduino Mega 2560 in the mail. It has 256KiB of program memory (8x the memory of a standard Arduino!)
As I mentioned in my last post, the standard Arduino only has 32KiB of program memory, and with all of the networking features I want compiled into the library I'm using, I was already at 33KiB. But now with a spacious 256KiB (What will I ever do with it all!) I can add in features until my heart's content! (DNS and DHCP oh my!) Other than the extra memory (and extra I/O pins) It is identical to the regular Arduinos. Or so I thought... (cue the misery.)
Getting a blinking LED sketch (Arduino speak for program) running on it from the Arduino IDE was easy enough. But replicating it inside my Code::Blocks setup was not so easy. It took further modification of my command line scripts for which there was little to no documentation to base it off of. After lots of groping around in the dark, trial and error, and some guess work, I got it there. Though the auto-reset was not working, so I have to time a physical reset of the board with the compile button in the IDE to get the programs to upload. *annoying*. This took a few hours... but it gets worse.
Then began the real pain. You see, the trouble starts with the fact that the wonderful WiFi board that I use (the WiShield, made by AsyncLabs) is no longer in production. In fact, in March of this year, AsyncLabs shuttered their little studio completely. Which is a real bummer because they are the ONLY mature, drop-in WiFi solution for Arduino
With AsyncLabs out of the picture, development on its library and support in its forums has all but ceased. With the Mega2560 being a relatively new board, its fair to say that support will never be added for it in the WiShield's code. Now you might ask, but Adam! You said the Mega was pretty much identical to other Arduinos! Why would support need to be added at all! And it's because it's NOT identical. There is a small difference that turned out to be vitally important.
You see the Arduino's are based on an AVR type chip manufactured by Atmel. Atmel makes a variety of these chips under the ATmega line.
These ATmega chips provide a nice little piece of hardware/software functionality called SPI or Serial Protocol Interface. I won't go into the details, but it's critical to the functioning of the WiShield.
This is where the problem lies. Arduino's based on the ATmega168 or the ATmega328, have their SPI pins on 11, 12, 13.
But Arduino's based on the ATmega1280 or the ATmega2560, have their SPI pins on 51, 52, 53.
This was a deep rabbit hole the wasn't helped by my ignorance of underlying hardware. Most Ardunio hobbyists never need to get this deep into the micro-controller at the heart of the Arduino, so I initially wasn't trying to learn all about it, I was just trying to solve the problem. And I wasted a *lot* of hours going down this vein. After two days of researching the problem, banging my head against a wall, investigating other WiFi chips and even other micro-controllers entirely, the project was in real danger. But I finally had a break through. I pieced together a solution from many different forum posts and a deeper understanding of the hardware and the problem at large.
It ended up being both a hardware and a software fix. And I had to mutilate my beloved WiFi board a little
This was not a fun excursion. But I hope it clears the the path for some smoother sailing. Next I'm going to try to make the Arduino keep time using NTP (Network Time Protocol) for synchronization. And after that work on pulling events from a Google Calendar. So stay tuned, and I hope to keep these posts shorter
I had an unexpected break through on my C3 project! A couple nights ago, I had some spare time, and had been thinking about the pressure sensor for a long time. The problem with it is, there is a circle with a radius of just 4mm, and in order to get good readings, the force must be applied to the center, not the edges. This gives me only about 2mm's in radius to apply force in. Since this will be under my mattress where things can be jostled or move around, that's a pretty narrow margin of error.
With this in mind, I came up with an idea for a "puck" and threw it together in Google SketchUp:
I was blown away by how easy SketchUp was, I learned the program and made this model all in less than an hour. What you are looking at here, on the right is the base of the puck. The sensor will sit at the bottom of the trench and be held in place by it's constrained neck. And the left is the top, that will insert into the trench, and the notch will hold it perfectly in place, while the nubbin will be the only thing applying pressure, and it will be held perfectly on the 2mm pad.
The ease of all of this, really motivated me, and the next night I got my self over to my local hacker space, sprout & co. and printed this baby up using their fantastic Thing-o-matic:
So I brought it home, marveled at how this thing that had been in my brain just two nights before, was now sitting in my hand, and set to programming my Arduino. Came up with a voltage divider so I could get good values out of it, and calibrated it so I could convert the values to readings in pounds. Then I set it up to record a full night of sleep, and dump the contents to a text file on this little net book.
And it functioned perfectly!
You can even see when I got out of bed near the beginning there!
Despite these resounding successes, I hit the same wall I had been at for a while now. The standard Arduino, as well as the available WiFi shields, really weren't up to the scale of the project I had in mind. And the new Arduino Due and the official Arduino WiFi shield which might solve my problems, are seemingly never to be released.
After a day or two of mulling this issue over in my head, I began perusing SparkFun as I am want to do. And I came across the IOIO which I have seen before, but this time it sparked (see what I did there?) a sea change in how I was thinking about this project! So many of the things I wanted the project to do (Like WiFi, NTP, Google Cal sync, Text-to-Speech) are exceedingly difficult for little 8bit Arduino's to do. And other things I wanted the project to do (interfacing with a variety of hardware sensors) are difficult for Android phones to do.
But my change in thinking was to treat my Micro-controller merely as a "Sensors Package". Which a custom Alarm Clock app on my phone will communicate with in order to be smarter than it could be on it's own.
So that's what I'm doing! I'll hook my sensors into my IOIO (pronounced yo-yo) which will connect to my phone via Bluetooth. And my Alarm App which I will make, will utilize the sensor data to do everything I had hoped it work! And more!
As I stated in my last post, I began some actual work on this project over the weekend.
What's some times not appreciable, is the amount of time it takes just to get started on something like this. Finding all my Arduino parts and pieces, installing the software, figuring out all the little quirks again (It's been more than 6 months since I finished the robot project).
Finally being setup again for Arduino development, I set to soldering together a little voltage regulator for my bread board. It would allow me to put in anywhere between 3V and 36V and get a nice clean 5V signal out. This way I could independently power my breadboard without extra wires from the Arduino.
Next I needed to test my pressure sensor, to figure out how it works and how best to use it. I started by building a little RC (resistor capacitor) circuit as described in the sensor's user manual. But quickly realized this wasn't necessary with the Arduino, Just using one resistor and an Analog pin I could read it directly. Problem was, I was getting these highly variable values. In fact, when graphed over time, they looked quite a bit like the charge and release cycle of a capacitor.
This puzzled me of course because all I had in the circuit was a resistor and the sensor. After more fiddling and frustration, I removed my nifty bread board power supply and hooked it up directly to my Arduino's 5V pin, and instantly I got stable values. Good for my level of frustration. Sad because I really liked my little bread board power supply. Not sure what I screwed up when soldering it together...
Anyway, I happily played around with my sensor, creating functions to produce readings in lbs rather than voltage and such. It was fun and cleared the way for what was, in my mind, one of the biggest question marks for the whole project.