Videos!

So after the semester ended, I didn't have as much time as I thought before I left for my internship.  Then when I got back, school started pretty quick.  So I finally had some time to upload my videos from demo night.  Enjoy!

Attachment of Showcase Handout

Here is a PDF copy of my Showcase Handout (click to see full size image).  I've turned in my last assignment for my other classes today, so over the next week I hope to add a few more posts regarding shopping lists, code snippets, and other miscellaneous tidbits.  Stay tuned.

Completed!

I have finished my Droid.  The software is complete.  The body design is complete and built.  All of his hardware is finished (and it all fits inside... I was worried for a bit :-D).  I'll post follow up pictures, video, and information after the presentation on Thursday as a sort of after-action review.  See everyone on Thursday!

New drive values - implemented!

So my theory worked, and now I have new CONTINOUS drive values based on my previous post.  I have put together a little demo video showing the output values as I move the drive stick around.  Each tick, two sets of numbers are printed.  The first row is the data being sent from the controller... the only two of importance for this video are the first two values, they are the Y and X values (respectively).  I put Y first because that determines forward/backward, while the X determines left/right.  The second row consists of the sine/cosine values based on the stick angle.  The first one is the left wheel, the second is the right.  As these stick values change, the droid calculates the angle they create and assigns sine and cosine values to them, which I'll work out to be percentages of speed.  When both values are equal, they are only at 0.71, so I have one last thing to do to scale these values so that there is always a 1.00 (basically I'll take the largest magnitude of the two and divide them both by that).  Again, these are only percentages, the final speed will be determined by how far the stick is from center multiplied by these percentage values.

In my video, I start out pushing the stick to the right, then slowly circle counterclockwise slowly about 1.25 times around.  If you follow my rotated unit circle from my previous post (and you have a good idea of the decimal values of fractions shown) you can see that this will work just fine.

(Currently my video is not uploading right... I'll take a look tonight and fix it then.)

UPDATE:  So the Jing video I recorded is a .swf file, and for some reason it isn't letting me upload it.  Suffice to say, I won't be worrying about the video... but believe me, it was good.  :-)  No it wasn't, it was a bunch of numbers flying up a screen.  I'm really tired... only thing left to do is paint him and he's done done.

Drive values solved... hooray trigonometry!

So I've been trying to decide how to determine the values to set the drive motors from the X-Y axis values that I'm sending from the controller.  When the stick is just moving in the Y direction, I want both wheels to go the same speed (forward or backward), when the stick is just moving in the X direction, I want both wheels to go the same speed, but in opposite directions (forward/backward or backward/forward), and when the stick is in some combination of the two axes, I want the values to interpolate between these extremes. 

My initial calculations caused some deadspots in the stick values where the droid wasn't moving in the direction that I was expecting (or it wasn't moving at all).  So I thought instead of having discrete cases to do certain things with the values, if I could find continous functions that I could feed in these inputs that would output the values I wanted, I wouldn't have to have a bunch of if-else statements.  So I set out to find these functions.

Today I was brainstorming and thought "maybe cyclical trig functions would help out", so I looked up the unit circle:

I got this picture from:
http://www.mathpeer.com/images/trig/unit_circle.gif

 






















Well, this isn't exactly helpful... I mean, full Y and no X should be both wheels forward... here, it would be full right, no left.  Then I put my head on my chin and thought some more... and while my head was tilted on its side, I finally got it... what if:


... I turned the unit circle a little bit (about 45 degrees).  Now, full Y and no X would give me the same value for both wheels (with sine and cosine).  What about my other conditions?  Well, full left X and no Y will give two values of equal magnitude, but opposite direction... and full right X and no Y gives the opposite effect... AND full backward Y and no X gives the same values, but both negative.  EUREKA!

So, my new process will be:

1) Input X and Y axis values from the controller (from 0 to 255)
2) Map these values so there are negative and positive values (ie: -200 to 200)
   (this will allow me to determine which quadrant of my new unit circle the stick is in)
3) Determine the angle from one of the axes using the X-Y values and arctangent (arctan(X/Y) = angle)
4) Assign cosine of this angle to one wheel, and sine of this angle to the other
   (these sine/cosine values will now act as percentages of SPEED, determined by how far from center the stick is [calculating the length of the hypotenuse, since X and Y act as the other two sides])
5) Multiply these assigned percentages to the speed and set the results to the wheels

