Roomba Scheduler - Cliff sensor failure apart from one!

[jasperpants]

Hi all,

I'm having an "interesting" problem with my Roomba Scheduler. It was working great up until a couple of weeks ago when it gave out the uh-oh, then 5 beeps(indicating cliff sensor failure).

It now just gives an uh-oh at switch on and no beeps.

I've tried a few things recommended on this site such as cleaning out the dust etc around the sensors, checking the wiring, checking the IR LED's with a camera, and also replacing the cliff sensor wiring loom with a new one but no joy.

On closer inspection with the digital camera I can see that the wall detection IR LED is lit on the side of the bumper, and the cliff IR LED at the same side as the spinning brush is lit also.

However none of the other three on the bumper are lit, or the one that sits above the swivel wheel. I'm assuming the ones that are out are all on the same circuit.

Doing the self test it does not pass on the cliff sensor test but I can stimulate the 3 other sensors with a remote control/virtual wall.

Has anyone any suggestions on how to proceed?

Thanks in advance

[Gordon]

...I've tried a few things..., and also replacing the cliff sensor wiring loom with a new one but no joy. ...

Why was that done? Did you know for certain that a fault existed in that harness assembly?

If you kept that old harness & cliff modules, some info could be obtained by de-mating the left-side plug so you can plug in the original harness and put Roomba into the self-test mode. See if the LEDs light up on the left-side of the old harness.

[jasperpants]

Hi Gordon,

I swapped out the harness assembly as I had read another post where someone had tried it and it fixed the problem. I was hoping that would be a quick fix and the Roomba could get back to work.

I put the original harness back on this morning and I get the same problem. Same LED's out, same "huh" from the Roomba and same result from the self test.

[Gordon]

...I put the original harness back on this morning and I get the same problem. ...

With that result, the fault is looking more like it resides on the main_PWB assembly.

If you have a voltmeter, preferably a digital multimeter, I can tell you what points to measure LEDs' drive-signals.

The fault almost has to be a faulty transistor. If that turns out to be the case you must decide to either replace it (it is one of the easier components to access and work on), or replace the entire PWB-asm. How's your electronic-parts soldering skill?

[jasperpants]

Yes I've got a digital voltmeter and a soldering iron. Not sure how good I would be at anything surface mount but otherwise I should be ok. I'd rather replace the transistor than the entire board.

Voltmeter at the ready!

[Gordon]

Yes I've got a digital voltmeter and a soldering iron. Not sure how good I would be at anything surface mount but otherwise I should be ok. ...

No sweat! We are looking at a TO-92 cased xstr!

FYI: Unless I say "your left, or right", I mean Roomba's left or right.

At the left-end of the PWB between jacks J1 & J3 you will see the xstr "Q4". It is this device that drives the three cliff-LEDs on Roomba's LH-side. Its three pins are connected to a column of pads. Look around to the forward face of the PWB to locate those same pads, and to also note that each one connects to a nearby, numbered test-point: TP#10 for the top-pad (Q4 collector, or Q4c), TP#9 for the mid-pad (Q4 base, or Q4b); and TP#8 for the lowest pad (Q4 emitter, or Q4e). Of course, you may touch either test-pads or xstr-leads while measuring.

Voltage measurements will be referred to signal-return, which I usually call SYS_COM. Look for a handy contact-point to it under the board's edge-clamp at that left (Roomba-left) end. It is TP#6.

With Roomba switched ON and ready to receive a clean-mode switch-press, you want to measure between TP#6 and TP#10. Set your DMM to measure AC, and less than 20V.

FYI, you will be using an ac-voltmeter function (a function that was designed to measure sinusoidal waveforms) to measure a 1kHz square-wave continuum, so can't predict what voltage-reading is proper. Make a note of the value, and we'll shift attention off to the RH-end of the PWB and repeat the measurement on that side's driver xstr, so we have a working-level to compare.

"Q37" is the same type xstr as Q4, and is the second TO-92 cased xstr inset from the RH-edge and near the board's top edge. Look on the board's FWD-face for TP#197, the Q37c TP.

