Roomba 555 doing the circle dance

[latzka]

Hello everyone, hopefully this is the place to find some much-needed Roomba expertise.

I bought a second-hand Roomba 555 a couple of months back. The battery was dead so I replaced it and since it has done a solid job until today when it suddenly started acting up. By chance I was actually watching my Roomba do its thing in the hallway when it went wrong. Nearing a wall (= not actually hitting the wall) it started rotating to the left which I thought was another random change of direction. After 10 or so continuous spins, however, I realized that something wasn't right, turned it off and moved it to the center of a room. Upon switching it on the infinite spinning resumed until it stopped and reported error code 10 (dirty sensors/not seeing obstacles or stuck wheel).

I did a reset, put the helpless thing back in its home base and once again hit the Clean button.This resulted in an odd sequence of Roomba turning immediately to the left while backing up, stopping, switching the brushes on and then crashing back into its home base and docking as it tried to move forward.

The first conclusion was quite naturally that the wheel module had given up the ghost. So I disassembled the left wheel module and tested it with a 9V battery. Much to my surprise, the motor ran just fine in both directions and there seemed to be no loose wires either. As I put the wheel module back into place I had my Roomba standing on its tail and I tried turning the wheels manually and tested the suspension travel when more odd things happened. A small piece of metal dropped from somewhere (see the horrendously low-quality photo attachment). It looks like a some sort of a connector piece but I've got hard time figuring out where it could've come off from.

Since I had the robot disassembled and the error code included a bumper sensor fault I decided to give it a thorough cleaning with some canned air. While at it, I also used a camera to verify that at least all of the IR emitters were working.

Unable to find an apparent reason for the malfunction, I rebuilt it and hit Clean. Weirdly enough, it started up perfectly normal and ran for something like 15-20 minutes before entering the spin again after the left wheel once again lost all drive in almost the same spot as before. After another cycle of disassemble-clean-reassemble it seems that the condition is now terminal. No drive at all in the left wheel under any circumstances.

Anyone want to hazard a guess what's broken?

Is there a way to use the built-in diagnostics in this model by the way? I found some instructions online but they don't seem to work as advertised. Unfortunately the demo mode seems to be omitted from this model so I can't use it either to see if the wheel module is working.

[vic7767]

The 555 model Roomba contains the same Built in tests as all the other 5XX models. The component that has broken and fallen out of your wheel module is the activator arm that is used to send the wheel up/down info to the MCU.

[Gordon]

...Anyone want to hazard a guess what's broken?

Well, vic identified the loose part, so in effect the wheel-down/up switch is broken.Yet it might just get fixed by re-assembly. Read what MikeW did to fix the same fault: viewtopic.php?p=109660#p109660

[latzka]

Thanks guys!

I'm going to see if I can at least temporarily fix the activator arm and running some BiTs is still on the to-do list as well. I'm just a bit unsure if that'll explain the circle dancing behaviour as the vacuum was briefly running normally even with the activator arm completely gone.

EDIT: Small update: I managed to get the micro-switch re-assembled. The arm itself seemed to be intact with the end of one of the legs acting as hinges slightly bent. I straightened it up and with the help of pliers and a flat screwdriver installed it back into its place in the micro-switch assembly. Clickiness is back.

No effect on the circle dance though as I expected. Roomba just circles a bit forward, a bit backward (probably trying to do a turn here) and then racing anti-clockwise with different speeds until sounding the "Uh-Oh" without additional beeps and reporting an error 10.

[latzka]

Ok, found the right instructions for the BiTs. It fails tests #12 (left wheel) and #14 (left wheel encoder/motor current). I guess this strongly suggests that I should go shopping for some wheel modules? Are there any other possible reasons for the left wheel failing in such way? Just asking because from the 9V battery test I know that the motor itself is intact to at least some point. H-bridge?

Bumper tests and sensor tests pass, although the outer light touch sensors test suggests that my Roomba is a bit cross-eyed.

BiT #16 didn't lit the DOCK light for some reason although the main brush spun backwards and then forwards.

At least the wheel drop fix works as it passed test #8 with flying colors.

[mfortuna]

The 9V test won't tell you if the motor is pulling too much current but I would suspect a 9V battery wouldn't work if the roomba could drive it. If the motor doesn't spin at all under BITs then I would expect the encoder test to fail since it can't pass if the wheel doesn't turn.

So things seem to point back to the H-bridge. If there was someway you could connect the right motor to the left side (or vice-versa) you could verify if it was the motor or H-bridge.

[Gordon]

Links to other reported 5XX (R3) drive-wheels' H-bridge data:

{posted shots of 5XX's LftWHl & Main-Brush H-bridge H/W}
viewtopic.php?p=64271#p64271

{posted a sketched region of R3's LHS wheel drive H-bridge H/W}
viewtopic.php?p=92759#p92759

{posted 5XX Left-wheel Motor H-bridge data for rangatanga}
viewtopic.php?p=94579#p94579

[latzka]

Thanks again.

I've got some basic electronics knowledge but I'm not that familiar with measuring transistors. Is there a way to use a ohmmeter for that purpose while the transistors are still connected to find out which one has failed (by comparing the values to the ones on the right side H-bridge for example) or do I need to do something like disconnecting the base lead?

[TechGuy]

You can use a ohm meter to find out which transistor fails.
http://www.allaboutcircuits.com/vol_3/chpt_4/3.html

The H-bridge consists of 2 PNP and 2 NPN transistor. I tested them without removing them from the circuit board. When in doubt, compare the reading from the other H-bridge.

[latzka]

I measured the transistors with an ohm meter and they seem to be ok. B-E, B-C and E-C no matter which way I probe them give the same readings as the ones on the right side H-bridge.

I'm running out of ideas.

Are there any other transistors driving the ones on the H-bridge?

[TechGuy]

Re-do the BiT.
Is the left wheel rotate backward and forward?
Is the left wheel rotate the same speed as the right wheel?

[latzka]

I'll re-do them as soon as I get the thing re-assembled. I sort of got curious of the construction and pretty much tore down the whole machine into bits and pieces.

The first time I did the BiT the left wheel didn't turn at all either direction (in BiT #12 and/or #14). There's no difference in resistance when rotating the wheels manually.

I'm betting on a short/loose connection somewhere else than the H-bridge, dying MCU or then there's something wrong with the wheel module despite it running on 9V power.

[vic7767]

Check and see if the small magnetic disc is not broken or missing from the drive wheel.

[latzka]

The disc is in its place and in one piece.

Also re-did the BiT, same results as before meaning no drive on the left in either direction.

[latzka]

The wheel module itself is fine. I took it apart and did what mfortuna thought of earlier. Some creative moments with adhesive tape and I managed to plug it into the right side wheel well. Ran the BiT #13 & #14 and it runs both directions just fine.

It's something on the PCB or the MCU then.

[mfortuna]

It is interesting how H-bridge related failures seem to be happening more on the 500 series than on the earlier 400 series. I don't recall many H-bridge failures on older models. Not sure if there was a change to the circuit or to the devices.

[Gordon]

It is interesting how H-bridge related failures seem to be happening more on the 500 series than on the earlier 400 series. ...

Not only that Mike, but the three failures reported in my post yesterday are all that I am aware of; and they are ALL ON R3's LEFT WHEEL drive circuit !

[TechGuy]

The cause for all these 500 series problem (my guess) is due to water getting inside from the top. The lower half of the motherboard has a plastic sheet cover the circuit. The top parts of the motherboard consists of motors(wheels, brush) driving circuit, the 5V Buck Converter and the battery charging circuit etc. When the top part gets wet, say goodbye to the motherboard.

I don't have a 700 series Roomba. I am wondering how much water proofing was dome to prevent water entry.

[vic7767]

I don't have a 700 series Roomba. I am wondering how much water proofing was dome to prevent water entry.

None. In fact with the addition of the touch panel that the 780 has, there is major potential to suffer water damage.

[Gordon]

...Are there any other transistors driving the ones on the H-bridge?

Indeed there are. Four can be seen on the partial H-bridge sketch provided (as a link) to you yesterday. Here is a copy of it taken from post: viewtopic.php?p=92759#p92759

By this time it should be obvious to you that the sketch is showing solder pads on the top side of the main_PCA, and all the dashed-lines indicate component cases beneath the board -- actually they all are leaded through-hole mounting devices.

Transistors, (xstrs), Q72, Q73, Q87 & Q88 are necessary to control the four power xstrs that form the bridge. Perhaps two of them are more critical that the other pair. I do not have that detail for Roomba R3, but I do for Roomba R2. To view the R2 bridge circuit simply search this rr-board for schematic2.

In R2's schematic2 one can see a pair of smaller xstrs, just outside the H-bridge central area, that serve a signal splitting function and also a signal buffering function, since the MCU's driving capability is too wimpy to directly drive bases of B772 and D882 power xstrs. By studying either splitter xstr, say Q31 (upper right) one may see that when signal voltage on its base goes HI it makes Q31 turn on (i.e., emitter and collector currents flow). Emitter current through resistor R118 creates a voltage signal on node #120, thus causing current to flow through resistor R130 and into the base of NPN xstr Q28 which turns it ON.

Back over at the collector of Q31, the xstrs HI base voltage causes collector current through R119 to develop a base voltage on PNP power xstr Q27 that is low enough to make base current flow out of the xstr and turn it ON.

With both Q27 and Q28 conducting collector current, that current courses through the motor, "M", and the motor is expected to drive its wheel in reverse (opposite to the green "Forward" arrows in the drawing).

Notice that Q30, at right in schematic2, must be held OFF for the above to happen -- so the MCU pulls Q30's base down to near zero volts.

But if R2's MCU commands FORWARD wheel rotation, it is expected to first command Q30 fully ON to clamp the base of Q31 to just a few tenths of a volt greater than GND, an action which prevents Q31 from erroneously turning ON.

Back to the R3 circuit now. It has four outlier xstrs shown 'wrapped around' the H-bridge components in the above sketch. I can only think that two of those provide split-voltage drives to bases of the power xstrs, and the remaining two (TO-92 cased) serve in the same manner as R2's Q30, to clamp low one or the other splitter bases (to safely hold OFF the side that must remain OFF).

Now, with that introductory material behind us, I suggest that you shift from resistance measurements on those bridge components to voltage measurements while running the several wheel-drive BiTs. The goals would be to:

1) Verify that a pair of PNP/NPN power xstrs have their base voltages lowered & raised, respectively, relative to PCB-GND for one commanded drive direction.
2) Verify that the other pair of PNP/NPN power xstrs have their base voltages lowered & raised, respectively, relative to PCB-GND for the inverse commanded drive direction.
3) If improper base signal is found on any power xstr shift the voltage test point to the relative splitter xstr's base to see that the MCU is passing an inverted signal to it.

If you learn that the MCU is driving a splitter correctly, but the splitter does not drive the PNP/NPN pair correctly, you have a fair chance of fixing the main_PCA.

If you learn that a properly driven PNP/NPN pair fails to pass current through the wheel motor, you have a fair chance of fixing the main_PCA.

If you learn that the MCU fails to output any of the four necessary control signals to H-bridge components your main_PCA is toast. IMHO, that is.