Voila!  No if-else trees, just short pre-process calculations then set values and go.

In theory... I've only come up with these just now during my Thursday classes.  I'll test these ideas tomorrow and hopefully, that will be the end of the drive tweaking (and indeed, the end of the software development entirely).

Construction 99% Completed - Phase IV

The legs are finished... complete with foot shells!  All that's left now is to use my rough skin to make the final skin, paint everything, and finish the final programming (adding a few more button functions to play 16 sounds).  I can see the light at the end of the tunnel... I just might faint!!! (Or maybe that's just my body telling me to get to sleep... this is the fifth night out of the last seven that I'm up past 1am... but I'm loving every minute of it!)

Magic legs - Phase III

R2D2's got magic legs!  I finally decided on how to attach the legs to the main body... with removable pins through a support beam.  I've also decided at this stage that (unless there are any complaints from Professor McDaniel) this will be the last picture I post until the big reveal at the expo.  I'll still post updates, but I'm really proud of my droid and I want his final appearance to be a surprise.  See you guys on the 21st!

Late night body building - Phase II

I was going to post this last night, but it was 2:30am.  I've built the remainder of the main body in removable segments.  Now what's left is the shell and legs.  Also this afternoon I finished redoing the front caster.  It looks so much better.  Lots of pictures here:



Droid all in pieces (except the lowest level because

I had all the wires run through it)



Speaker placed



Arch with the XBee unit placed



Third level with the dome motor placed





Dome placed



New front caster with shell (no wheel binding this time!)



Side view of the new hotness... I mean caster. :)

 



Front wheel woes

So after mounting the front caster last night, I thought that it might be a little too far out front, but I decided to go with it.  I spent a couple hours putting the shell around the caster and framing it up, but now it REALLY looks too far out... so I might be dismantling that soon.  I'll wait until after I build him up more before deciding...

Body construction - Phase I

I have begun construction on the body.  I'm taking a triple decked approach, each level will be removable so that I can get to any of the parts.  So far, I have built the lowest level with the chassis and battery packs, mounted the front caster, and started the second level (which is where the arduino, shields, and hopefully the speaker will be held).  The third level will have the dome motor mounted to it.  I'll post more as I build it.

Dome construction

I'm at the point where the software is almost done, and the hardware is just about done as well.  So, in order to do fine tuning, I really need to build the body next.  My daughter was sick today, so I decided to start with the dome (because I required much less workspace for this). 

I'd been concerned until yesterday about how I was going handle this.  But yesterday I had a brainstorm... styrofoam craft balls!  I bought a 5" ball and tried wrapping it with aluminum foil.  This was giving mixed results because of the bumpiness of the ball.  So I decided to make a hemisphere out of posterboard to act as a layer between foil and ball which allowed for much smoother results.

I took another piece of foil and mixed some blue-purple paint to paint the wedges of the dome.  Now I just need to build the main body to decide whether to use the hollow shell by itself or if I can get away with leaving the foam ball in...

Sound work continued - Motor shield integration

Be prepared... long post is loooooooooooooooooooooooooong...

Today was scary.  Really scary.  Really REALLY scary.  So scary, that had I screwed something up while doing what I was doing today... I would have had no droid for my final project.  But as Seth Rogan said in the movie Paul, "Sometimes you just gotta roll the dice."  So I rolled.  And after a couple of hours, I breathed a sigh of relief.  My motor shield still works.  My wave shield works.  And most importantly, they work TOGETHER.  Let me share with you what I did today.

First, it had been a while since I loaded up the wave shield, so I brought that out and put the new R2D2 files on it.  Works like a charm.  Next, I needed to be able to access each file directly instead of consecutively, so I grabbed some of the sample code from the library and there it was.  Piece of cake.  Then, I said to myself, "Self... let's stack these things."  So I did.  I stacked the wave shield on top of my motor shield (which is on top of my arduino), and I copied in just the part of the setup code that would read the available files on the SD card (for now). 