You may either use the reference pad TP#6, or shift that probe to to the main SYS_COM TP#206, which is located about 30mm along toward the LH-end, and 15mm down from the top-edge. TP#206 is a column of three test-pads!

So, measure from either TP#6, or TP#206 up to TP#197 and note the value.

Both xtrs are driven by the same source, hence, both collector-voltage swings should be very similar. There is, of course the difference that Q4 has to drive three LEDs, while Q37 drives only two, but I doubt that will bother us much. It should be easy to detect that Q37's signal is larger than Q4's.

If you find that condition, you might also add to the measurement set by showing that both xstrs are getting the same base input swings. Do that by measuring from TP#6/#206 to Q4b, TP#9, then to Q37b, TP#199.

Report back, and we'll go from there.

[jasperpants]

Ok, the results are in:

TP#6 and TP#10 - 0.248v

TP#6 and TP#197 - 0.54v

TP#6 and TP#9 - 0.672v

TP#6 and TP#199 - 1.123v

So indeed Q37's signal is much larger than Q4's as you had suspected.

[Gordon]

Ok, the results are in:

TP#6 and TP#10 - 0.248v {dV_Q4out}

TP#6 and TP#197 - 0.54v {dV_Q37out}

TP#6 and TP#9 - 0.672v {dV_Q4base}

TP#6 and TP#199 - 1.123v {dV_Q37base}

So indeed Q37's signal is much larger than Q4's as you had suspected.

Yes, it looks like Q4 has lost a lot of its current gain, and is looking like an increasing load to its 100 ohm, series base resistor (both xstrs have those series resistances before connecting to the common signal driver). That is why dV_Q4base is half of dV_Q37base.

Based on those data, I thinks its worth a try to replace Q4 with a new "S8050". May as well buy a few -- shipping will cost more than the parts. Try Mouser.com or Digikey.com. The latter will ship via USPS Priority mail, so shipping is limited to less than $5, and you get parts in three days.

I've attached a pdf-format data-sheet. There should be numerous options in mfrs, and slightly modified leading characters of the part's ident.

[jasperpants]

Thanks for the info. I'll get a few on order and report back once I've swapped it out. Anything else I should be aware of before doing the work?

[Gordon]

...Anything else I should be aware of before doing the work?

Since I am not privy to your technical background, especially so far as functioning as an elex bench-tech, I could palaver on for a couple feet of text. However, I don't have time to spend on that, so I'll try briefly touch on a few topics, such as: odd materials/tools, PCB-preservation, and ESD-control.

1) Odd Materials/Tools: You may have to outfit your 'work-station' with some odd materials and tools which you may not ordinarily keep on hand. The following items come to mind:

a) rosin-based flux, electronic grade, liquid or paste.

b) small-diameter (say 0.020" to 0.032" dia.) wire-solder, rosin-core.

c) Soder-Wick?, or equivalent de-soldering aid.

d) Clip-on heat-sink (for new xstr installation).

e) Flush-cut side-cutters, smallest size.

f) Hand-lens, 10X power, or other optical aid to inspect repaired area for solder-shorts, etc.

g) 100% isopropyl alcohol, to dissolve (or thin liquid rosin-flux) used flux (i.e., clean up the re-work area).

h) "acid-brush", with bristles shortened to about 1/3rd original length (to apply item 1-g).

2) PCB-preservation: Roomba's main_PCB is a multi-layer construction, with at least three layers of copper, and possibly four. Layers are connected by 'vias' of plated-through-holes. Q4's three leads pass through such vias. While dismounting the duff Q4, you want to do everything you can to avoid damaging the vias, their pads, or traces to/from those pads.

If I had to remove Q4, my first thought is to simply cut the xstr-body away from its leads; and, leaving lead-stubs long enough to grasp with forceps while heating their individual pads. However, I can see that direct method may be ruined by the close proximity of the two adjacent jack-bodies. If your side-cutters are not slim enough, their jaws will simply not fit into the available space. To get around that limitation, I would then try to crush/crumble the TO-92 body (I have a small Vise-Grip pliers whose jaws will fit between the jacks, and apply tremendous force to the plastic body). The, with the plastic body out of the way, small side-cutters can finish the separation job, and de-soldering individual lead-wires will go much faster than sequentially heating the three pin-ends to incrementally 'walk' the xstr's leads out of the vias. More importantly, the removal stress applied to the PCB will be less -- both mechanically, and thermally.

