Good news, bad news… and an observation about the universe.
TL;DR, Broke something. Fixed something and came out on top. No matter how bad things seem to be here, just remember, its probably much worse in other universes.
Good news:
But the motors seemed too weak. A bit disappointing so I tested feeding them 24V, figuring that if I burnt out the motors I would just buy 24V ones as replacement as the 12V motors aren’t of much use if I can’t actually use them. It definitely ran better… stronger… at 24V but something went wrong with the encoder and the main arm kept moving and slammed into the front of Floyd’s torso and kept trying to run… then there was the snap…
Bad news: Broken Arm Member
An observation about the universe (sorry longer than I intended):
Sometimes a setback gives you an opportunity to take a big step forward. I decided to tear down the arm to extract the 12V motors and try some bench testing with them to see how they ran at 24V without risk of destroying Floyd. Turned out they ran really crappy.
The TI motor drivers I use have configurable over-current protection where it can be set to ‘chop’ the output if current exceeds a certain level. You feed the chip with a reference voltage (I use a pwm pin of my teensy 4.1 through an RC circuit to generate the voltage) and its used by the driver as a point of comparison to its built in current sensing circuit. The sense current is also sent to an output pin in which you can convert to a voltage with a resistor to ground (remember this resistor for later) so you can read it on the mcu. The chip also drives a fault pin to ground when it enters current-limiting mode. I had included all these pins in the pcb design, so I added their monitoring to the firmware and noticed I was regularly getting faults coming in even when current limit is set to a high level and testing was done at slow speeds with no load… not many faults… 1 out of 20 samples… but regularly like clockwork. I put an oscilloscope on the fault line and the output to the motor and noticed the faults coincided with the leading edge of the PWM pulses sent to the motor… and occasionaly on the trailing edge as well. I then switched the probe to the current sensing pin and saw spikes that seemed to coincide with transitions of the PWM signal:
Those spikes were apparently high enough to exceed the reference voltage and kick in the chopping mode… and when I tried to run the motor at full speed I noticed even more spikes and faults… the current wasn’t near the limit and it was just the transients were tricking the driver to think it was. If I couldn’t run the controller at a decent current level because of these spikes, I was screwed.
Reading through TI’s datasheet I spot a statement to the effect that if the current sensing built-in deglitcher doesn’t work well enough, to put a 10nf cap on the line to smooth it out. Obviously, I didn’t want to spend money on another set of boards just to squeeze in a single cap… I already had to fix an issue and get a new batch a few weeks ago and didn’t want to spend the money yet again. While staring at the board to see if I could somehow bodge a cap to ground in the very, very impossibly tight space, I remembered the resistor I mentioned earlier… a 0603 1.5K ohm resistor to ground on the same line… so I did “something crazy enough that it might just work” and soldered a 0603 10nf cap on top of it. To my surprise, not only was I able to do it as my soldering skills are fairly weak, but it actually worked.
Of course that begs the question as to whether or not the motors are actually too weak and perhaps it was just the current limiting cutting in. Regardless, I now have a MUCH better motor controller and perhaps only because I broke Floyd’s arm.
I mentioned this particular controller was from the second batch. On the first batch, I was trying to wrangle a board into a case I printed and somehow pushed too hard against a cap and it popped off and took one of the pads with it (the one that ties the cap to ground). I tried to resolder it but couldn’t… I kept scrapping around the pad to find the ground plane only to discover the entire top layer ground plane was missing. Somehow between running my last DRC and generating the gerbels, I managed to delete the ground plane. I had been using a mouse with a left button issue and when I was readding the ground plane, I ended up deleting it again… so I put the mouse in recycling and got a new one. With that said, had that cap not popped off, I might have never realized the ground plane was missing.
…and finally the observation:
To put things in perspective, I very well could have been banging my head for weeks trying to figure why the motor controller wasn’t working… either with the first batch (nothing would have worked without that ground plane) or the second batch trying to figure out the right PID settings only to be confused by current limiting kicking in erroneously and not noticing it. If the multiverse theory is correct, I suspect I would be doing just that in a vast majority of them. So, to me, I’m pretty damn lucky to be living in this particular universe. First, I pop a cap and learn the motor controller didn’t have a ground plane and second, I break Floyd’s arm and realize I had transients that were causing the controller not to put out full power. Both issues could have been a source of endless frustration.
What’s the odds that two specific failures happen that fortuitously lead to discovery? Pretty slim… my suspicion is that most all universes suck and this is one of the rare good ones.
PS: There’s probably some other universe out there where I’m typing this message talking about how lucky I am to be in a universe where I accidentally discovered three issues with the motor controller and how fortunate I am not to be stuck in a crappy one where I only discovered two of them. Though it would be nice to live in that one, maybe in that universe everything is on a cob.
, maybe it’s using a bunch of elusive Raspberry PIs? Or pricey lidar sensor(s)?