Why does this one RoboClaw light red when running?

[jwatte]

Last year, I was having some trouble with Roboclaw 2x5A controllers detecting "overcurrent" and disabling, even when the motors driven had a stall current less than 5A. The problem was traced down to something that required me to send the claws in. I sent in all three of my 2x5A, but time was very close to when I needed the control, and I ended up re-purposing some 2x30A that I had from another project. The three 2x5A controllers came back all nicely upgraded, and have stayed in their anti-static bubbles until this month -- now I'm doing a new project that could use these controllers, again with motors rated at < 5A stall.

Two of the controllers seem to be working just fine, so far -- no overcurrent detected when starting up.
However, the third controller is behaving differently. Sometimes, when all the controllers are running at full PWM but without load (free running on the bench) this one controller stops with a lit red status light.
Even when running, the green and the red lights flicker on and off. On the other two, the green light is on solid with no red.

I thought that perhaps the problem was that running spikes would cause the motor to detect over/under-voltage. I hooked up a scope to the power distribution board that feeds this controller and two actuators, and got a 'scope picture. Here it is:



It seems OK to me -- some spikes are to be expected when running gear motors.

This is being fed by a 10A bench power supply at 12.0V; the actual draw of the entire system seems to be about 0.7A when this is running, and 0.35A when the system is idle (which includes a number of actuators, microcontroller, and the other two roboclaws, too.)

Here is a video of how the lights are flickering:

https://photos.app.goo.gl/qPGwtHHHXTaVy4vm2

As you can perhaps not see in the video, power to the RoboClaw comes from the distribution board it's mounted above; this board uses two solid 1oz copper pours and a number of 10A/200mil screw terminals. Into this board, power is fed with a 16 Gauge stranded copper wire. From this board to the RoboClaw, there is about 2 inches of 22 gauge flexible stranded silicone wire. (16 or 18 gauge won't fit into the screw terminals on the 2x5A.) The motors are in turn fed by about 8 inches of flexible stranded wire (same 22 Gauge) going to another board with 1 oz pours, which interfaces with the motor-and-encoders connector on the motor (which is based on 100 mil spacing pin headers.)

This same setup is repeated another two times for the other two boards, and those boards work great, without this symptom.

What could be causing this? How can I debug this? Is there a fix I can make?
If I had a fourth 2x5A I would try swapping it in, but I don't, and they've been replaced by the 2x7A in the stores by now. And I'd prefer not to run a heterogeneous setup if I can help it.


Edit: One more clue: When I run one of the other motor controllers, the "suspect" controller still flickers red/green, even if it is staying still.
Because those motors are further away, I see hardly any spikes on the voltage bus at the suspect roboclaw -- 100 mV typically.

[jwatte]

Disconnecting all wiring except power, this controller still blinks red when another controller is running. A scope on the power wire shows < 100 mV ripple.

Isolating the controller from the chassis ground (resting on plastic, only connected with power) shows the same thing.

Moving this controller to the power wire for another controller that works fine, again insulated from chassis ground, STILL shows the red blink when another controller is running. measuring ripple across the big capacitor on the board still shows < 100 mV ripple. At this point, I don't even have a good theory for what the board is picking up to even make it change the LEDs! Radio?

[Basicmicro Support]

Its a hard one to diagnose. Since its a very very old board and doesnt have the USB connector you cant diagnose it easily by using Ion Studio. You dont say(or I missed it) what the control method is. If you are using packet serial read back the error status while the problem is happening and let me know what the value is.

Also, I assume the firmwares are all the same but if you can double check this.