As expected (because I've been lucky with a bunch of things on the project so far, so I figured that I would run out about now) the files could not be read.  I was prepared for this, thanks to Mike's truth table he sent earlier this semester.  So I went to work un-soldering 4 of the 5 jumpers from pins 2-5.  While I was at it, I decided to add some headers so I could test back and forth until I got the right combination right.  The prototyping jumpers are a little less permanent, but that will be ok for the final project.  After I put the headers in, I put the jumpers in the way they were first to test out the shield (by itself again).  Success.  Now came the first hard part... figuring out how to modify which pins the wave shield is looking to use for the DAC control. 

Luckily, there wasn't much code in the WaveHC library to go through, so in the WavePinDefs.h file, I found four sets of declarations like this (this is what my code looks like now, I put the original lines in comments at the end):

     // use arduino pins 2, 3, 4, 5 for DAC                             
     // pin 2 is DAC chip select                                        
     /** Data direction register for DAC chip select. */                
     #define MCP_DAC_CS_DDR PIN19_DDRREG // originally PIN2_DDRREG      
     /** Port register for DAC chip select. */                          
     #define MCP_DAC_CS_PORT PIN19_PORTREG // originally PIN2_PORTREG   
     /** Port bit number for DAC chip select. */                        
     #define MCP_DAC_CS_BIT PIN19_BITNUM // originally PIN2_BITNUM      

So I followed the definitions of PINx_DDRREG back to ArduinoPins.h, and saw a bunch more definitions, I believe the were some 70 pin definitions for each grouping (probably for Mega support).  So I said "let's give it a whirl and reset these definitions to the analog pins (referenced as digital pins 14-19)."  So I did that and put the jumper wires in the proper places.  Success, my wave shield was now running off the digital pins 16-19, leaving pins 2-5 available for the motor shield.  So I tried the two shields together again.  Fail.  What NOW?

I went back to the truth table (thanks again Mike!) and there were still some pin interactions that I needed to resolve.  But now I had no idea how, because the motor shield PCB is made in this way... I didn't add jumper wires like the wave shield.  So I did a search for wave and motor shield and came across this forum thread (http://www.adafruit.com/forums/viewtopic.php?f=31&t=8066#p63795).  I took a double take.  Cut the what?  Traces?  Never done that before... let's google it! (http://www.diystompboxes.com/smfforum/index.php?topic=81879.0;prev_next=next)  So at this juncture, I was floored.  Take my perfectly fine working on its own motor shield, solder some new wires and TAKE AN X-ACTO KNIFE TO THE BOARD??  ARE YOU NUTS??  I looked again, and there really was no other way around it... the SD card needs pins 11, 12, and 13 (from its documentation), so if I want these two to work together, gonna have to get in there.  This is where the dice rolling came in.  Soldering mistakes I can fix, but scraping out the traces is kinda permanent.  I highly doubted that I could've ordered a new motor shield in time, but I pretty much had no other option.  I followed the instructions by poster 'jonharrell' and soldered in new wires and scraped out the traces for the other two pins.  His pictures were life-saving with this.  I am (hopefully only) sacrificing servo capabilities to have 4 DC motors and wave shield functionality.

Well, lady luck was once again with me after all and I succeeded.  Now I have control of at least the two drive motors (haven't rigged up the third yet to test) and I can trigger a sound to be played with any of the controller buttons.  ::phew::  Now the only concern I have is whether the sounds will still be audible from inside the droid's body as well as heard over the motors (even on the other side of the shield where I could specify a higher frequency, the motors were still loud), but that's completely out of my hands unless I find a much louder speaker...

But that'll have to wait until everything else is finished if I have some time left.

Starting sound work

So I thought I'd take a short break from working the motor part of my project and do a little bit with the sound.  I got 161 R2D2 sound bytes from my older brother today, so I wanted to make sure that the speaker I had would work.  I cut the plug off an old pair of headphones and soldered some wires to it. 

Fortunately, the wiki page description of which parts were which was accurate and now the speaker works with my wave shield.  I've selected 16 sound bytes for the SD card (because I'm going to use combinations of the 4 top buttons to index these).

Next step is to make sure the wave shield works on top of the motor shield...

Wirelessly remote controlled Droid demo

Here we go, the long awaited demo of my droid!  I have some tuning to do with the controls of the motors (such as how much power to give to which wheels if the stick is full forward but partially turning left).  But after that, the dome will be easy (it's just one value, forward or backward) and the sounds will be controlled by digital button signals.  After that, it'll finally be time to begin work on the shell for the final showcase.  Enjoy!

(The file was too large, at 250MB, and I ran out of time this morning and didn't have time to compress it... I'll try to do that later this evening and will update this post with the smaller video... please stand by :-) )

And here it is!!

How I'm juggling my sketch uploads

So unfortunately, when you have multiple sketch windows open in the same instance of the program, all windows are linked - meaning when you change the board type and serial port in one window, those values change in the other window.  That being said, I just tried Professor McDaniel's suggestion of running a second instance (starting the program a second time while one is already open) and the settings stick... which is some help.
The other part I have to contend with is to upload sketches to the Fio, one of the manual pages somewhere said to not have the XBee attached when uploading sketches... so everytime I go to upload, I have to remove the XBee (don't want to fry it so close to deadline).  So I have my controller setup on the right side of my laptop and the arduino/motor setup on the left side... and each respective sketch is on the matching side of my laptop screen.  Phew... get all that?  Good.

Wireless communication - Part Deux

Hooray!!  After several hours of troubleshooting, I have finally figured out (I think) the last issue for communication!  In my previous post, I mentioned that when I sent more than one byte across the connection, that the later bytes were garbling.  Well, I decided to ignore it and move on to work with my PS2 controller and how it communicates.  I was sending one value just fine, but when I attempted to send a second one, I was perpetually getting bogus values for every byte after the first.  When I should have been getting (128, 128), I was getting (128, 192), and for kicks I tried (128, 128, 128, 128) and got (128, 192, 192, 192).  Interestingly, 192 is 64 bigger than 128, so I thought for some reason that subsequent bytes were getting bit-shifted somehow, but I couldn't figure it out.

I finally stumbled upon a post about other people using the NewSoftSerial library for Arduino (http://arduiniana.org/libraries/NewSoftSerial/), and what I found was that the 57600 baud rate that some of the XBee tutorials told me to use is on the absolute edge of capability of this NewSoftSerial library.  So I used X-CTU to reconfigure the XBees to communicate at 19200, and changed all serial calls in my sketches to use 19200, and...

VOILA!!!

Appropriate value passing is now occuring.  Likely, if I really wanted to, I could probably upload sketches wirelessly now... but I'm fine with my current way... I've gotten used to it.

What is that?  I didn't describe to you my current way of uploading sketches?  Ok, since you asked so nicely... I'll tell you in my next post.  Just need to snap some photos.  ;-)

Wireless communication - Part I

After hours of reading multiple setup guides, I finally have achieved wireless communication between my controller and my laptop via two XBee radios!  It seems as if I was doing it right everytime I tried a new tutorial, but something wasn't working.  I found out that two things were wrong:  1) Some idiot mounted the XBee into the Arduino Fio incorrectly and had it in backwards... >.>   and 2) I was initially trying to setup the computer XBee as the sender and the arduino XBee as the receiver, when in actuality my project is going to require the opposite.

The one page that best sums up the necessary steps is this page from AdaFruit (the most important part is getting the X-CTU software to allow you to modify the settings on the radio(s)):

http://www.ladyada.net/make/xbee/point2point.html

Except that since I have an Arduino Fio, I did not need to rig a connection to the board... that's already been done for me.  I was also having some issues with the sketch sample at the bottom of the page (sometimes when I tried to transmit more than one character at a time it would garble them i.e. if I sent "1", I got back "1", but if I sent "123", I got back "12c").  So I went for broke and just re-uploaded my PS2 controller sketch, mounted the transmitting XBee to the Fio, connected up the serial port on my laptop via FTDI cable, and hit reset on the Fio.  BINGO!  Serial communication achieved.  Next up, modifying my motor demo sketch to look for serial input and hope my luck can continue...

Droid Mark II body sketch

Ok, so I've been trying to post my blog entries from my Droid phone so that I could just snap the pictures with the phone and upload them directly.  It also let me work without turning on a computer.  However, earlier today, I wrote a very nice post about the demise of my prototype Mark I droid... here is what I can remember from that post:

My proof of concept droid crashed during the demo last week and the supports holding the battery pack in place fell off.  I was sad for a moment (nobody wants to see their creations crash and burn like that), but I knew in advance that I would need to be rebuilding the body anyway, so I was good.

From that failed demo, I learned some very important things: 1) put the heavy battery pack near the bottom and as far forward as possible, 2) get a lower profile caster for the front wheel to reduce the amount of backwards tilt, and 3) never underestimate the power of coincidence.

