Archive

Archive for the ‘Project Description’ Category

Life Update and Checkerbot Follow Up

Wow, it’s been altogether too long since I’ve posted.  Fortunately, and this is important, I’ve been able to spend a lot of great, quality time with my family.  We recently had a great time at the Oregon Beach and at the A.C. Gilbert Children’s Museum since my return from interning at the Robotics Institute at Carnegie Mellon University. (No, really, I was there!)  I’d been away from the wife and kid (“kids” including the one due in September!) for about a month, and it was great to be back.

For just a paragraph or two, I’ve gotta spill some philosophy.  Even before you have a family, and especially after you start one, hopefully everything you’re doing is for their current or future benefit.  There is nothing that can replace the fulfillment of a loving family, and like all great things, it requires preparation.  An interesting point of fact that is that Sam Walton, someone who spent his whole life innovating and who founded the largest retail chain in the world Wal-Mart, determined that he failed in life.  His last three words, given on his death bed while surrounded by his family that he hardly knew, were “I blew it!”

No one’s perfect, it’s just important to be making progress rather than regress.  New goal in life for me: Don’t blow it.  I gotta make a little bit more effort in that area, and I’m thinking even just a random act of kindness or two a day for the people I love will help.  Now, go to your room and think about it for 10 minutes, then come back and read the rest of my post. ;)


Me standing next to Boss, winner of the 2007 DARPA Urban ChallengeI had an amazing time at the Robotics Institute.  That’s me next to Boss, the autonomous Chevy Tahoe that won the DARPA Urban Challenge a few years back.  It drove itself, without collision and following all normal traffic rules, through a 60 mile urban obstacle course.  It is one of the most famous robots alive.  Boss vs Brad: Brad loses.  Boss vs Millenium Falcon: I’d love to see that show up on Youtube…

I got to work with a great group of people on a really fun, agriculture related robotic project.  I’ll probably share more on that in the future, but it’s not for me to talk about yet ;).  Most of the people around me were working on the Google XPrize project, and it was awesome to see that and other jaw-dropping amazing projects in the bay I was in.

I’d like to share a follow up post on how the checker playing robot went.  It was pretty fun, albeit stressful.  We knew at the outset that the chances of successfully navigating this project was 3,720 to 1, but we decided the risk was worth it.  Plus, we figured we could call the support desk to help us get through any ID10T errors.

The robot was based on the new XMega AVR processor.  It has quite a few more features than the standard AVR chips, which also made it a bit more difficult to use.  I recommend AVR processors highly, but unless you need functionality only provided by the XMega series, I would recommend most beginners stick with AVR chips from the ATMega series.  This project, however, needed the higher processing power, the larger RAM, and the higher flexibility of peripheral hardware offered by the XMegas.

I don’t want to repeat too much of the description of the design and process that my lab partners and I went through to do this project – it’s already available on the project website here.  You can download the SolidWorks CAD, EagleCAD, C code, and other project files from there.

So it wasn’t quite capable of playing checkers at the end of the term.  Our grades took a bit of a hit because of that, too, but it was great to try something new and the reason for this design is as follows:  We tried tackling this problem from a user’s point of view, which is something I believe is left out of academic and commercial projects all too often.  Who likes to play checkers?  Children and old men in the park.  Most other robots in the class were gantry or industrial robot arm based and relied on a laptop tether to function, which could never be practical when used by children or the elderly for safety, expense, and ease of use reasons.

Our robot weighed in under a pound and was, at least theoretically, easy to use and setup.  It used AA batteries and would be safe for anyone to use, and not expensive to replace if broken.

Now, if only it had worked :D.  The robot performs computer vision by reading images in from a UART based camera directly into the RAM of the XMega.  The XMega then determines where the checker pieces are at, calculates moves, and then goes out onto the board to execute those moves.  We fell just short of what was needed for full functionality in most areas due to lack of time and lack of experience with certain components.  As you’ll see in the video, poor motor control and localization was the primary point of failure.  Check the project website for a more detailed synopsis of what worked and what didn’t.

In this video, the robot has just captured an image and is moving from the image capture location to the checker board to make a move.  All decisions were autonomous, but the bot was stepped through its motions one step at a time and assisted when its localization or movements were out of place.

