Monday, April 25, 2011
Attachment of Showcase Handout
Monday, April 18, 2011
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!
Friday, April 15, 2011
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.
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.
Thursday, April 14, 2011
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.
Today I was brainstorming and thought "maybe cyclical trig functions would help out", so I looked up the unit circle:
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).
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).
Wednesday, April 13, 2011
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!)
Tuesday, April 12, 2011
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!
Sunday, April 10, 2011
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. :) |
Saturday, April 9, 2011
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.
Friday, April 8, 2011
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...
Wednesday, April 6, 2011
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.
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.
Tuesday, April 5, 2011
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.
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. ;-)
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. ;-)
Monday, April 4, 2011
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...
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)
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)
Subscribe to:
Posts (Atom)