The Grind Continues

It's been about ten years since I first conceived of what would become Laser Tag Robot Tank (I'm still shopping around for a better moniker). There were a lot of stoppages and detours in that time. I put serious work into the project over two winters during Covid times. And then I've been working pretty steadily on it over the past year. All that to say, it's been a long time and I'd like to see something like a finished project. Sometime around Fall of last year I had something like a finished version. It did all the functions required and it seemed like the motor-driver issues that have plagued me had been resolved. I showed it around and everyone was duly impressed but when I mentioned that there existed two possible improvements of better batteries and a range-detecting sensor, everyone agreed that these things would be good additions. I didn't really want to but the project went in for another round of revisions. In the event, it was a good thing because the motor-driver problem had not actually been fixed.

I've forced myself to put off other Arduino-based projects until this one is fixed. And I really want to show this thing off. All this to say that there is a lot of motivation to declare it done. But I don't want to ship garbage.

So I added the distance sensor and migrated from four NiCad batteries to two 18650 lithium-ion batteries. These both ended up being pretty good improvements, I think. The battery update I think lessened issues with the microcontroller fuzzing out. The motors seemed less strained at 7.5 volts, over the 4.5 volts that I had before. But I was still having problems with the Arduino resetting, particularly after reversing the motors. I finally knuckled down and learned enough about my digital oscilloscope such that I was to set it to trigger and capture an anomalous event. This was the voltage supply to the board going up and down wildly as the motors stopped and then started again. All of which just confirmed that the power supply to the Arduino was getting messed up. I looked at the board layout again I ended up redoing most of the traces. The main improvement I think was just to add two sets each of a polarized 10 micro-Farad capacitor and a unpolarized 100 nano-Farad capacitor to the power lines before they get to the 5 volt regulator. I also added a 800 mico-Farad capacitor and put it as close to the ATMega328p as possible. I even changed the tank hull design a bit, in order to accommodate a 4,700 capacitor. However, testing seemed to indicate that this extra-large capacitor didn't appear to significantly improve the situation so I went back to the 800 uF cap, which was the largest that would comfortably fit in the current board design. I added unpolarized capacitors to the motor power lines, which the datasheet shows in its application diagram but I had been ignoring.

Anyway, after tweaking the main board several times, it seems like the problem with the motors resetting the microcontroller have lessened. I won't say that they have gone away because I have made that claim numerous times and I have been wrong every time. I found that keeping the batteries charged up helps prevent resets. There was also an incident where one of two seemingly-identical tanks had reset issues while the other did not. There was frenzied swapping of parts between the two tanks, attempting to isolate the problem. I never did fully figure it out but I think it can happen that a motor or gearbox can appear fine but internally have some issue to cause the microcontroller resets.

I had dusted off my old motor strain test sketch and I improved it a bit and ran the tanks through their paces. Now it seems I can run the motor strain test for minutes without triggering any reset. But, again, I'm not celebrating this time around. I've learned to be not be foolishly optimistic about things.

So, with the new batteries and a distance sensor and the motor-driver issues not currently bumming me out, I was well on my way to finalizing the last parts of the design. I hadn't been thinking that it was ready to demonstrate but then everything was coming together nicely so I hurried to finish the second tank, a red one. Things were looking pretty good the night before the demo, as I finished assembling the red tank. The blue tank had taken me a lot longer to assemble. I tweaked the hull design a little bit to make assembly easier.

I hurriedly wrote some code to make a combat robot. I wasn't sure it was good code but mostly I just wanted the tanks to aim for each other and shoot and record hits. They didn't need to be particularly clever. As I was putting the finishing touches on the red tank, I noticed an issue. The tank was registering a command from the IR remote for maybe one out of ten button presses. This is something that I'd actually notice happening before but I had dismissed it or forgotten about it in favor of other problems. Now, for a demo, it was important that the tanks register hits. Having built a Tank Target device (more on this in another post) and having that target device sitting next to my tank, I could see the target light flashing every time I pressed the remote button. But the tank did not register the signal. So there was no problem with the remote. I figured it must be a wiring issue, since it was intermittent. I pulled the tank apart. With everything apart, I used some test programs and the IR receiver seemed to be fine. Putting it all back together, it stopped working again. I used a raw IR dump sketch that comes with the Arduino IRReceiver library and I saw that, when the IR receiver was not malfunctioning, it was sending a lot of garbage data back to the microcontroller. Finally, by switching between various IR receiver test programs, I had another realization: the IR receiver only started acting up when the distance sensor was activated. This fact had been until this point obscured from me because it required a hard reset (removing all power sources) in order to fix the IR receiver. So: turn the distance sensor on and the IR receiver would start sending garbage data to the microcontroller (it still sent valid data, too, but it would take multiple signals to get through. Just holding the IR remote button down for an extended period was the best way to get the command to register). Reset the microcontroller by removing all power and the IR receiver would work again, as long as I did not activate the camera. So I knew the problem but wasn't sure of the solution. The Google chat bot suggested adding filtering caps to the IR receiver power lines. And this is actually shown in the application diagram for the IR receiver, which is a TSOP38238. As well there is shown a resistor in series with the voltage supply line. 

So I modified the turret board to add two capacitors and a receiver between the 5V power supply and the IR receiver leads. Now I have to wait for the boards to be manufactured and sent to me. In the meantime, I have a few tasks that I can work on. One of which is finalizing the design of the Tank Trainer device I mentioned earlier. Maybe I'll make another post dedicated to that.