Checkers? What the … oh … Checkers!

In case you’ve noticed, my last few posts have not been about the ZephyrEye.  Not to fear – ZephyrEye is alive and well!  Boards should be readily available soon.  So for everyone out there interested in hacking together some Battlefront radar screens with your paintball/laser tag buddies, it is coming shortly.  Of course, if you can’t wait, feel free to grab the schematics and spin your own PCB ;)

So what the heck have I been posting about?  As I mentioned previously, I’m taking a Mechatronics course where we have to build a checker playing robot.  Here’s a conceptual animation for the design that my team and I came up with:

I used Blender3D to animate this video.  I’ve found with several of my robotics projects that most people get confused when I try to describe it.  By making a rough 3D sketch and animating the intended functionality, I’ve been able to talk with people much more effectively and get faster and better feedback about what will or won’t work.  It also helps me get several jumbled and mixed together concepts in my head down to a single, better defined concept.  If you’re planning on doing robotics, especially if you’re working on it from an electronics point of view, I’d highly recommend learning a 3D sketching system.  But I digress…

So this checker playing robot needs to be able to play checkers completely autonomously.  Most teams used either a stationary robotic arm or gantry style approach.  I’ve never been a big fan of either, in fact, I’m pretty enamored with the concept of small autonomous mobile robots.  A big reason for this is the ability to quickly apply swarm concepts to these robots if you build a few up, which is something I always toy around with in the back of my head but never do.

Here’s some of the primary system components and a simple description of each of them:

  • XMega256: Pretty powerful little chip.  I both appreciate this chip and its potential, and at the same time can’t believe how long the errata list is.  It’s pretty bad, but fortunately I haven’t run into too much trouble yet.  I’ll be using this for all of the checker-playing AI, computer vision, and localization tasks.  Yep, you heard me: computer vision on an AVR!
  • C328: OK, so the computer vision isn’t as hard as it could be – the COMedia C328 is a pretty easy to use (relatively speaking) UART camera.  The datasheet sucks, and it looks like it’s being discontinued.  I’m sure other similar parts will crop up soon, though.  I’ve been reading in raw 565 RGB images into the XMega RAM and finding color blobs with it.  I can also transmit a JPEG to a computer via XBee.
  • XBee: I use these for just about everything.  I usually write up a debug interface between the computer terminal and the robot so I can debug very quickly, and portably – it’s just as easy to debug and control from my desktop as it is my laptop, making presentations a lot easier.
  • Servos: We went with servos for motor control.  As my other posts have alluded, I’m using some hacked for continuous rotation, and instead of controlling position I’m controlling their speed with a standard servo signal.  To maintain balance (I didn’t want to go down the inverted pendulum road…), the bot also has a servo with a “propeller” mounted in front.  The propeller slides over checkers as the bot goes forward and backwards, but rotates when the bot turns to avoid strafing the board and moving checker pieces all over the place.
  • IR Sensors: There’s a bank of 6 IR emitter/detector pairs on the front of the bot.  These are used to detect where the bot is at on the checkerboard.    By monitoring the difference between when a left and IR detectors hit a checker square, you can also correct and maintain orientation so you don’t knock checkers all over the board.
  • Odometer Sensors: More IR sensors, this time the QRE1113 reflectance sensors.  These sensors monitor a band of alternating light/dark colors on the inside of the wheel, so every time the wheel moves a certain distance, the XMega gets a “tick” that’s worth a certain distance.
  • Chassis: A benefit of being in school, I have access to 3D printers that can take certain CAD files and actually “print” 3D objects in ABS plastic.  We used this for the chassis, which put all of our servo mounts, sensor mounts, and other typically difficult-to-make-precise-on-prototype features a lot more accurate.  It cost about $30 – not bad for what we get.

That’s the general idea.  Here’s a picture of where it’s at right now:

Here’s hoping that I get it done in time!  I don’t think it’ll get done in 12 parsecs, but that’s a measurement of space and not time anyway …

ZephyrEye Rev2: Call for Schematic Reviewers

24 February 2010 3 comments

There are a few inevitable truths in this world.  Taxes will rise, Wookies shed all over the furniture, Luke and Leia are related, and there is no such thing as a perfect first draft schematic.

