Turret Board Revision 4

Over the weekend, I updated the turret-board design and put in a new order to OSHPark. There was a lot of trial-and-error and aggravation, trying to figure out why my bread-board version of the Pixart camera was working, while my revision 3, with bodge wires added, still did NOT work. Turns out that I needed my oscillator to share a ground with the Arduino. This is still a weird kind of mystery to me and another one of those times when I wish I had a firmer grasp of the underlying theory. [Edit: Circuits need a common ground! This Stack Exchange explains it okay.]

After I figured out the oscillator situation, the camera seemed to work fine. It would occasionally stop working but I think that this was just due to bad connections. It would be nice to have a reset capability. Just having the ability for the microcontroller to shut on and off the power to the turret would be sufficient. This would only require the addition of a transistor to the main board. But it would require one more pin, which means that I would be down to one status LED. Or something else (speaker? rear sonar?) would need be sacrificed. Anyway, here's hoping that, with solid connections on a PCB, the camera will remain stable.

Speaking of stability, I have no idea how the microcontroller or power supply are going to behave, with three constantly-running cheap DC motors. Everyone says to have separate power supplies for motors and logic. I've stubbornly resisted, wanting the simplicity of only having 4 AA batteries. We'll see how it works, in practice.

So, after fixing all the camera stuff, I was eager to finish-up my board layout. But I forced myself to solder-up and test the remaining board, which is just the discrete circuitry for the IR transmitter, receiver, and beacon. Just two transistors, what could I have possibly screwed up? Well, turns out I used an incorrect component in the schematic, it was a BNJ junction but it had a different pin configuration. I only discovered this after some hours of frustration with different combinations of the PCB and a breadboard.

For my troubles, I earned a burn mark in the shape of 1/4 watt resistor.

After finishing the turret-board, which is just beginning to feel a bit like drudgery, I decided to hook-up my turret motor and two Hall-effect sensors. This stuff is a bit more fun, since I get to actually watch something happen, in a physical way, which was sort of the appeal of getting into micro-electronics in the first place. I had some concern that the turret encoder sensor would not work well, since I had to use pin-change interrupts and not hardware interrupts (hopefully, I used the correct terminology there]. The turret motor does not spin at some crazy speed, maybe 6000 RPM, which is 100 revolutions per second. The magnet attached to the motor shaft has 8 poles. If I capture both rising and falling signals that's 100 * 8 * 2 = 3,200 interrupts per second.

I did have some amount of trouble. Firstly, the interrupt library I was using was really outdated so I had to find another. Then it simply didn't work, for mostly stupid software mistakes that I made [like not setting the proper pinMode for my input pins]. Another issue was that I was using Arduino pin 13, because that is what pin will be used on the PCB. Well, the Arduino ties pin 13 to a LED on the board and this gave me some trouble, until I added a 100Ω pull-up resistor. I won't need this in my final design, since I won't have this LED.

Finally, I did get everything working and it seems to work really well! There is one sensor located underneath the turret, and a magnet glued to the turret. When the magnet passes over the turret, a signal is sent to the microcontroller and it knows that the turret is in its forward position. Thus, the turret is calibrated and each rotation of the turret motor is counted, forward or backward, and the microcontroller knows the position of the turret relative to the tank. Right now I am using degrees, though radians might be easier, from a coding perspective? I am only seeing something like 300 motor-rotation interrupts per second, not 3,200. Just from watching the Serial output and making a rough calculation, I ended up dividing the motor rotations by 24,000 to arrive at the number of degrees and this seemed to be roughly correct. No counting teeth or complicated math for me! I'm not really looking for an exact position, anyway. Every rotation the turret makes, it is recalibrated. If the degree figure is slightly off, it probably doesn't matter much. The point of having this figure is just so that the robot can make some appropriate action when detecting a target, such as driving toward or away. Since I do not have wheel encoders, pointing the robot in the direction of its turret is going to be largely, guesswork. It WOULD be nice to have wheel encoders. But, again, the problem is pin count. I suppose that I could move to an ATMega2560, for a slightly increased cost.

It's funny: When I first got an Arduino Uno dev board, the pins seemed excessive. Like, I never imagined I would be struggling to fit everything in. [I just looked up the specs for the ATMega2560: "has 54 digital input/output pins (of which 14 can be used as PWM outputs), 16 analog inputs". I'm practically salivating over here].

Speaking of constraints, I actually have no idea if the software that I have sketched out in my head for this tank will fit on the ATMega328. I assume that it will, as long as I don't crazy with the libraries, but it's another limitation that I have to keep in mind.

I made a Github repository for my robot software. I have been using a bunch of small programs to test various components of the robot, but I found myself re-writing the same routines. So it seemed about time to create a canonical version of what I hope will eventually be a fully-functioning Laser Tag Robot Tank.

Oh, another thing that happened: there was a mistake in my code such that it was reversing the motor every single loop. Well, the practical result of this was that the motor did not move but made a sad, barely perceptible noise. Also, the motor controller got very hot and then refused to work. But a few minutes later, after I fixed the software bug, everything was working okay! So that bit in the half-bridge datasheet about "blah blah thermal shutdown" seems to work well in practice! I'm happy that the electronics bits I've been playing with have been so resilient to all my mistakes, otherwise this would be a much more expensive learning process [as it is, it's still none too cheap].