Funnily enough, the power of coincidence ran high this week when I learned that my father, whilst trudging around at MegaCon, had purchased an old land line phone... in the shape of R2D2.  As I was looking at it, I quickly realized that it was almost exactly the size that I had envisioned for my droid.  So I quickly took up a ruler and pencil to measure all the vital tidbits of info that I could... and I also sketched out some specific layout... because pictures are 2D, it's possible I could have gotten my proportions all wrong going off the high res images from the interwebs.  Now, I'm 99% confident about my information!

Rest in pieces, Mark I droid... your sacrifice will not be in vain,

Mark I droid
March 26th, 2011 - March 28th, 2011

(Click on the picture above to get the full size image if you wish to read my chicken scratches)

Proof of concept - body design

Now that I have the majority of the droid parts, I wanted to make sure it would all go together as I imagined it in my head.  The only thing I was lacking was a front wheel caster.  I searched the web and couldn't find anything small enough (at least, not one in my price range), so I made one out of a metal coat hanger.  The rest of the body frame is made out of balsa wood because I needed it to be as light as possible, yet have good potential for sturdiness (I used to make balsa wood structures that held hundreds of pounds of weight for Odyssey of the Mind in middle school).

Now I know what proportions to fix for the final design and what else I need to make room for.  In this build, the gearbox is on the bottom level, my arduino and motor shield are on the 2nd level, the motor shield power box is on the 3rd level, and the arduino power in taped on top.  I still need to make room for the wave shield, a speaker, and a motor (or stepper) to rotate the dome on top.