The Rev2 circuit is nearly complete.  It looks AMAZING if I do say so myself.  That’s the problem, though:  I’m inundated with excitement and therefore am unable to find things that are wrong because I don’t want to find any reason that might delay getting the circuit boards back as soon as possible.

I’m calling out for a few extra set of eyes to look over the schematic   If anyone could please go to the Google code, download the Eagle CAD files and take a look, I’d really appreciate it.  If you want to make changes, let me know so I can arrange for them to be merged back in properly.  Even if you’ve never looked at schematics before, take a look and as always, feel free to ask what’s going on in the comments.

This is also a great chance to give suggestions on functionality.  I should add, it may be your LAST chance!  Please give some comments if you think you might ever build one, if nothing else just to say you think it works for what you’d like to use it for.

If you’re not familiar with CAD schematics and circuit board layouts, it might be interesting to look at the history of the .sch and .brd files in the Google Code repository.  By looking at older revisions, you can see the steps taken along the way chronologically.  I commit changes at least at the end of almost every day I work on the project.

The current Bill of Materials can also be found at this Google Docs spreadsheet.  It includes estimated pricing – it currently comes in at just under $200.  A little bit higher than I was hoping, but about the same cost as Rev1 and Chuck Norris (adverbicized) packed with new extra features!

The schematic is hopefully organized well enough for someone not intimately familiar with this project to try and understand one section of the schematic at a time.  The capacitive touch schematic is separate, because it will be a separate board.  The way it works is you put copper pads on the board, glue it to the inside of your enclosure, and it senses you touching it on the outside of the enclosure.  Pretty nifty, and a great way to avoid milling the enclosure.

Please post comments below, or add to the Google Groups discussion page.

ZephyrEye: Rev1 vs Rev2

11 February 2010 7 comments

OK folks, I’ve received quite a few requests so here’s what’s up with the circuit boards I have available.  They are Revision 1, and have some hardware bugs (all of which can be corrected with a scalpel, soldering iron, and a fair amount of skill).  I’d like to go through the rundown once here so everyone understands what’s up.

The plan is to get started with Revision 2 soon.  There are quite a few feature improvements that would make the ZephyrEye work a lot better, and I’d like to list them.  I’m not trying to talk anyone out of a Rev1 board, I will gladly send them (without charge but unpopulated) to anyone until I run out, but I would like to avoid anyone having false expectations of what it can do.  That being said, it will probably be at least a few months before Revision 2 is ready.

If you are thinking about building a ZephyrEye, please use this post to consider your options.  Remember, it really can’t do much of anything by itself – it only tracks other ZephyrEyes, so think in pairs.  And Rev2 is very unlikely to be backwards compatible with Rev1.

Revision 1

I feel kind of like I’m hanging out my dirty laundry, these are some pretty silly mistakes:

  • LCD connector is missing two traces, which requires hand soldering wires to this connector.
  • Traces ran too close under the LCD connector, so installing the connector requires bending the pins down at an angle and soldering them without the connector having full flush contact with the board.  This bug proudly brought to you by the autorouter.
  • An extra voltage regulator needs to get patched in for the XBee, which outdid the current supply capabilities of the original regulator.

Hardware that is still untested:

  • Microphone to ADC
  • ADC channel for voltage monitoring
  • Charging indicator from LiPoly chip

State of Software:

  • Has a bootloader for easy, wireless program updates
  • Can do simple system setup
  • Can play King of the Hill, but currently limited to 2 players (I currently only have two ZephyrEyes to play with ;)
  • Still has a few bugs, graphic artifacts, etc.
  • Still needs other games programmed into it.

I only have unpopulated circuit boards (e.g., bare as the day they were born), so it’s up to you to have the tools, AVR programmer, XBees, GPS module, and pretty much every other part if you are considering putting one of these together.  Alternately, if enough people request it and are interested, I might put together some kits.  Email me or leave a comment if interested.

Revision 2