3) ESD-control: Give Electrostatic Discharge Control due consideration. If you have had no ESD training, then google it for things to read. Fortunately you are not handling any loose MOSFETs during this re-work, but, it will still be prudent to behave as if you are. The ESD damage threat will depend largely on how low the % relative humidity is in your work area when you work on the PWB-asm. If RH is less than ~35%, you should follow ESD-Control rules.

Generally, those rules talk about "grounding" this and that, but, the very important element is that you, your soldering-iron-tip, the loss transistor, and the PCB-traces all be (essentially) at the same potential. Grounding everything does that, but when you give due consideration to *safety* it is the grounding of 120VAC-powered tools that demand everything be connected to the AC-power ground system. Do you know if your soldering iron is ESD certified?

One of the ESD-safe things to do when your intent is to pick up a dismounted Roomba PWB-asm, is to make your first point of contact the tinned shield-can surrounding the SCI's Mini-DIN connector. That shield connects to SYS_COM, and whatever your potential is, at that moment, is then applied safely to SYS_COM everywhere to shift potential on the "ground-plane", and you don't impart a discharge current through some ESD-sensitive component as that current tries to reach lower potentials. Once you have that shield in your hand, you can feel ESD-secure while touching any other part of the PWB-asm.

While you are working with the PWB-asm, and you need to leave the work-station momentarily, or even bend over to retrieve a dropped item, be sure to touch the shield-can before anything else.

4) Transistor Installation: Try to clamp a heat-sink onto the transistor-lead being soldered. Allow a little time between soldering of each lead, so the PCB can cool.

[jasperpants]

Hi Gordon,

Transistors arrived this morning. So I set about replacing the defective one.

It was pretty straight forward, however the same problem still exists! I'm going to check the voltages again to see if they are also the same or if there was any improvement. I'll report back in shortly.

[jasperpants]

Yup, voltages are the same as before!

Help....

[Gordon]

Yup, voltages are the same as before! ...

Unfortunate! Sorry to have put you through all that work!

In reviewing some of the prior information, you said:

...However none of the other three on the bumper are lit, or the one that sits above the swivel wheel. I'm assuming the ones that are out are all on the same circuit. ...