Rebuilt chassis - successful modification

As I was testing out the chassis, I realized that the way the instructions told me to build it, the wheels would not be independent from each other.  There's a third hex axel that runs through the whole assembly (see the red arrow), and the gear boxes are bolted in place to both ends.  So I had two choices: a) rebuild the chassis using the low speed option (4 times slower than the normal mode), or b) attempt to cut this axel in half.  The pieces couldn't possibly fall out, and with the hex bolts in place on both sides, they should still function like normal... they just won't affect the other side.  I opted to cut the axel in half... and it worked!  Now both wheels are independent from each other.

Hooray engineering!!!

Minor hiccup - suspend disbelief

I've completed the chassis, and have realized that I haven't been accounting for the actual shape of a proper droid until now.  The body tilt when on three wheels keeps the wheels away from the body, which means to be accurate I would need to run belts down the legs to turn the wheels instead of just connecting them to the axels.  I may have to fudge this and attempt the more complicated drive system for a future revision.

(R2D2 picture from Google search, link here:)
http://27.media.tumblr.com/tumblr_l415r2rV0W1qc7oabo1_400.jpg

More parts - chassis

I went to my local hobby shop to ask about wheels, since I've never built something like this.  I talked with him about how you should properly attach wheels to a motor, so he pointed me in the direction of these gear boxes.  I know I need two independent wheels, so this twin motor gearbox seemed to be the way to go.  The gentleman who helped me also said that he thought this would work, and would give me something sturdy to support the droid.

Making the controller work (part 2)

It took some trial and error with Ardiuno pins, but I finally got my controller to work with Bill Porter's demo sketch.  After making sure everything was working, I prototyped a mounting board to attach my Arduino Fio to the controller, as well as a port for connecting the FTDI cable prior to getting the XBees working.

Making the controller work

So I set to work hacking the controller.  As I was researching, I came across a website of someone who has already written an Arduino library for PS2 controllers!!  That takes care of weeks of researching and trial and error programming. 

Bill Porter's website is well documented with instructions on how to get up and running.  He also actively reads his comment section to help other people troubleshoot their controller.

http://www.billporter.info/playstation-2-controller-arduino-library-v1-0/

Finding the right components (part 3)

I also needed a cheap controller to hack.  I did some searching online and saw that PlayStation 2 controllers have been successfully hacked, so I bought a $10 PS2 controller.

Finding the right components (part 2)

I want my droid to be controlled wirelessly, so I needed to pick up some XBee modules for communication.  Also, in order to interface prior to getting the wireless stuff going, I needed to get a USB to FTDI cable and an XBee adapter kit from Adafruit.

Finding the right components (part 1)

The first thing I needed to figure out was what parts to get.  I knew I'd need another arduino, so the search began.  I came across this Arduino Fio, which has a built in socket for an XBee module.

Pictures to come... my camera is on the fritz...

Muahahaaaahaaaaa!!!!!!

Phase One of my evil plan has been completed!  I have convinced my professor to allow me to build a droid as an 'assignment'... I will chronicle this endeavor here so that when I have finally taken over the world, I'll be able to show everyone how I did it!!!  Nothing can stop me now!!!