On top of the features Revision 1 already has, I would like to add the following features.  Note that some of these are crucial to be successful in playing paintball with a ZephyrEye.

  • Clear epoxy filled case that can take direct paintball impact and other abuse
  • Capacitive touch buttons, which would enable the above feature.  These would replace the tact switch buttons for the menu, zoom, and power buttons.
  • Digital compass for heading compensation.  This way the “radar” is oriented the direction you’re facing, rather than just pointing north, which is a little confusing if you aren’t a well-oriented person.
  • Helical GPS antenna, for better reception when near other objects (like your arm, body, or hopper)
  • GPS module (or chipset) with higher sensitivity and output frequency (> 1Hz)
  • Swap out the Series 1 XBee for either a 900MHz XBee or a MeshNetics ZigBit module, which have longer range and more complete, ZigBee compliant firmware.
  • If possible, an optional external ZigBee antenna for better transmissions in, say, densely forested or urban arenas.
  • Use the newer, faster XMega256.  More peripherals, and runs at a blazing 32MHz.  She’s fast enough for you, old man.

Make sure and post comments here or join the Google Code project if you’d like to have input on what Version 2 will be able to do.

Edit: I’ve also just created a Google Group for project development discussions.  If you think you’d ever be interested in using a ZephyrEye, for paintball or other, please join the group and put your thoughts up.  Revision 2 hardware development will begin in earnest soon, so now is the time to ask for features.  I’m torn between adding a can-opener or laser pointer … surely your ideas are better.

ZephyrEye: Assembly and Testing

27 January 2010 Leave a comment

So now we’re getting into the nitty gritty: time to put this sucker together!  I actually really like soldering.  It’s kind of like knitting.  You put your soldering iron on a TV tray, turn on the Price is Right and some soap operas, and make wonderful Christmas presents.

As promised, here’s the top side and bottom side of the 2-layer PCB returned from Sunstone Circuits.  I usually go without silkscreen and solder mask (the green coating on PCBs) because it’s cheaper and a little more convenient to solder patches onto.

The best way to test a new circuit board is to assemble and test one section of the circuit at a time.  Of course, I never do this.  But you should.  If you haven’t noticed so far, I have no issue using hypocrisy to control others actions.  I’ll make a great politician someday.

The alternate method that I more typically use is that I will cut traces on the board using an Xacto knife and then put a dab of solder over the cut when I get ready to test it.  Sometimes it works well, sometimes I end up doing a lot of cutting, fixing, cutting, and fixing …  kind of a Michael Scott/Jan Levinson relationship goin on with my boards, snip snap, snip snap …

On this particular project I did a blended approach of the above – I did a few things at a time, and some cutting as necessary.  The first thing you want to solder on is the voltage regulators and associated passives.  Check to make sure you get the voltages you expect with a voltmeter, because if you don’t it could be the end for any chips attached to that voltage rail.

What’s that? VR4, you say?  Where’s that on the schematic? Well, it turns out I didn’t do a great job of specing VR2.  For a while, whenever the XBee transmitted a packet, it would reset the GPS.  Undervoltage!  It couldn’t source the current needed when transmitting.  So I cut Vcc loose from the XBee and tacked on an extra LDO regulator to provide power for it since it draws more current than anything else.  This seemed to fix the problem.  Snip, snap, snip, snap…

The LCD datasheet recommends two separated 3.3V voltage rails, one shared with VCC and one for internal needs, on top of a 6.8V white LED backlight voltage.  The TPS61040 boost regulator worked great for this source.

Next I soldered on the MCU, LEDs, the XBee module, the GPS connector, and all the associated passives.  Touch bases with Starfleet Command by writing a quick program to test that the microcontroller is running.  The best test is the “blinky” test.  If you get the LED to turn on and off, you’ve got things going for you.  If you don’t get a blink or if you notice your one second toggle is actually eight seconds, check the MCU fuse bits.  Shorted crystal leads is typical if you fail to get anything, or check the “divide clock by 8” fuse bit if you get an 8-second “1-second” blink.  Alternately, check that time has not been scaled by LHC tests.

I’ll mention some about the programming, etc., but if it feels like I’m talking about it briefly, it’s because I am.  The next blog topic is programming, where I’ll dive into the programming details, fuse bits, chip communication protocols, etc.

The XBee was the first part to get going.  It’s even easier than a MAX232 chip.  Just connect the UART lines up and start sending bytes.  Whatever you get on one end, you get on all the others (at least in out of the box configuration).  So it’s really great for diagnosing problems early on.  On the other end, I’ve got another XBee chip connected to my computer through an FTDI UART-USB chip.

