Not Dead Yet

I've been working on this project and wished to post an update. I don't imagine this blog has a ton of readers but I was looking over old posts and reminiscing and thought maybe it was useful to keep track of progress, for myself if for nobody else.

I wanted to include some photographs and screenshots but that will have to wait for another post. Or maybe I'll come back and update this one.

I started blogging about this project in the Fall of 2017. I worked on it most of that Winter and into the Spring and then other things took hold. I bounced between Portland and Arizona and most of my stuff was in storage during that time. In 2019 I returned to Portland and I finally ended up living at a place with the space for projects. Up to that point, I had been purchasing remote-controlled tanks off the shelf and modifying them to be autonomous. I had a couple of parts custom-printed from Shapeways. There were several disadvantages to this approach but it was always going to be cost-prohibitive to get every part needed to assemble an entire tank printed on-demand by a third-party, even ignoring all the parts that would have to be printed as I iterated on designs. Anyway, in 2020 Covid hit and I was stuck at home like most everyone else and it seemed like a good time to pull the trigger on a 3D printer. I bought a Creality Ender 5, which was recommended as a good cheap printer by the nerds on reddit.com/r/3Dprinting.

So the work I did over the next two years or so was mostly on the physical design of the tank, though I still did some work on the PCB design and on the software. I don't have a great record of this period of development as I neglected to make blog posts. I'm through the related GitHub repos in order to remind myself what I worked on. I spent a lot of time in FreeCAD and, while I'm still pretty bad at it, I can at least make most basic shapes.

The tank is based on the Tamiya Double Gearbox Kit as well as their Track and Wheel set. The dimensions of those items inform the design of the tank. I also borrowed heavily from the design of the tanks that I disassembled, which gave me the inspiration for the turret design.

In early 2022, I moved out of the Portland house and into my own home. By that time I had a mostly-finished 3D-printed plastic tank, just needing a few revisions. Well, I should clarify that I mostly have only tested components of it. Nothing about it seems to NOT work but I have never assembled the entire product and subjected it to extended testing. It's entirely possibly that some parts of the design will not stand-up to repeated stresses.

The motor driver remained an issue, though. I had actually thought it solved and was wiring-up an entire tank to test out the software on when I did do some test and realized that the motor drivers still apparently reset the microcontroller after some seconds of use. This was deflating to me and I had to again box-up the entire project. I did think I would unbox it in the near future but I had no idea the projects that were awaiting me in my new house. It took about three years to get the house to a state where I am more or less comfortable inside of it so now I have time for fun projects again.

About six weeks ago, I pulled everything out of boxes. I spent some time organizing stuff and re-familiarizing myself with the project. I somewhat happily was able to quickly reproduce the motor driver issue I had experience just before pausing the project. It was interesting to look back and see that I had written a post about being frustrated by motor drivers way back in 2018(!). I'd like to think I've learned a lot about electronics since then but I guess maybe not enough to solve this issue. 

At some point during the Covid phase of development, I switched back to L293D drivers. They have a higher voltage drop than the TB6612FNG drivers but they still seem to work nearly as well and using the DIP package is much easier than soldering surface-mount.

I decided to order a circuit board with the Arduino, the voltage regulator, and the shift register. I ordered a separate board with the motor drivers. There was a header placement on the first board that connects to a header placement on the second board, with the various signals from the shift register and the ATMega328p going to the motor drivers on the second board. Once I received the boards and soldered on components, I connected the two boards using jumper wires.  The idea here was that I would be able to isolate the motor drivers from the microcontroller and would be able to easily intercept any anomalous signals between the two that might be causing an issue.

I had two possible root causes for my motor drivers not working in the single-board design. The Arduino power supply is dodgy and some current disruption from the motor drivers causes it to reset or the motor drivers are emitting some large amount of noise on the ground plane, enough to reset the microcontroller or get it into some indeterminate state.

In the event, the two board configuration worked just fine in driving three motors that were installed into gear boxes. I ran a test program that ran the motors for one direction for five seconds, paused 500 milliseconds, and ran the motors the other direction for five seconds. This was able to run seemingly indefinitely. The H-bridge that controlled two motors became warm, but not hot, to the touch of my finger.

Armed with that knowledge I pored over the faulty board design and found something I probably should have seen before: a logic supply line running right next to the ground plane and directly above another ground plane. I can't be sure that this is the issue but it seems like a likely culprit.

I redid the board layout, taking care with the regulated voltage line, trying to keep it as far away from the noisy motor-driver ground plane as possible. I found a neat feature in the KiCad PCB layout tool: Net Inspector. Using Net Inspector, I could highlight my ground or power wires and inspect to see if the layout makes sense. I made the ground wires in a star pattern, to avoid a ground loop. I did the same for my logic supply voltage, connecting the microcontroller with the other voltage supply at the power-supply capacitor, and not directly together. But I'm still an amateur when it comes to electrical design. What looks good to me may not be theoretically sound.

One problem I experience is that I want KiCad to treat logic ground and motor ground differently. I want the traces of each to be different width. But they need to be connected together, which makes them the same net. [I just Googled this and I guess using a "net tie" is the answer. I'll try this for the next revision.]

In the days since ordering the new revision, I've thought on the design and I already regret some decisions. I think I should have flipped the motor drivers around, which would have allowed me to isolate the motor current from signals better. 

Apart from the main problem of the motor drivers, I am doing some other revisions. I did some testing with IR signals and I recognized that having a constant source of IR light, in addition to an IR signal, doesn't seem to detract from decoding the signal. I guess the IR receivers must be able to filter the signal somehow. What this means for me is that the circuit I built from NPN transistors in order to turn the beacon off while the tank was shooting wasn't necessary. I also recognized that the protrusion that held the IR camera was an unneeded vestige of an earlier design. So I redesigned the turret board to be simpler, in a simple rectangle shape. Changing that meant that I had to update the turret design so I got the 3D printer out of storage.

I have some other revisions to do so I need to make new prints for the entire tank. None of that design will change drastically, however.

I'll post some more updates with details on the tank design or maybe some other aspects of this project.