AVI-TAR System Design Part 2: Prototyping

Last post I talked more about the design path behind the current incarnation of the AVI-TAR project. Time for nuts and volts.

Phase I: Component Selection

Last post, I talked about what parts I thought I'd need. I'd settled on the Sparkfun Pro Micro Arduino board for my initial prototype since I expected that it'd have the horsepower to run the system I wanted to develop. It's small and easy to both breadboard and integrate. That just left everything else...

I knew that I wanted to mount the display behind the top rail of the TAR, where the MARS sight would normally attach. I figured on printing up plastics for that so I had a good idea of dimensions: about 45mm x 45mm. That helps greatly with the display selection. There are a number of LCD and OLED modules out there and they're all pretty cheap. After a good deal of research I decided that I'd try a Nokia 5110-style display. I picked up the SparkFun version as well as a few from Deal Extreme, which were half the price of SparkFun's part but are also not made as well.

Input switches for the user interface was purely a product design choice. I started out with a 4 button membrane switch part that I had laying around but quickly realized that there's no good place to put that on the TAR. After some unfocused staring at my partly disassembled TAR I came up with the "navigation inputs in the grip tail" idea. SparkFun came to the rescue with a scrolling switch on a PCB:

By now I must sound like a SparkFun employee. The reality is that I hit a lot of sites looking at stuff; SparkFun just seems to keep coming up with the right part at a decent price. Digikey filled most of the rest of my BOM (bill of materials).

Phase 2: Breadboarding

WIth parts in hand, I tossed the Arduino, nav switch and LCD onto a protoboard and started writing code to bootstrap myself. It only took a few hours spread across a week or two.

Once I got "Hello World!" working and could read the switch inputs it was time to build a PCB test platform since the motor controller is a surface mount job.

Phase 3: Test Platform

The last time I designed a PCB I used an etch-resist pen. This time around I used Eagle Light. Whip up a schematic with the schematic editor and it'll help greatly with the board layout. Here's the schematic (click to enlarge):

I eventually ended up with this 2-layer board from the OSH Park PCB service:

This board uses .1" headers for connections. It allowed me to quickly swap things around. The Pro Micro (which I soldered headers onto as well) sits in a regular DIP socket on the board so I can swap it out as well. The only things soldered in are the passives and power electronics.

From that and the schematic I got to my test platform:

(Yes, the board it powered up and on the main screen)

With this board I was able to try out a number of shot detection methods: dV, dI (the motor driver has a current sense output), even a piezo element attached to the gearbox:

(The gearbox is from a SIG 552, one of our first AEGs in the house)

Interestingly, for my hardware choices I found that the piezo detection method was very good at determining when a shot occurred. My software wasn't quick enough to detect the current changes in the freewheeling part of the gearbox cycle. Voltage detection was also a non-starter with a LiPo and the motor driver running the show. When I first played with voltage detection, I saw distinct spike in voltage when the motor freewheeled via a Fluke scopemeter across the battery leads of my stock microswitch-operated gun. With the half-H bridge driver and a LiPo running the gearbox, all I saw was a dip in voltage when the gearbox was operating.

That left me with a choice: try to use the piezo detector and filter out rough handling (bumps, drops, etc.) or go with a true BB detector. 

I ended up gritting my teeth and drilling a perfectly good 6.03 barrel to mount one of these:

It's a Sharp 10mm photo interrupter on a breakout board. I'll bet you can't guess where I got it from...

Putting that across the path of the BB as it went down the barrel was the surest way to detect a shot. At 500 fps (154.2 m/sec - more than most fields allow anywhere) a 6mm BB travels about 25,700 BB-widths per second. That means that as that BB passes the photo interrupter it will deliver a signal change that lasts about 39 microseconds. As long as the photo detector's edge time is 1/4 of this or less and the Arduino can detect and act on the signal change we're all good.

As it turns out, Arduino interrupt servicing is much faster than 39 microseconds so we have a working shot detector. The rest is just coding. Or is it?

More about that next post, as well as the "production prototype" board build. Time to bend an elbow...