Archive

Posts Tagged ‘microcontroller’

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.

Advertisements

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: Parts List

11 February 2010 2 comments

So, the stats tools on WordPress are kind of impressive … and useful at correcting idoits like me.  I’ve talked all around it, but I noticed I haven’t released an actual bill of materials and noticed quite a few people have been searching for it.  Maybe they want to build a ZephyrEye?  I’ll try to do my best to appease the masses.  It’s been quite a while since I actually built the hardware, but here it goes…

Lucky for me, and anyone else using EagleCAD, there’s a handy User Language Program (ULP) called bom.ulp that autogenerates a BOM.  It only lists items that are actually on the schematic, however, so don’t forget things: the LCD connector denotes you should also buy an LCD display.  I’ve never made that mistake though.

Partlist exported from /home/brad/Development/zephyreye/trunk/cad/ZephyrEye Rev0.2.sch at 2/11/10 1:32 PM

Qty Value Device Parts
2 LED1206 LED1, LED2
1 LIPOLY-GEN BAT1
1 PINHD-1X2 MIC
1 POWER_JACKPTH PWR
8 TAC_SWITCHPTH SW_DOWN, SW_IN, SW_LEFT, SW_OK, SW_ONOFF, SW_OUT, SW_RIGHT, SW_UP
1 .01uF C-USC0603K C5
7 .1uF C-USC0603K C3, C7, C17, C18, C21, C22, C23
2 1.5K R-US_R0603 R4, R7
1 1K R-US_R0603 R1
3 1uF CAP_POL1206 C8, C9, C12
1 2.2K R-US_R0603 R2
2 2.2uF (TANT) C-USC0603K C14, C15
1 4.7K R-US_R0603 R9
1 8MHz CRYSTAL XTAL-MCU
4 10uF CAP_POL1206 C1, C2, C6, C10
1 10uH INDUCTOR0603 L7
2 18pF C-USC0603K C19, C20
1 22K R-US_R0603 R55
2 100K R-US_R0603 R5, R54
1 100pF C-USC0603K C11
3 470 R-US_R0603 R6, R8, R16
1 470K R-US_R0603 R3
2 470pF C-USC0603K C13, C16
1 1000pF C-USC0603K C4
1 AVR_SPI_PROG AVR_SPI_PROG HDR1
1 BC108B BC108B Q1
1 DATAFLASH ATMEL_DATA_FLASH IC2
1 EM408 EM408 GPS
1 MAX1555 MAX1555 MAX1555
1 MBRA140 DIODE-DO214AC D1
1 MEGA128-A MEGA128-A IC1
2 MIC5205 V_REG_LDOSMD VR1, VR2
1 NOKIA6100_LCD NOKIA6100_LCD LCD
1 TPS61040 TPS61040 VR_LCD
1 XBEE-PRO XBEE-PRO XB1

Most of the “primary” components are from Sparkfun, with most of the passives, voltage regulators, etc. coming from Digikey.  So, on top of this list, you’ll also need:

If anybody is seriously interested in making one of these guys, let me know.  If at least 10 people are interested, I would be willing to make kits at cost (should be ~10-20% cheaper), and help those wary of the SMT soldering (for a nominal reimbursement).  Keep in mind the programming either comes from you, me, or the community and that the software has basic functionality but is not yet complete.  Also, you’ll want at least two (unless you want to use it for something other than paintball/laser tag gaming).

Note: I’ve started adding a few product links in.  As I have time, I’ll fill in the rest.  Feel free to help out in the comments if you find links to products (from SparkFun or DigiKey generally) before I do.

ZephyrEye: LCD functions

11 February 2010 Leave a comment

So, how do I get all these different components to play nicely together?  Lots of time in the datasheets, browsing forums for tips, and a perpetual lack of anything better to do.  That’s because of the inherent coolness of the project, obviously, and not from lack what “y’all call da social skills“…

I’ll be going through each of the components in the chip and talk about how I interfaced them to the ATMega128 AVR microcontroller.  I’ll try to give enough detail so that someone could rewrite this in a different language if they felt like it.  Once the component interfaces have been described, I’ll go through and describe the remaining functions (menuing, GPS, games, etc.).