The "swivel wheel" had not registered with me. Yet, even though you say the LED in its rotation-sensor is not lit, I'm not convinced that condition is impacting operation of cliff-LEDs. One strike against its association is: not enough wires go to that module to permit both square-wave drive to its LED, AND dc-biasing of the PT and its signal extraction. Besides, that module's harness goes to J22 which is at the right-end of the main_PWB, and therefore close to Q37 (right-end, where it could easily join with Q37's network), not Q4, where the problem appears to be.

I have no swivel-caster Roomba or associated swivel-caster parts, hence, all my thinking & circuit info is based on non-swivel-caster machines.

Your best bet for checking that rotation sensor is to do Test#10. Hopefully, a passing result will come forth for it, and thereby disassociate it from the LH-cliffs' fault.

Back to Q4 and its two LEDs, I am going to replicate the measurements I asked you to do on your Scheduler. Both xstrs (of same type) use a common input signal, and your data are showing Q4 working hard to drive three LEDs, while Q37 easily drives two LEDs! Hmmm! I am seeing my erroneous thinking in that last sentence -- it IS Q37 that must work harder because it suffers a higher conductive current for a half millisecond, every millisecond.

I should be saying: "and your data makes it appear that Q4 is working hard to drive three LEDs (since the collector-signal is smaller), while Q37 appears to easily drive two LEDs! (because its signal is larger)". The signal IS larger because less voltage gets dropped across two LEDs (even though a little more current may be going through the two, than through Q4's three).

As I said in a prior post, I have a pencil-SK of the driver-schematic to view, and that makes it easier to visualize such action. i will try to show some dynamic waveforms to support that re-assessment, as well as data taken via DVM as you did.

There is some uncertainty as to when those data will be posted, but hopefully before midnight!

[Gordon]

Ok jasperpants, here are some intermediate data... the DVM measurements. Basically, just something to look at, until I pull together some 'words of explanation'.

Code: Select all

               Sched data            4220 data:

TP#6 and TP#10 - 0.248v, a.k.a. dV_Q4out = 0.985Vac; and 0.969Vac (2nd DMM)

TP#6 and TP#197 - 0.54v  a.k.a. dV_Q37out = 0.658Vac; and 0.643Vac (2nd DMM)

TP#6 and TP#9 - 0.672v   a.k.a. dV_Q4base = 2.63Vac; and 2.609Vac (2nd DMM)

TP#6 and TP#199 - 1.123v a.k.a. dV_Q37base = 2.63Vac; and 2.557Vac (2nd DMM)

TP#206 and TP#32 -......        dV_TP#32 = 2.66Vac (common signal point, to 
                                         100 ohm base-resistors for Q4 & Q37)
										 and 2.568Vac (2nd DMM)

                 -......        dV_6_206 = 0.009Vac (verifies little difference
                                         in measurements by referring to TP#206 
					                     instead of TP#6)
										 and 0.0053Vac (2nd DMM)

Reference-point check:          dV_probe-tip2RTN = 0.004Vac; & 0.0002Vac (2nd)

Operating Voltage:              simul_V_batt = 15.00Vdc

Notice that I repeated the measurement set by using a different DMM (different mfr & vintage). to ward off suspicion that the meter is doing something funky.

Two noteworthy items are: 1) the large & small values of these two measurements dV_Q4out and dV_Q37out have changed 'sides'; and 2) my 4220-data for dV_Q4base and dV_Q37base are nearly identical, while your Scheduler-data show a 2:1 difference.

Dynamic waveform (actual signals) data have been captured, but must be transformed to jpeg format to post. It may not be until the 13th that you see those data.

Those waveforms are somewhat boring since they are all of nice square-waves & identical frequency; and, only the magnitudes of the signals are of interest. Practically, I could show one image, then table the Pk-Pk signal values!

As of yet, I have no vision telling me where to point the finger of suspicion. I'm hoping that will come from understanding differences in real signals magnitudes coupled with the DVM-readings.

[jasperpants]

Thanks for the interim message. Looking forward to your deliberations.

[Gordon]

Thanks for the interim message. Looking forward to your deliberations.

Here they be -- but, as yet non-committal:

Related to this cliff-LED drive problem, the following data now exist:


[I'll attach a copy that can be resolved by normal vision.]
The data do not clearly point to a specific faulty component, but, illustrate that both left and right cliff-LED sets are not adequately powered. The right-side LEDs have enough drive to make their cliff-sensors function, but probably not optimally. The left side LED-drive power suffers so much that you report inability to see their glow via a digital camera.

Essentially, these data suggest that at least one additional signal voltage -- that on TP#32, which is the output of the preceding stage -- be measured. Unfortunately, TP#32 is hidden until the PWB is lifted out of its slot-cavity. Then it may be found located near the black-plastic housing that supports the left-bump-switch hardware. The test-pad is about 6mm offset from the right-face of that box --- to the right (Roomba's) -- and at about the elevation of the box's lower face.

If your measurement of that signal (V_Q44c) is not in rough agreement with a 2.6Vrms value, it would then be necessary to sample some points farther back along the signal train. Those would be: TP#40, 10mm farther right, then 10mm up (to read V_Q44b), TP#51, 6mm more to right and up 4mm (to obtain V_Q24c), and TP#41, 4mm below #51 (to obtain V_MCUout). The usefulness of the supplied offsets is totally dependent on the Scheduler's PCB pattern matching the 040911 vintage board that I've been working. If you decide to measure those points, I will do the same and expand the table to include those data.

Bear in mind that both Qs 44 & 24 are tiny surface-mount devices, which makes them tedious to R&R.

I should now talk about the tabled data. The talk can be divided into two categories: Precautions, and Commentary.

PRECAUTIONS:

1) All of the measured values are being displayed with more significant figures than they deserve. So don't put much trust in them. One glaring example is obtained by comparing V_PP levels shown in E4 & E5. If the pertinent schematic could be posted for view, it would be immediately obvious that E5 can't be greater than E4! E4 is the driving voltage into Q4's base-resistor, and E5 is the voltage of the driven base terminal -- it has to be less than the voltage at the input-end, else the Q4 xstr would not turn ON!

