Friday, June 20, 2014

AVI-TAR System Design Part 3: Parallel Tasks

See the Intro Video for a quick demo of the prototype



In the last post I talked about the "bench test" system. This post is about the process behind building an integrated prototype.

After the Bench Test...

So I have a functional hardware and software system literally duct-taped to my AEG. The next step has to be mechanical integration, right? (Yes, that's rhetorical.)

I broke it down into these parts:

  • logic board location and internal wiring
  • display location and housing
  • scroll switch location and housing
  • Magazine switch mounting
I'd already kludged the IR detector and will be revisiting that subsystem later on. Each of these parts stand alone and so I worked on them in parallel. We'll start with the heart of the system here.

Logic Board

From the start I'd had the idea of mounting the logic on the underside of the top rail assembly of the TAR-21. It's a long plastic part that slides out of the main body and it has a lot of dead space. The original board I'd designed was the approximate shape but not quite right. Also, since it used .1" headers for most connections it was not field-ready. Those headers are big and do not lock the connectors in place. Great for tinkering, not so much for real world use.

So, back to Eagle Lite for some tweaks to the schematic and board layout. The schematic needed some cleanup, inserting the IR detector connections and deleting some now unneeded parts. Here's the REV B schematic:



As you can see from this version, I'm learning a little more about schematic-building.

A not so quick trip through the board layout and I get this, which went off to OSH PARK for manufacture:



You'll notice that I'm using through-hole components for everything but the half-bridge power device. It's easier for me to build and troubleshoot and I don't need to shrink the board down any further.

Here's the board stuffed and mounted into the top rail. It's a friction fit but there are provisions for fasteners.



I'm using Hirose connectors for the low-power connections. I'm here to tell you that terminating the wires into those without the specific crimping tool is a good way to determine how motivated you are in your work. It's tough, fiddly work.

Next time...the display housing.


Intro Video Posted

I finally found a few hours to shoot and edit a short introductory video on the AVI-TAR prototype:

It shows the basic operator interface and what it looks like as it burns through a small  50-round simulated magazine. I'm using a 300-round flash mag to supply the gun but set the mag capacity low to show a complete magazine cycle when firing in burst mode.

I've almost got the next post in the design saga done, just need to shoot a few more photos.

Stay upwind from the guys who pack menu 01 MREs with them...


Saturday, June 14, 2014

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...

Thursday, June 12, 2014

AVI-TAR System Design Part 1

When I started this project over a year ago I knew very little about AEG (airsoft electric gun) operation. That was a blessing because it forced me to try different things in ignorance of the "system" I was working with. You learn more from your failures.

With that in mind, time for some technical stuff.

Theory of Operation

This is a toy, after all, so I didn't try to get too fancy. In order to meet my design goals (in my first post) I figured that I needed the following elements:
  • A "shot sensor" to detect when a round was shot. There are a few ways to do this:
    • Timer - Once gearbox timing is determined, you can time the shots if you have a fast enough timer system and fine control of the motor so that you can be sure of where the gearbox is when you stop the motor.
    • dV or dI detection - The motor that drives the gearbox tends to draw more current as it pulls back the spring and then freewheels as the sector gear releases the spring for a shot.
    • Hard gearbox timing - Uses some method to determine where the gearbox is. There are a few systems out there that seem to monitor the sector gear. I assume that they look at the disconnector assembly to determine when the system has run through a cycle.
    • BB detection - Uses some method to detect a BB fed through the barrel.
    • Other - Vibration detecion via a piezo element on the gearbox? Tried that...
  • A magazine position sensor to tell when there's a mag inserted in the mag well.
  • A user interface; display and user controls that would fit into the gun's design.
  • Power electronics to control the motor.
  • A micro controller to tie it all together.
From that comes the system diagram:



Of course, this is primarily a software-driven design since the feature set I'm aiming for is complex.

With these subsystems, the operational theory is:

  • State-driven software that reacts to user inputs as well as environmental inputs,
  • Environmental inputs include shot detection, battery voltage and magazine state.
  • User inputs include trigger state and some sort of menu/selection switch inputs.
  • Software runs in a continuous loop, checking inputs; some inputs may generate interrupts to trigger state changes mid-loop.
  • Inputs result in state changes, which cause subroutines to execute, based on state.


So Many Choices:
A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible.
With that quote I profess to be more engineer than scientist. Why hurt yourself while trying to unscrew the inscrutable? I tackled components in this order:

  1. Motor control. I wanted a half H-bridge design but didn't want to have to festoon my board with multiple MOSFETS and their attendant components that'd be needed to interface to logic-level I/O. Fortunately, there's a lot of need for this type of logic-driven real-world interface so you can find everything you need to control a DC motor prepackaged onto a chip for not much money. I looked at a number of high power half bridge drivers before settling on the Infineon BTN7960B, which I found can be sourced cheaply. It's an older product and Infineon has since moved on to the BTN7971 and BTN89xx family. A good discussion of how to use these neat little devices is here.
  2. Processor. There are plenty of decent uCs out there and plenty of good tool chains supporting them. I didn't want to waste time in circuit design so I looked into breadboard type devices. It boiled down to PIC and AVR devices. I've used both before but the AVR-based Arduino culture seemed more adept at rapid prototyping so that's where I went. The SparkFun Pro Micro (5V) is what I settled on. I'd helped my son build a game with one for a school project and he got to learn C and state-driven programming while I got to check out the product.
  3. Everything else. I knew that I didn't have a full-formed idea for the user interface, nor did I understand how to detect shots from the AEG. I figured that I'd dope those out through trial and error. And boy, was there a lot of error to experience...

The "everything else" category was where the scientist came in. Experimentation was the only way to determine how to solve the puzzles of shot detection and the little gotchas that revealed themselves during design integration (making all the parts work as expected). Research is important to the scientific process as well. For example, I found that the micro switch used in the S&T gearbox has a lot of bounce when running in full-auto mode due to the extreme vibrations caused by the gearbox. I spent hours figuring out why the gun would randomly stop firing in burst mode; this was the cause. As it turns out, someone else wrote up the phenomenon. A little time on Google would've saved me hours of hair-pulling and I ain't got much hair to begin with. Of course, you have to know what you don't know before you can research.

I figured that I'd be breadboarding the bench test, throwing support electronics around the core as needed. In reality, once I decided on the display to use and got that working on a breadboard I saw that I needed to get onto a PCB. The motor control IC I wanted to use is a surface-mount device and I needed to run it full power in the early stages of development. No way to do that on your usual white protoboard.


These days, you can do PCB design and get a batch of boards made pretty quickly. I've been using OSH Park for PCBs. They take Eagle board files and turn them into reality for not a lot of money.

I'll continue on with the PCB design and schematic in the next post. Until then, "if you can hear it, it wasn't meant for you".