This handy little LCD display is pretty easy to use.  SparkFun sells them standalone as well as with a sweet little breakout board, which handles the hard to solder connector and funky backlight voltage nicely, allowing just about anybody with a spare micro lying around to use this display in their projects.  Here are some simplified pin descriptions (but remember the datasheet is the final reference) for those setting up their own display.

  • 1) V_digital: Supply voltage for internal logic circuitry.  Should be separate from V_display.
  • 2) LCD_reset: Resets the LCD.  Necessary for communications.
  • 3) DIO: Data input pin, connect to the MOSI line of your MCU’s SPI hardware.
  • 4) SCK: Serial clock input pin, connect SCK line of your MCU’s SPI hardware.
  • 5) CS: Connected to the chip select line of your MCU’s SPI hardware
  • 6) V_DSP: Display voltage.  This supply voltage is the one that actually drivers the liquid crystals, and therefore needs to be very solid.  The datasheet recommends it has its own voltage regulator, which is not always necessary (it can be tied to Vcc) but I have conceded as it reduces flickering.
  • 8 & 9) GND & LEDGND: Connect to ground.
  • 10) V_LED: White LED Backlight voltage.  +6.8V required to drive these little suckers.  I’ve used the TPS61040 boost regulator to do this, it works nicely.

Note that pin 7 is NC.  It’s also worth pointing out, since this is a battery driven project, that it’s useful to have enable lines connected to GPIO pins on your MCU.  In particular, I’ve been pleased that the +6.8V regulator can simply be turned off when the display is dormant – this saves between 40 and 60 milliamps, which can extend battery life a LOT.

BASCOM-AVR has some very nice routines to use knock-off cell phone displays with the Phillips and Epson chipsets.  However, it didn’t quite work with this particular display from SparkFun so well.  Luckily, I’d already been using this display for a while before Bascom added a library for it, and by using my init routine after calling theirs, it seemed to work out OK.  Here’s the relevant pieces of code (remember, the code can be found on the Google Code repository).

If this LCD worked directly with BASCOM, setting it up would be easy peasy:

'*******************************************************************************
  'Configure Display
$lib "LCD-epson.LBX"                                        'Library for LCD screen
Config Graphlcd = Color , Controlport = Porte , Cs = 5 , Rs = 6 , Scl = 3 , Sda = 4
'*******************************************************************************

I had to add on my custom init routine to get things to work right, as well as a few helper functions:

'************************************************************
'Sends initialization data to LCD screen
Sub Init_lcd()
   Lcd_cs = 0

   Waitms 10

   Snd_cmd Disctl
   Snd_data &H03
   Snd_data 32
   Snd_data 12
   Snd_data &H00

   Waitms 10

   Snd_cmd Comscn
   Snd_data &H01

   Snd_cmd Oscon
   Snd_cmd Slpout

   Snd_cmd Volctr
   Snd_data 5
   Snd_data &H01

   Snd_cmd Pwrctr
   Snd_data &H0F

   Waitms 100

   Snd_cmd Disinv

   Snd_cmd Datctl
   Snd_data &H00
   Snd_data 0
   Snd_data &H01
   Snd_data &H00

   Snd_cmd Rgbset8                                          'Set up the color pallette
   'RED
   Snd_data 0
   Snd_data 2
   Snd_data 4
   Snd_data 6
   Snd_data 8
   Snd_data 10
   Snd_data 12
   Snd_data 15
   'GREEN
   Snd_data 0
   Snd_data 2
   Snd_data 4
   Snd_data 6
   Snd_data 8
   Snd_data 10
   Snd_data 12
   Snd_data 15
   'BLUE
   Snd_data 0
   Snd_data 4
   Snd_data 9
   Snd_data 15

   Snd_cmd No_op

   Snd_cmd Paset
   Snd_data 2
   Snd_data 131

   Snd_cmd Caset
   Snd_data 0
   Snd_data 131

   Snd_cmd Ramwr

   Clr_scr 255

   Snd_cmd Dison

   Waitms 200

   For B = 0 To 140
     Snd_cmd Volup
     Waitms 2
   Next I
End Sub
'*******************************************************************************

Wow, I should have commented that a LOT better … bad Brad! (hitting myself with rolled up newspaper)

Here’s the helper functions.  Normally I’d just refer you to the code, but for those of you trying to get this LCD to work, using the 9-bit frame is a little tricky.  I will refer you to the code for pin definitions and constants, however.  I ended up bit-banging it – YMMV.  Be careful with the polarity and phase of the SPI signal, it’s very particular.  Lastly, note the syntax of BASCOM-AVR for addressing a bit in a byte is the dot operator (e.g. Dab.7 returns the value of the 7th bit of the byte variable Dab).

'*******************************************************************************
Sub Snd_data(byval Lcddata As Byte)
  Lcd_sck = 0
  Lcd_dio = 1                                               'Data = 1
  Lcd_sck = 1

  Shiftbits Lcddata
End Sub
'************************************************************

'*******************************************************************************
Sub Snd_cmd(byval Lcdcmd As Byte)
  Lcd_sck = 0
  Lcd_dio = 0                                               'Commands = 0
  Lcd_sck = 1

  Shiftbits Lcdcmd
End Sub
'*******************************************************************************