After I got the XBee transmitting and receiving (transceiving?), I programmed a UART based bootl0ader into the Mega128.  BASCOM-AVR provides a very easy to use and easy to modify bootloader that receives programs via XModem.  It works like a charm with only slight modifications (baud rate set to 38400).  A bootloader acts like a separate program whose sole function is to copy the main program into Flash memory.  It runs at startup, or if called from the main program, and checks to see if it is receiving the a particular byte sequence.  If yes, it does it’s thang.  If not, then it just calls the main program.  This speeds up development time a billion, because I can reprogram it anywhere.  From across the house or across the street even.  Kinda fancy, yeah?

Next, I checked reception on the GPS.  Since the Mega128 has two UARTs, I used one for XBee and one for GPS.  The GPS transmits NMEA strings, which provides localization information.  This one was pretty straightforward, just parse the GPRMC sentence to extra heading, latitude, and longitude info.  And it can be simplified if you assume it’s only used in the Northern hemisphere, which of course, I simplified.  I did add a 2.2K pullup on the GPS Enable line which helped it ride through the power dips during XBee transmission.

Last but not least, the LCD display.  This one took a little bit of soldering iron sorcery to get it to work.  I forgot (gulp!) to connect the data and clock lines on the display.  That makes it a beautiful blue PCB decoration with no function.  If you look closely at the display connector (just north of the AVR), there are two little strands of wire that pull those signals off the 0.5mm pitched (spacing from center of one pin to the next).  I soldered them to a couple of cut out vias and then soldered a strand of ribbon cable to suitable pins on the MCU.  The screens are a little fragile because of this…

Last and, since I almost forgot about it probably least, the battery and charging circuit.  The battery is an 1100 mAh Lithium polymer from SparkFun.  According to my scope, the circuit drew about 250 mA, which if the circuit was optimized to draw all the juice out of the battery, would last for four hours.  In reality, the Low Drop Out (LDO) regulators require about 0.3V about 3.3V to properly regulate, so they will source from 4.2V down to 3.6V properly, but without crunching a lot of math I should be able to get about an hour per charge.  The MAX1555 is a super simple Lithium Polymer battery charger that can charge the battery through either USB or DC power sources.  When the battery is full, it automatically goes into trickle charge mode to keep the battery topped off.  It works perty good.

I just said perty.  My redneck past is always nipping at my heels …

Anyway, the final physical appearance of the jobber looks like this, next to a couple of common objects for size comparison:

And just to make sure things would look right, I programmed in a quick and dirty static screen that represents what the game screen might look like:

Next post, we’ll dig into the firmware.

ZephyrEye: Board Layout

27 January 2010 7 comments

Have you ever wondered, if you were a cat, if you would have been one of those cats that would have chased the laser pointer mark across the wall, again and again and again?  Eight hours a day?  If yes, then there’s a promising career for you in circuit board layout!

Actually, it’s not quite that bad.  I have to admit, though, if I were a cat … well, anyways, it’s kinda fun in a weird way to lay out a circuit board (which is probably what the cat would say too).  You get to put all the components in correct positions, and it gets you outside of the flat earth of schematic-land and thinking a little in 3D.  These parts have to fit in an enclosure, and that’s usually the trickiest part of board layout: How is this PCB going to fit in its final resting place?  Will the charging plug fit?  Where will the screen go?  How will buttons make it outside the enclosure?  Then you hope there’s enough space left on the surface of the PCB to connect them all together with flat copper wires.

I have to lay out a disclaimer here (hmmm … probably should have a few blog posts ago …) that I was working towards a proof of concept more than something that could actually be used.  The approach I took led me to design a project that would absolutely shatter into a gooey, paintbally mess of plastic and electronic parts if it took a direct hit.  That … actually makes it sound kind of fun … (No Brad!  Don’t do it! Don’t go into the cave with your lightsaber!)  I’ll explain later how I intend to make this thing field-hardened and able to withstand the worst abuse that even a cartoon Nelson (“Haw haw!”) could throw at it.

So here’s a list and short description of the approach I took for the enclosure and mechanical interfaces:

Enclosure:

  • ABS Plastic enclosure from Polycase.
  • Edit: The case is actually a PacTec enclosure, from the PP series.  Memory lapse caused this unfortunate mistake.
  • This one from SparkFun is a little bulkier, but might work as a decent replacement (no guarantees!).

Screen Cover:

  • 1/16″ Acrylic (Plexiglass) from a local hobby store.
  • I carved into the case with a drill, flush cutters, and an Xacto knife to make a viewing hole for the LCD display.
  • Cut the acrylic with scissors, and stuck over the viewport on with double sided tape.

Buttons:

  • 3/8″ tall tact switches, with stiff contact force to prevent accidental presses.
  • Drilled using a 1/8″ drill.

Charging Connector:

  • 2.1mm Barrel jack (planned) for charging from a wall wart.
  • Since I only charge it from my bench power supply, I decided to just leave it with male 0.1″ pin headers.
  • I left the top plate off until I was sure things were working.  Then I left it off because it was working – why rock the boat?  The charging connector therefore required no drilling.

Battery:

  • An electrical component for sure, but a very large one with special placement considerations.
  • Fits flat behind the PCB inside the enclosure.

GPS:

  • Again, an electrical component but it’s large and needs to be placed carefully.
  • Originally, I mounted it flush to the back with foam tape.  It seemed like this caused it to take way too long to get a good lock on the satellites…
  • So I placed it perpendicular to the face of the enclosure heading out the back direction.  Again, double-sided foam tape.  It’s just about as important as a soldering iron for most projects I do.

On/Off Switch:

  • A simple slide switch was used.
  • Just cut the positive terminal from the battery and soldered this in series.  Again, no top plate makes installation easy.

So, on top of all the electrical connections, we’ve also got to worry about all the mechanical placement when it comes to board layout.  So let’s get down to it.  I chose a two-layer PCB, meaning you can put copper on top and on bottom with copper plated holes (vias) that connect signals from one side to the other.  The red denotes where copper will be placed on the top side of the circuit board, and blue denotes where copper will be placed on the bottom side of the board.  Without further ado, here it is:

The inverted looking silk screen helps show which parts are to be mounted on the back side instead of the front.

Eagle actually has an autorouter, which works OK even though the results are usually ugly as sin on Sundays and it’s generally hard to fix things if you add new connections post-autorouter.  Nevertheless, on large boards it’s still a useful and time saving tool that’s worthwhile.  I used it for this project, and then went through and thickened higher current wires and corrected a few other items of importance.  I also laid out some large ground planes using polygons (see the big read lines that go around the perimeter?), which snap a large copper plane around existing traces without overlapping or shorting other traces.

That’s about it for the board layout process.  I used Sunstone Circuits to fabricate the circuit boards, they are in-state to me and ship it the following day (free ground shipping, which is overnight to me).  There are lots of other places that are probably cheaper, but I’ve never had a quality problem and I get them REALLY quick.  Patience has never been a virtue of mine.  In fact, it’s never been a virtue – that was  a lie spread by the magical powers of ligers in the late 18th century.

Uh, I ordered a few extra boards (price breaks levels work solely to generate revenue), so if anyone wants one, feel free to request in the comments!  They’re not perfect, but can be made to work.

Next time: I’ll go over what I found (and didn’t find!) during testing.

ZephyrEye: Schematics

26 January 2010 Leave a comment

So here’s the start of the design section of the project.  I’m releasing this project and related information under the BSD license.  I’m not into the viral type of Open Source licenses, but if you make a buck let me know about it cuz I’d l0ve to hear about it.  And maybe you can buy me some draft root beer … and if it’s a lot of money, maybe a Tesla

I thought I’d put one of the many logos I made for it here.  Amazing what a guy with a hamster wheel in place of right brain functionality can do with a few GiMP filters…  Well, maybe not as amazing as I think, considering I am the one with the hamster wheel brain.

Before I dive in too deeply, lemme run over the development cycle that will ensue now that I’ve got my spec:

  • Draw up a schematic
  • Lay out a circuit board (e.g., place drawings of the parts on a printed circuit board document and draw metal wires between all of the parts that need to be there).
  • Break piggy bank.
  • Send the circuit board to a “board house” to get it fabricated.
  • Purchase parts needed from online electronic component suppliers like DigiKey, SparkFun, and Mouser.
  • Assemble the parts.
  • Write the code.
  • Field test the result at various steps along the way.

