This damn robot is starting to wear me down.
I etched another batch of PCBs and constructed the ones I needed urgently. The modified sensor breakout board went together pretty well and testing has confirmed that the bump sensors now work as expected. I also constructed a new sonar deck with a few tweaks to the design, including the pads for the voltage divider, mounting holes for the new HC-SR04 sensors and a couple of other options. This time I elected to use some 3mm amber LEDs on the sonar deck as I ran out of white LEDs, but the amber LEDs look pretty good.
The cable connecting the main board to the motor driver was a bit short so I stripped off the connector and made a longer cable. Once that was installed I modified the code for SpotX and loaded that up, making changes as needed for the pinouts of the new main board. Everything seemed fine until I powered on the motors. Nothing happened. I used a logic probe to test the state of the input lines and half of them seemed disconnected. I checked the Pic Basic code for the PIC and found that the pinouts were all wrong. In the existing code, the Pic was using the low nybble of port B as the input, but the new main board uses port A as the command input lines.
Once I reprogrammed the PIC and powered on again, none of the buttons seemed to work as expected, although the motors did run. I then realised that I had to re map the command codes to the new Pico output lines in the correct order so that the PIC chip received the same number on its input pins otherwise I would need some janky translation tables and confuse myself. I fixed that problem by reordering the assignment of Pico output pins into the command line list, so that the order of the Pico pins in the list matches the appropriate element in the command signal tuples at the same time compensating for the fact that owing to my PCB layout, the order of the Pico pins is not 1:1 with the order of the PIC pins, but hopefully all that’s sorted out now.
At some point in all of this, there was smoke again.
The new design of the motor driver board should prevent motor lockup, but only in the event that the PIC is protective in the signals it is sending. I added some code to ensure that the motors are turned off while the robot starts up and also changed the PIC program to turn off the motors that are not being used in the left/right turns. Until I did this (like, for more than a decade) the motors would be powered on and locked up on one side while the other side moved forward or back. Not very good. Actually, I haven’t had a chance to check that code, because of the smoke.
I thought that the smoke might not have been completely disastrous, but when I turned the robot on again I discovered that even with the anti lock up code, one set of wheels was locked up on power up. It even happened when I disconnected the control cable. With the pulldown resistors, all the motors should be defaulting to off. I figured one or more of the FETs had again blown so I pulled the board and tested each of the FETs. Sure enough, one of the Fets was short ciruit. I pulled it out and replaced it and on a hunch ran a continuity test over it again. It was still shorted. The board was fine, so that left the snubber diode. I pulled the diode and, yep, it was shorted too. So I replaced that. Now I have to put the robot back together, but maybe I won’t.
Maybe I’ll patch up the old burnt out board and set up a test rig so I can check my code without having to root around in robot guts all the time.