'*******************************************************************************
Sub Shiftbits(byval Dab As Byte)
   Lcd_sck = 0
   Lcd_dio = Dab.7
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.6
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.5
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.4
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.3
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.2
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.1
   Lcd_sck = 1
   Lcd_sck = 0
   Lcd_dio = Dab.0
   Lcd_sck = 1
End Sub
'************************************************************

After that, it’s smooth sailing as all of BASCOM’s internal drawing and text display functions work just fine.  Here’s all it takes to draw the setup screen.  The “splash” picture was included in the program, and is loaded from flash program space.  Pixels are set using the Pset command.  Drawing text at certain coordinates and with a defined forecolor and background is done using the Lcdat command.

'Display Picture
W1 = 0
For Y = 2 To 80
  For X = 0 To 127
    B1 = Lookup(w1 , Splash)
    Pset X , Y , B1
    Incr W1
  Next X
Next Y

Setfont Color8x8

Lcdat 88 , 20 , "Start Game" , Black , Gray
Lcdat 96 , 20 , "Join Game" , Black , White
Lcdat 104 , 20 , "Options" , Black , White
Lcdat 112 , 20 , "Settings" , Black , White
Lcdat 120 , 20 , Unit_name , Gray , White

... (near bottom of program)

'Extra include files - Fonts
$include "color16x16.font"
$include "color8x8.font"
$include "smallfont.font"

$include "zephyreyepic.txt"

So there you have it, how to use the SparkFun LCD display.  Hopefully that helps somebody understand how to use it.

As I’ve stated before, I also hope the lengthy explanation helps get all this converted into AVR-GCC.  As a side note, I would like to develop the component libraries into a more useful place: the avr-libc-corelib project.  This would make libraries for all the components readily available for others to use.

As always, if you have any questions about using this display, feel free to leave comments or email me!

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!

Paintball Radar: Birth of the ZephyrEye

26 January 2010 1 comment

To my wife’s great chagrin, I like playing video games on occasion.  She equates it to the worst form of self-indulgence there is, and a complete waste of time, but it’s relaxing and I rarely (read: less often than not) let it interfere with things I’ve got to get done.  All said and done, I go through spurts where I’ll play for a few hours for a couple days in a row maybe once a month.

My favorite game is Battlefront.  Yes, the original – Upper management won’t approve expenditures on new video games so the ones I get are usually pretty old.  Woot to the stormtrooper.  Enough digression – One day I was playing and thought, “Wouldn’t it be cool to have the enemy radar in real life?”  To which I responded casually to myself, “Heck yes, it would.”

So I made one.  Loosely based off of Halo and Battlefront radar, I designed one for the only acceptable (upper management required non-lethal) recreational war I could think of: Paintball!

I toyed around with the thought of actually making a product out of it for a while.  I didn’t because paintballers I talked with just weren’t willing to part with $200 for what they considered a gimmick.  But it did give me a reason to blow several hundred dollars on something my wife would marginally approve of.  It’s all about working the system (erm, I mean, I love you honey!).

So I came up with a fancy project name, ZephyrEye, drew up a quick concept screen, and wrote up some project specs.

Hardware Specs:

  • Color LCD screen
  • Should be able to monitor ammo levels by detecting shots fired using a microphone
  • Must be hardened to survive a direct blow
  • Uses GPS for localization
  • Uses ZigBee mesh networking modules for up to 1 mile transmissions
  • Must be reprogrammable via wireless bootloader.
  • Must use an AVR processor.
  • Battery must last at least an hour.

Software Specs:

  • Both friendly and opposing players can be identified by color and/or symbol.
  • Visibility of friendly/opposing players can be user selected per game.
  • “The Walking Dead” can be identified by color/symbol (so they don’t get shot again ;)
  • Players can be “respawned” by waiting in a neutral “base” zone for a timeout period after being shot.
  • Can keep score of different styles of games: Capture the Flag, Elimination, King of the Hill, etc.
  • Players can report being hit, which removes them from play and shows others their location as they withdraw.
  • Field objects (such as bunkers, bases, field boundaries, etc.) can be programmed in, saved, and restored.

I’m sure I’m forgetting something, but that’s more or less what I set out to create.  Here’s what I came up with using a cross-platform compatible and open source 3D rendering software called Blender, with a few post-processing effects using GiMP.  I’m really not an artist, but I think it gets the point across.  I’ve never actually integrated a ZephyrEye into a hopper, but I thought it would be cool.

I should also note that while I’ve really enjoyed my paintballing experiences (heck, I went paintballing for prom one year ;), I don’t own any equipment and I don’t go very often.  So, like almost all of my inventions, it’s a solution looking for a problem (bad Brad!).  But even Sir Mix-A-Lot can’t deny the coolness factor.  It’s there, baby.

Next: Schematics and design files.  Hopefully by the third or fourth post on this topic, I’ll have some videos of the functioning prototypes (cause I still don’t have any that look decent…).