The flickering LED indicates either an over voltage/under votlage or an over current signal. There is a voltage divider fed off the main power connection which is read via A/D. if there is a cold solder any where in that line it could potentiall be allowing the A/D reading to float or do odd things which could explain the problem. Same applies to the current sense(eg theres the shunt resistor and a signal resistor(on the bottom middle of the board for each channel).

If I had the board in front of me I'd touch up all the components to see if that fixed the problem. But you cant do that with most hobbiest solder equipment. if you have a good soldering station and water soluble flux then I recommend you go over all the caps and resistors on the board if you feel you can.

My guess is the one board has a cold solder and worked when we tested it before sending it back but failed while sitting in the bag, during ship, when you pulled it out. No easy way to really know on that. Only way to confirm a cold solder is to touch it up. If that works then you know it was. Even probing all the components would necessarily tell you. Touch the lead of a component could make it bridge the gap and seem to be fine.

[jwatte]

Yes, I'm using packet serial. I'll read the status back and let you know tonight. The firmware is the same one that got installed when you had the boards last year (I read it back and verified when I opened the bag, but don't remember off-hand); I think version 4.17? I'll verify that tonight too.

I have a Weller solder station and some slim tips, but not hot-air rework. I may be able to find one, though, so I could try that. I also have a syringe of no-clean flux that's probably still good sitting in the fridge.

Which specific components go into the dividers? If I want to focus the heat away from the electrolytic capacitor, for example, it would be useful if I could hit the main suspects first.

[jwatte]

Also, I cranked the oscilloscope up to 100 us/100 mV per division and probed straight on the power capacitor on the board, and filmed it. It doesn't really show anything more than what I suggested already, but here it is for what it's worth:

https://photos.app.goo.gl/aNifp8A1uO2359GI3

You will note this is only connected through power, and the spikes seem quite minimal. (The video is unstable because I had to tell the computer to stop/go the other controller while filming; apologies!)
The other probe is hooked to the power bus where this board normally goes; this is taken while the board is free hanging, only connected to the power wire where one of the working boards is normally connected, to remove any chance of other stray signals.

Anyway, if I could know which specific components make up the dividers (other than the big fat current sense resistors; I can tell those by myself!) that'd be helpful.

[jwatte]

The data you asked for:
They are all running 4.1.17.
The problematic board reports 0x800 (main battery low) warnings when it complains.

... I will try setting the main battery voltage levels to something really low/high and see what it does.

[jwatte]

So, this seems to be a work-around:

Code: Select all

void setvoltage(uint8_t id) {
  unsigned char cmd[] = {
    id, 57, 0x00, 0x28, 0x01, 0x00
  };
  wr_claw(cmd, 6);
}

It sets the main battery range to 4.0V .. 25.6V, and then the claw doesn't complain.
If I can know which components specifically measure the main battery voltage, I can hit them with the re-solder, too.

My guess is one resistor is slightly different value on this board compared to the others, and LiPo auto detection ended up thinking 4S instead of 3S, and then the small ripple +/- 100 mV was enough to send it under the threshold. Or something like that?

[Basicmicro Support]

Unfortunately that model is so old I no longer have the layout files so Im not sure what parts are what. The resistors for voltage deividers though should be a 100k and a 4.7k. You should have two sets(one for logic battery and one for main battery). They will have a .1uf cap next to each set as well. 100k isnt used for anything else so you should be able to find it fairly easily.

Once you get reasonable voltage readings, I recommend setting the voltage range to the proper lipo range. 3v*cell count for minimum voltage is recommended. A lot of lipo protection circuits use 2.5v but under the loads the motor controller produces you have drained all the power by the time you hit 3v so 2.5v is just leaving room to damage the battery.

[jwatte]

Thanks for the answer!
I find that there is a little bit of voltage loss as the motors are running, because I'm using "good enough" but not super fat wiring in my distribution harness.
However, I have a separate microcontroller measuring the battery voltage where it comes in to the system, and this will turn off the LiPos before they manage to damage themselves, so I don't really need the roboclaws to duplicate this function for this particular system.

Btw, six individually sprung driving wheels, four individually steering wheels:


Clearly, still in development; no wiring looms or rain sheathing yet for example