2) All "V(rms)" values have been obtained by using a DMM's AC-voltage function to measure a 1kHz square-wave (of various peak-to-peak [PP] amplitudes; and, two such waves are biased above 'ground' by many volts!).

3) Those ac-data, in (2), are intended to provide a relative-link between remote DMMs, one (or two) in California, and another in Virginia. Since we cannot know how those remote instruments respond to a signal-source for which they were not intended to be used, we can't depend on the ac-magnitudes to mean anything by themselves. However, their relative magnitudes within each of their robots should have meaning. Ratios of that type do not yet appear in the table. I'm assuming that to be fair, because of the quite large difference between columns D and I data. At the CA-side of the country, two DMMs, of differing makes, were used to measure the same signals. Reasonably well matched values resulted, hence, I'm not expecting much offset between east & west coast measurements of an identical 1kHz wave-train. The one caveat there is whether both DMM reading track well when sampling such a wave-train that is also dc-offset above ground.

COMMENTARY:

1) Cell-IDs are a handy way to point to any particular value or textual table entry.

2) Column D values are each the average of two different-make meter readings.

3) Column E values are peak-to-peak voltages obtained via digital oscilloscope (DSO).

4) In column F, the ratio of col-E to col-D, the ratio is expected to be nominally constant, and IS so for all square-wave signals that swing from ground to a higher value. The two that deviate noticeably, are collector signals that are smaller amplitude, and do not get pulled down to ground. It may be more due to the smaller amplitudes, than to the dc-offset, that causes deviation.

5) In column-G it can be seen that base, emitter, and collector signal-voltages have been sampled for the two LED-drivers Q4 and Q37. Transistor Q44 provides a common driver-signal to Q4 and Q37, hence only its collector signal has been measured.

6) The ailing Scheduler's DVM readings in column-I are so wimpy, as compared to column-D, that suspicion now points to Q44, or earlier points in the incoming signal-train.

[jasperpants]

Hi Gordon,

Ok, so here's my latest data:

Test 10 - Fails. So it's not picking up any rotation on the caster. I'm not seeing it light up either with the digital camera.

TP6 to

TP32 - 1.107
TP40 - 0.904
TP51 - 2.044
TP8 - 0.275
TP201 - 0.778

[Gordon]

...here's my latest data:
TP32 - 1.107
TP40 - 0.904
TP51 - 2.044
TP8 - 0.275
TP201 - 0.778

Greetings jasperpants, I have placed those data in a revamped version of the table. As before, the table data are sorted using column-G as key. Signal progression through the circuit, from the MCU's signal-generator, on out to driven LEDs, are then represented top-down in that column:

Comparison of TP 51 & 41 values start off really well, but the ratio of TP32s in row-7 (oops! clipped off row#s) show Q44 has lost ability to get its collector swinging!

Before just flat out saying "replace Q44", it may be wise to check values of Q44's collector-load resistance, check the two base input-resistors that connect Q44c to Q4b and Q37b, and check the emitter resistances for Q4 & Q37. To make those three checks, remove Roomba's battery, verify no residual voltage remains on any following test-pad, then measure resistance between the indicated test-points:

a) Resistance between TP32 and TP6/TP206 S/B ~27k ohms.

b) Resistance between TP8 and TP6/TP206 S/B ~62 ohms.

c) Resistance between TP201 and TP6/TP206 S/B ~62 ohms.

d) Resistance between TP32 and TP9 S/B ~100 ohms.

e) Resistance between TP32 and TP199 S/B ~100 ohms.