I’m definitely a bottom-up developer, meaning I take the skills and parts I know well and attack the given problem with those first, and only add in new skills/parts as my existing skills/parts set prove unsatisfactory.  I’ve tried to break this habit, but it gets really cool results really fast and it’s hard to part with that (at the expense of a most likely higher quality project that might be achieved using a top-down approach).

I’ll hit you with a brief overview on the parts that I picked, and then I’ll show the schematic at the bottom:

MCU:

  • ATMega128 from Atmel
  • 128KB Flash program space, 4KB RAM
  • 54 I/O pins
  • 8 ADC channels, for power monitoring and microphone reading
  • Clocked at 8MHz and powered at 3.3V (because all cool components run at 3.3V ;)
  • It’s one of the easiest microcontrollers to use these days, and ridiculously capable.
  • Programmed in BASCOM-AVR.  More on that later …

GPS:

  • EM-406 GPS module from SparkFun.
  • 20 channel (e.g., can track up to 20 satellites simultaneously)
  • 5m accuracy
  • Small and works pretty standalone
  • Connects through a UART to the Mega128

LCD:

  • Color LCD Nokia Knock-Off from SparkFun.
  • 128×128 Pixels
  • 4096 possible colors, but only 256 at a time in the palette
  • Not that great, but it does the job about as good as an old cell phone LCD display would

Wireless Transceiver:

  • Digi XBee Pro, also available from SparkFun among many other vendors
  • 1 mile line of sight range, 300yd urban range
  • Easy as pie.  And like Jack Handy says, “If you get the chance to choose between regular heaven and pie heaven, choose pie heaven.  It might be a joke, but if not, mmm boy!”  Mmm, XBee!
  • Flexible addressing and self-healing mesh networking capabilities

FRAM:

  • FM24C64 chip from Ramtron.  I’ve only found it from Mouser.
  • 64KB of high-speed, non-volatile RAM.
  • Cheap (~$3.50)
  • Used to store field and game information, along with user settings
  • Every project with small non-volatile needs should use one of these.  They’re fantastic.

Battery:

  • 1100 mAh Lithium Polymer battery from SparkFun.
  • MAX1555 Li-Ion battery charger.
  • This is a pretty good and easy to use combination, and I’ve had great luck with the crazy easy to use charging circuit in the MAX1555 datasheet.

Those are at least the main parts that drive all the primary functionality of the system.   Drum roll ….

….

Schematic time!  I use EagleCAD from CadSoft (http://www.cadsoftusa.com) for drawing schematics and laying out PCBs.  They have a free version for non-commercial use, which is great for open source and hobby stuff.  SparkFun releases EagleCAD libraries for almost all the parts they sell, which kicks development speed up to .5 past lightspeed.  Eagle is also cross-platform compatible, for all you fellow penguins out there.

ZephyrEye Schematic

Sorry for the under-impressive image on this page.  Click through to zoom in for readability.  You’ll notice I organize my schematics by net names rather than running crazy lines all over the page.  Please don’t ever make schematics like that.  Every time you make a rats nest out of nets running all over the page, a devil gets his horns.  Just don’t do it.

Instead, label the crap out of EVERYTHING.  It’s best to not leave any nets with a default net name (e.g, N$42).  You’ll notice that it’s usually fairly easy to follow the document this way, especially when you’re using a printout, PDF, or some lame JPEG on a blog instead of Eagle to view the schematic.

Rant time’s up.  Anyways, I know I messed a few things up.  I’ll make an errata list if I can remember what they are …  Also, it’s OK if you don’t have a clue what’s going on.  I’ll explain most of the connections in later posts, especially once I start talking about the software (because that’s where the pin functionalities and inter-IC signals really get defined).

Also, you may have noticed I like SparkFun (woot!).  They’ve got some great stuff that hobbyists normally can’t source, like the GPS module, LCD display, and lithium ion batteries.  They also have a lot of great tutorials for beginners, for everything from Arduino to basic soldering.  Shameless plug: buy stuff from them.  Every time you place an order, a devil gets his horns removed.  (No, I don’t work for them … that’s a pipe dream …)

Next time, on Brad’s Projects: Board Layout!  Yay!