If those values test OK (no need to report their values), the only other thing that might provide comfort is to light up the three-LED string, to both camera-check each IR-output, and to measure string-current.

Lighting the string entails:

1) de-mating P24 (an unmarked plug) from J24.

2) Connect +V_test to the RED-wire's socket.

3) Connect the ORG-wire's socket to one end of a resistor of size: R_series ~ (V_test - 3.6) / 0.03.

4) Connect the other end of R_series to (+)Ammeter (expect much less than 100mA); and return (-)Ammeter to -V_test.

I just did that using V_test = 6.8Vdc and a 100 ohm R_series to obtain I_LED = 30mA. One LED, I viewed, was emitting. This check shows: 0.03 * 100 = 6.8 - 3 * dV_LED, giving dV_LED = 1.28 volts is more like what gets dropped across each LED (when I_LED = 0.03A). Note that our dynamic measurement results shown in table cells E9 & E12 permit computation of peak-current(s) which the LEDs experience. So, by dividing those (E9 & E12, nominally equal) delta-voltage(s) by 62-ohms (Q4 & Q37's emitter-resistors), we see I_LED_pk = 69mA. But, that is cool, since a 50% duty-cycle is limiting their exposure to over-heating.

BTW, a handy way to mfr tiny test-probes (to stick into the sockets of P24) is to use small-size dress-maker's pins. 0.021-inch diameter works fine. just nip off half-length of its sharp point (leaving some leading taper at the tip), dress off any burrs, then solder pig-tail leads at the head ends, apply some insulation, and you're done!

If you get around to thinking about R&R-ing Q44, let me know, and we can talk about it.

[Gordon]

In case any passerby is curious about the waveforms which exist in the cliff-LEDs driver circuit, I have attached some example data.

The top graph shows the source signal coming from U8, the MCU. This particular picture can serve for other signals that swing from zero, up to three to six volts, such as collector signals of Q24 and Q44 (IOW, their graphs would look very similar).

Under the top graph are three Signal Information windows that summarize various data which automatically is extracted from each scope-trace. These three cover U8-54, Q24c, and Q44b.

The lower graph provides dual-traces of Q4c (lower trace) and Q37c. These signals are unique in that their peaks reach neither the 15-volt (battery) supply level, or 'ground'. From the lower peaks it is possible to compute dV_LED as ~ 1.26V-Pk, no matter whether three LEDs are in series, or two (as for the RH pair, Rt-outer Cliff & Wall-Detector).

The bottom attachment shows two Sig-Info windows, one for Q4e & Q37e, and one for Q4c & Q37c. VPP signals in the emitter window may be divided by 62 ohms (emitter resistor for each xstr) to obtain peak currents experienced by the LEDs.

[Gordon]

Historical News!

jasperpants, thanks to a conversation with RmbaExch Chris, and a link he provided to a picture of the underside of the swivel-caster's sensor-PWB, I was triggered into to searching the RR-archive for a thread in which vic7767 discussed swivel-caster conversion of a Disco-Red. That is the thread which originally provided me with the information that that little PWB had only a three-wire pigtail attached to it, and that pigtail plugged into right-side jack J22 (which must have six contacts, rather than the original four). The outcome of that search is the following quotation, which explains additional (plug-in) wiring to the small PWB, and points out that the additional wiring connects the caster's rotation-sensor LED in series with the left-set of cliff-LEDs!

Another new discovery. There is an additional 2 pin connector on one side of the Swivel IR wheel movement detector. On a swivel equipped Roomba this connector is wired in series with the red lead of the top right pin on connector J24. I located a spare 2 pin connector that was used on an old Roomba wheel up sensor. This will be used to splice into the red lead of the orange/red pair on J24. Wheel rotation sensor circuit picture below. Right hand side shows 2 pin connector and green leads that will be spliced.

... which came from this post. Thus, we now have the answer to why that caster-LED is dark, along with the other three cliff-LEDs! This new info (that FOUR LEDs are being driven by Q4) also explains why the left-side cliff-LEDs are so dim you can't see their glow (via camera), while the RHS LEDs can be seen!