Roomba Scheduler - Cliff sensor failure apart from one!

The very latest news and updates for the iRobot Roomba robotic vacuum, the Scooba Robotic Washer and the Dirt Dog workshop sweeper. All discussion and troubleshooting questions go here.
jasperpants
Posts: 12
Joined: July 9th, 2008, 1:05 am
Location: Virginia

Post by jasperpants »

Gordon, on the 16th, you recommended doing two more trouble shooting operations. First were these resistance checks:
Gordon wrote: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.
...and, the second thing was to "light up the three-LED string". After you discovered (revealed in your 17 July post) that the LED in the caster-wheel rotation sensor is also wired in series with the left-cliffs LEDs, that string count jumped from 'three' to 'four' LEDs in series.

I am happy to report that I did the measurements of the resistances on the PCB. With rounding my values come in directly in line with yours.

However, I'm a little confused with the lighting of the string. Is the connection the red wire is attached to a voltage source? Or is it purely the beginning of the string of LED's and I need to get a voltage onto that?

I've inserted a picture of that plug's wiring so you may see how the red pair merges with the cliff wiring.
Attachments
DSC03313LoRez.jpg
DSC03313LoRez.jpg (156.03 KiB) Viewed 19203 times
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

Good job on those resistance checks jasperpants, since those results suggest the fault is now more likely in a xstr, or possibly a bad solder connection.

Regarding lighting the string: the RED-wire stuffed in P24[1,1] is the anode, ("A") of the caster's LED (getting to the anode via the two-contact connector on that tiny PWB). The cathode, ("K"), of the caster-LED connects through that two-contact connector to reappear as a 2nd RED-wire (both are GRN in vic7767's pix!, so your Roomba is different), which should go to cliff-LED_lft_rear-A. Wire color changes to WHT (in older Discos) between cliff-LED_lft_rear-K and cliff-LED_lft_front-A. Continues as WHT, from cliff-LED_lft_front-K to cliff-LED_right_front-A. That's the fourth LED, so cliff-LED_right_front-K comes back to P22[1,2] via an ORG wire.

Note: The "[a,b]" nomenclature that I use will be a mystery until you understand how it is defined in the Reference Info section of this page

Raw battery voltage is normally presented to the string via contact J24[1,1], the top, right (yours, when viewing the J24 connector) pin. You may verify that by measuring resistance between J24[1,1] and TP207 (way over at the right (Roomba's) end of the board, and just above J7). You can further check that TP207 connects to the V_batt_pos connector blade.

So you see, there is no voltage source in that string. You must power it. The plus terminal of your voltage-source must connect to that P24[1,1] (RED wire).

When all is connected, and Roomba runs in a cleaning-mode, it is Q4 that yanks that final cathode down, closer to ground (every millisecond, for 500 ?s), thus completing the circuit from V_batt_pos to V_batt_neg ('V_batt_neg', for practical purposes).

There is also no current-limiting resistance in that string, and that is why you must provide some external resistance when using a test-voltage to light the string. Since there are four diodes, each of which drops ~1.25 volt, the test-voltage must be larger than 4 * 1.25 = 5V.

Let me know how the LED-show goes.
jasperpants
Posts: 12
Joined: July 9th, 2008, 1:05 am
Location: Virginia

Post by jasperpants »

So, I gave a go at lighting up the chain of LED?s and had a hiccup.

On first attempt nothing lit. I used a 6v power source, 100 Ohm resistor, and hooked up to the connector sockets. No light from any of the LED?s.

I checked the voltage at the pins, post resistor, and got 6.3v. At the red wire connection to the caster board 6.3v, at the other red wire connection: open circuit.

So, I tried bridging the sockets in the 2 pin connector with a wire-jumper, and voila the other 3 LEDs lit!

So, should the caster LED have lit?
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

jasperpants wrote:...I tried bridging the sockets in the 2 pin connector with a wire-jumper, and voila the other 3 LEDs lit!
Very good! And that points out that the fault is on that caster-board!
jasperpants wrote:So, should the caster LED have lit?
Yes, indeed! At least it should have for the test in which the two-contact plug was mated to its jack.

There is something funky on that little board. Your above, bottom-side pix shows two // traces leaving the jack-pins to head straight over to LED "D1". You can test around the jack and its traces by driving D1 directly with a test-voltage.

Do you have any other resistor values? If not you'll have to come up with a test-voltage of V_D1_test = 0.03A * 100 = 3V. Do you have a couple dry-cells you can hook in series? If so, use one of your three hands to hold the camera so it views the LED, then use the other two on the probes of the 3V PS + 100 ohms to touch the top-side LED pads; OR, using only one hand, mini-clip the test-apparatus to the exposed legs of the LED, then camera-view it.
jasperpants
Posts: 12
Joined: July 9th, 2008, 1:05 am
Location: Virginia

Post by jasperpants »

Big news here: The Roomba is back from the brink!

I managed to light the caster-LED by applying a voltage directly to it, however I could not get anything through its connector-pins and traces.

So I started buzzing out the connections as you had suggested and I could get continuity to the leg of the LED but not the return circuit. So I finally decided to remove the foam from between the legs of the LED and PT to have a closer inspection to see where the trace went.

Well, needless to say, you can see the mess for yourself under there. Pic attached.

It looks like the via has rusted through hence no connection is getting from one side of the board to the other and in turn onto/into the leg of the LED so the circuit is broken.

So, I scraped around for some thin wire and made a new connection, as the pad was beyond the repair of my skill and equipment at hand, see pic.

After that it buzzed out ok so I tried a quick hook up to see if the Roomba would not give the uhuh when I pressed clean. And of course it burst into life as if nothing had happened!

All the LED's are lit now. The little bot is raring to go. Programmed for 7am in the morning, there's a lot of catching up to do on our hardwood floor.

Many many many thanks for your help with this. I can't begin to thank you enough.
Attachments
DSC03333-2LoRez.jpg
DSC03333-2LoRez.jpg (290.53 KiB) Viewed 19296 times
DSC03336-1LoRez.jpg
DSC03336-1LoRez.jpg (154.02 KiB) Viewed 19303 times
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

Great job of applying the band-aid!
jasperpants wrote:Many many many thanks for your help with this.
You are quite welcome. I learned a few things, and that is what I like to do -- as well as see an ailing robot pulled back from the edge of a land-fill.

You and I might just be the resident experts on the swivel-caster's sensor assembly! :-) Next time through a faulty (swivel-type) caster-wheel's rotation sensor may not take as long to isolate the problem! I'm betting there's a bunch more latent swivel-PWB failures lurking, just waiting for corrosion to etch through (or whatever) to cause an open-circuit!

One lesson I learned during this 'project' is for me to not be so quick to blame a driver-transistor, when the driven circuit contains several LEDs and many connections. I am just now able to put 2 & 2 together to discuss why Q4 and Q44 were made to appear faulty by that open-circuited LED-string -- when they were not!
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

Jasperpants is happy, now that his Scheduler is sweeping floors again, but, Why is it that no one is asking about the transistors that I early on claimed appeared to be weak? Did they 'heal' themselves?

No, they didn't need to be healed, or replaced, they weren't broken; answers the latter question. And, the answer to the first question could very well be: Not enough electronikers are critiquing these threads. Maybe none at all! I could very well have been just talking to jasperpants, and myself, throughout this thread!

Roomba-5XX owners (or their out-of-warranty repair person) should probably pay attention to the culminating technical information in this thread, because there is no reason for iRobot to not have copied 4XXX cliffs, wall, & caster-stasis circuits onto the 5XX's main_PWB asm! Only the names of the 'players' will have changed.

I'm just going to continue talking to myself, now that I have recognized why those Q4 and Q44 transistors were made to look bad; and perhaps, some future traveler, wending through the RR-archives, will come upon this post and won't fall into the 'hasty conclusion' trap!

Repeating the 'question', what caused those transistors to appear degraded? The short answer is: Transistor Q44 looked to be in trouble because Q4's output-load (the LED-string) was not connected! That missing load creating an impedance mis-match which then over-loaded Q44. Under that duress, measurement of Q4's signals became meaningless. (more on this, shortly)

If any 4XXX, with swivel-caster, owner runs into the symptoms of dark left-cliffs' LEDs, and dark swivel-caster (statis sensing) LED, the prudent testing is to first power-test that string of LEDs. Once that collector-load is known good, then worry about the behavior of its driver xstrs.

Advice is identical for Q37's two-LED string for Roombas right-side (outer) cliff & wall LEDs; as well as for left-side cliff-LEDs on non-swivel caster 4XXXs; however, the latter two zones do not employ the extra LED and its assembly design (i.e., PCB-mounted LED), which apparently weakened the swivel-caster's LED connection, hence, such open-circuit failures in non-swivel caster Roombas may be much less likely.

Further elaboration about this impedance mismatch, can now be discussed.

Some graphic aids have been assembled to support this discussion. One is a schematic diagram showing just the cliffs', wall-sensor's, and swivel-caster's LEDs' driver circuit. I call this diagram a "partial" Schematic_12 {Schematic12,Schematic#12}, because it does not incorporate the detector portions of each of those sensors. The partial schematic is shown next in the required small image size, but a more readable size has also been attached:
Image
This version also lacks connectivity information that can aid trouble-shooting, and that is unfortunate here because this sensor-group wiring is the most complex set within the 4XXX Roomba. Jacks J2, J8, J24, and the Bumper-jack J1 handle portions of off-board interconnections to corresponding remote sensor-heads. i believe no other Roomba sub-system requires that many connection interfaces!

A full Schematic_12 version will span an estimated four pages, to not only show associated photo-transistors, (PT), (the detectors which all seven LEDs illuminate), but will, in part, be a 'wiring-diagram' that shows wiring from plugs to remote sensor-modules.

The above schematic was drawn using a CAD, electronic-simulation program. Simulated circuit behavior will be shown at the end of this post, but, before viewing output data, it is important to have some notion about "input" data, to wit:

Other things about the schematic:

a) All part-labels and resistor values are those seen on the 2004-vintage main PCB / PWB-asm. The off-board LED device numbers are unknown, therefore visual-red LEDs, instead of 940 nm IR-LEDs, had to be put in the schematic to support signals' simulations. Simulations are then less-exact, but still show the devastating impact on circuit-function when one string of LEDs goes open-circuit.

b) A test-switch is shown in series with Q4's LED-string, but, that switch is not a real component. The normally-CLOSED switch will be set OPEN to simulate a disconnected LED-string.

c) Values of capacitance are unknown, however, the values shown were obtained by adjusting their simulated values until the circuit 'worked'.

d) Diode D28's P/N is unknown, and that is considered nonessential to the simulation; its just a voltage-clamp. SMD xstrs Q24, and Q44 are shown correctly. TO-92 cased xstrs Q4 and Q37, which are SS8050 types, are not in the simulator's database, so have been emulated by using the model of a nearly identical transistor -- the ZTX450.

e) A 50% duty-cycle, 1kHz, zero to plus five-volt stimulus signal is provided to the driver-circuit via the MCU, (micro controller unit) pin 54 of U8. Schematically, this signal source is simply shown as a simulated signal generator.

f) Q24 and Q44 are powered by Roombas +5VREG buss, while the output drivers Q4 and Q37 pull raw battery power through all the LEDs. V_batt was fixed at +15Vdc, for these simulations.

g) Note that Q44's output is dc-coupled to both output drivers, hence, if one output-driver is placed in a stressful mode, that stress will be reflected to the other driver, and also to Q44.

Under the above conditions, and with the indicated substitutions, two simulations were performed, one in which all LEDs were normally driven -- thus simulating normal operation, and the second was done with no collector load for xstr Q4 -- thus, emulating the fault in jasperpants' Scheduler.

The format of a simulator's output can look like that from a multichannel oscilloscope. See such multi-signals in this next image...
Image
(which is also repeated in a larger image as the middle attachment, below)

...sample wave-forms from signal-points labeled on the schematic. All signals, except for the base-drive (V_Q44b) into Q44, are nominally 5VPP, in magnitude, and with flat top and bottom peaks. Only the signal "V_Q44b" requires a smaller total scale-range (of three volts). The test-switch is closed, so these data represent a normally operating cliffs', wall's, and (if present) swivel-caster stasis' LEDs' driver circuit.

A click of the test-switch sets it OPEN, thus making Q4's load infinite resistance, after which a second group of wave-form plots were captured. They are shown in this final image...
Image
Now, the first feature change that might be noticed is the slight sloping of signals Q37e's, Q44c's, and Q4e's high-peaks, however, more importantly, the signals' peak-to-peak magnitudes of each of those three are drastically reduced! V_Q4e is down around half a volt, V_Q44c is not much more than one volt, and V_Q37e is similar.

I now recognize these effects to be due to the missing "transistor-action" of Q4! Q4, without any collector-load, behaves like a diode (the base-emitter diode) whose current is limited by the sum of its base input resistor plus its emitter resistor. Base current is then higher than when the dc-gain of the transistor allows base-current to remain very low while the higher, controlled, current(s) pass through the collector-emitter junction. Q4's action looked faulty simply because it had no collector-load! Then, it was the oversize Q4-base-current that overloaded Q44's output to then make it, and Q37 appear to be degraded.
============ Q.E.D. ==============
Attachments
Unloaded Q4-collector impacts Q37 and Q44 performances.
Unloaded Q4-collector impacts Q37 and Q44 performances.
Schem_12FaultXientDataSepLR.jpg (167.29 KiB) Viewed 19100 times
Uniform 0-5VPP signals (exluding Q44b) occurs during normal drivers' operation.
Uniform 0-5VPP signals (exluding Q44b) occurs during normal drivers' operation.
Schem_12NormXientDataSepLR.jpg (159.03 KiB) Viewed 19106 times
Interim / partial Schematic_12 (J2, J8, and J24 circuits)
Interim / partial Schematic_12 (J2, J8, and J24 circuits)
Schematic_12_partialLR.jpg (422.53 KiB) Viewed 19108 times
Last edited by Gordon on April 24th, 2009, 8:52 pm, edited 2 times in total.
User avatar
vic7767
Robot Master
Posts: 15556
Joined: January 14th, 2006, 7:31 pm
Location: Haughton Louisiana - USA

Post by vic7767 »

Thanks Gordon, now that you have offered up all this data, drawings and info, I will begin to troubleshoot my 4110 Roomba Red with the modded swivel front wheel and IR stasis assembly.

All this Red will do on power up is One Beep when the Clean or Spot button is depressed.

Image
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

vic7767 wrote:... I will begin to troubleshoot my 4110 Roomba Red with the modded swivel front wheel and IR stasis assembly.
Good luck with TS'ing the Red-Sched. I expect the first thing you will do is put a camera on that stasis-LED!

Let us know what the problem turns out to be.
User avatar
vic7767
Robot Master
Posts: 15556
Joined: January 14th, 2006, 7:31 pm
Location: Haughton Louisiana - USA

Post by vic7767 »

Well Gordon, you nailed this one ! When I flipped over the Red and powered up, the cliff IR reading was from the Right Rear sensor only.

Replacing the Stasis assembly module on the front wheel enabled all the other sensors in the daisy chain to operate. Thanks...........
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Post by Gordon »

vic7767 wrote:Well Gordon, ... Thanks...........
Welcome, on that.

The Factory's crummy soldering job on the stasis LED & PT leads must have retired many of these swivel-caster Roombas to the land-fill!! Just MHO.

Next time you are inside the 5XX, you might study how its stasis-PWB is put together. If soldering is not through each of those four vias, then the 5XXs have latent defects lurking.
User avatar
Gubbins
Posts: 8
Joined: November 21st, 2008, 7:56 pm
Location: Roseville CA

4100 has Bad RH Cliff sensor?

Post by Gubbins »

Most of the info in this thread is WAY over my electro-knowledge level but it seemed an appropriate string to ask about my issue:

4100 Red has no input from RH outer cliff sensor unit.

Using a camera i've determined all 4 IR LED's emit.
Using Diagnostic #2 and #3 i found that the other 3 units seem to work.
They 'see', however not too well. I have to put my finger or white card almost touching the unit to get a status change.
I beeped between the actual leds and plugs to find any broken wires, all seems OK.
Still no joy from the Right outside unit.
Q37 only provides "power" to the emittor, right?
What does the detector rely on?

Thanks
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Re: 4100 has Bad RH Cliff sensor?

Post by Gordon »

Gubbins wrote:...4100 Red has no input from RH outer cliff sensor unit. ...Using a camera i've determined all 4 IR LED's emit.
Emitting is one thing, but emitting the required amount of radiance is another. We always have to watch out for these AlGaAs IREDs degrading, loosing their capability to emit enough energy to do the job. Unfortunately, digital cameras are not absolute radiometers, so one can't view one IRED, then another, and claim they are equal emitters (the camera will usually accommodate any difference, one scene to the next, and make them look the same in its view-finder screen).

The only way we have to discern weak emittance, is to place similar IREDs next to each other, so they appear in that same frame. That's fairly easy to do with wheel-tach IREDs, but testing cliff-IREDs that way would take a lot of work!
Using Diagnostic #2 and #3 i found that the other 3 units seem to work.
They 'see', however not too well. I have to put my finger or white card almost touching the unit to get a status change.
Well, that would be correct, because the optimal scattering plane is the surface which Roomba rolls on. Its quite close to the bottom of the bumper, until the floor falls away.

How's its Wall Sensor working? You did not comment about it. The Wall's IRED is in series with the right-outer Cliff IRED.
...Q37 only provides "power" to the emittor, right?
Yes, Q37 drives two IREDs.
What does the detector rely on?...
Each sensor module under discussion, is totally independent of their IRED driver circuits. Only optical-coupling joins them.

Photo-transistors are the detectors / receivers, so you need to visualize an NPN BJT symbol, collector at top, emitter at bottom, and no connection to the base (optical energy stimulates the base). All are biased by the same dc-voltage (which is only a little less than battery-voltage). Each PT's collector connects to that supply voltage through a 3900 ohm 'load' resistor, and a 10 ohm resistor connects the emitter to a power-return bus, which eventually gets back to the battery.

The transistor's output signal is picked off at the collector and shipped off (passing through a 1k ohm series resistance) to Roomba's MCU where it has a dedicated input-port. When radiant energy strikes the PT, collector-current increases, which results in lowering of collector voltage (by volts). As the signal energy diminishes, collector voltage rises, to get quite close to the supply-voltage level. That stimulus switches ON/OFF at a 1kHz rate. If a scattering surface is beneath Roomba, some of that oscillating radiance which has scattered off the surface will reach the PT and stimulate it into conducting at the same rate. Roomba likes to see that condition.
User avatar
mfortuna
Robot Master
Posts: 5852
Joined: February 5th, 2006, 9:35 am
Location: NH

Root cause

Post by mfortuna »

I just noticed this thread and I'm wondering about the root cause. First of all the solder connections look poor. Solder should have flowed to the component side of the pads through the plated through holes. It only looks like it did in a few places.

The corrosion makes me wonder if the foam attracts moisture. Maybe the roomba drove through a damp spot and got the foam wet. Maybe the wet foam then corroded the LED leads.

Mike
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Another story!

Post by Gordon »

Hey Mike, there's another story which I prefer over the "corrosion" story. In my mind, a strike against the 'corrosion-concept' is: 'brown' is not a color that I can associate with any of the oxidation products of the metals Pb, Sn, Ag, or Cu. IMHO, that brown residue is from the contact-cement that was glopped on the assembly just prior to slipping the black-foam (polyurethane) light-blocker under the E-O devices. Further, I can more readily subscribe to a 'mechanical-stress' storyline as the source of open-circuit failure. See what you think, as I outline it for you.

This is my short version!

The bottom line will be: E-O device solder-joints fail under continuing stress resulting from improper design of assembly interfaces.

To get to that bottom line, we must all gain some appreciation of how many mechanical interfaces there are between the cases of the E-O devices (IRED, a.k.a., IR-LED, and the PT (photo-transistor)) and the surfaces those EOD-cases bear against when assembled into the robot's chassis. Coarsely thinking, there are only three such interfaces at the assembly level, yet each interface requires positional control of up to six degrees of freedom (freedom to be slightly off in x, y, and z directions, and to slightly tilt about the three coordinate axes which are implied in every mechanical design). If those freedoms are not correctly toleranced, the possibility of conflict is great.

At this pont it is appropriate to show the "E-O Aligner", whose main job is to properly point the IRED and PT devices toward the crown of the swivel-caster wheel. Here's a picture of the E-O Aligner ready to receive the E-O pair:
Image

It's the black casting, with two ears, and held in place with two screws. The two sockets provide close fits to the E-O cases. Its critical to the story, to notice the means provided for locating the E-O Aligner part while those screws are being tightened.

You can see cast-on ribs (part of the chassis casting) which guide placement of the black casting. Consider how precisely the mounting surfaces, surfaces under the ears, and the ear-edges, must be controlled relative to the cylindrical holes that receive the E-O devices. The ME-designer had to do that.

Moving along the mechanical reference trail to the next interface control feature set, find the screw-boss at lower right, and alignment-pin (with flat top) at upper left. It is that cylindrical pin which x,y registers the Optical-Stasis PWB, or PCB, "OS_PWB", or "OS_PCB", to the chassis. Since the OS_PCB seats on the annular facets on those two bosses, we should ask ourselves how precisely those seating facets are controlled, i.e., do they have the same, exact, height dimension wrt the seating plane which the E-O Aligner contacts? If not adequately controlled, the PCB will be slightly tilted, and the engaged E-O devices will be pushed into a matching tilt.

Tilting those engaged E-O devices, or even laterally translating them from their relaxed position, will place their leads under stress. The devices are able to flex in one direction, and largely relieve stress, however, orthogonal to that easy bending direction, each EOD presents a very stiff resistance to bending. That 'direction' is one in which force is applied in the ~plane defined by the two pins of an EOD. Any stress built up by forcing the device in that plane will not be relieved. It will show up as a fixed stress in the device's plastic-case, in the leads, and at / in the solder-joint at the OS_PCB's pads & plated through holes (pth).

The soldered joints seem to be the weak link in that scenario. We've seen that not much solder wetted the leads, or any of the four pths. This additional image shows big solder blobs piled on the top-side pads. Insufficient heat & flux, I'd say.
Image
This OS_PWB view shows the assembly has not been pushed down into contact with its support bosses.

We should also consider how that OS_PWB must have been assembled at the point in time where the two EODs were soldered in place. There is no doubt in my mind, that some sort of alignment tooling was put to use, to locate and orient the cases of those EODs. The tooling would have been prepared to register to the interface features, discussed above, to achieve confidence that the PWB assembly would later mate well enough with the EO-Aligner piece part. That tool has the responsibility to:

a) Stand off the EOD cases from the PCB by a specified distance.

b) Ensure EOD cases would be a specified distance apart from each other, and to also be in x,y registration wrt the PCB's guide-pin and mounting-screw holes.

c) Ensure the central (cylinder-) axis of each EOD-case to be at some specific angle wrt to each other, and to the plane of the adjacent PCB face.

That's a fairly large order for a floor cleaner!

If those registration aspects are not properly controlled, there will be interference between the EOD-cases and their sockets in the EO-Aligner. Mechanical stress / strain will exist, and nature will try to relieve the stress as time passes, temperature fluctuates, and a little mechanical vibration comes into play. The weakest link may not remain as it was when first mfd.

Poorly executed E-O device solder-joints can fail under continuing stress resulting from improper design of assembly interfaces.

#############################

The iRbt ME-designer erred when s/he mounted the EO-Aligner piece-part on the robot's chassis! It should have been registered to, attached to the OS_PCB to eliminate several tolerances of alignment from accumulating!

#############################

Note: jasperpants provided the additional pix via PM request.
User avatar
Gubbins
Posts: 8
Joined: November 21st, 2008, 7:56 pm
Location: Roseville CA

Re: Roomba Scheduler - Cliff sensor failure apart from one!

Post by Gubbins »

Gordon-
Thanks for your immediate reply, I however got distracted by Thanksgiving etc.....
SO.....
Side IR is lit and seems fine.
Held all 4 IR emittors side by side and saw basicly equal illumination thru my camera.
Measured voltages at the rcvrs, all about 4vdc w/ when seeing 'cliff', about 3vdc when seeing 'floor' and about 1.5vdc when staring right into an emittor.
Ran test #2 again only to have RH cliff sensor never see 'cliff' except when I totally covered the recvr.
Hmmmmm.
Actually pinching the RH recvr's cathode was the only way to get a status change.
Peeled by the shrinktube and resoldered the cathode/wire joint.
Reassembled and running a good looking shakedown as I write.
Cold Joint? Broken wire?
Either way, R2 is back in service!
Thanks Guys!
Gordon
Robot Master
Posts: 4304
Joined: April 6th, 2005, 2:02 am
Location: Santa Ynez, CA USA
Contact:

Re: Roomba Scheduler - Cliff sensor failure apart from one!

Post by Gordon »

Hello Gubbins:
Its good to hear that you may have overcome Roomba's cliff-sensing fault! You did a lot of work to reach the end!

If you can spare the time, to confirm, I would like to get clarification pertaining to your two measurements. See below...
Gubbins wrote:...Measured voltages at the rcvrs, all about 4vdc w/ when seeing 'cliff', about 3vdc when seeing 'floor' and about 1.5vdc when staring right into an emittor.
I deduce that you had connected your meter's probes across the leads of the PT, and that the meter was set to measure dc-volts. Are those correct deductions?
... pinching the RH recvr's cathode was the only way to get a status change.
When you say "recvr" you are referring to the cliff-module's detector, photo-transistor, dark-blue/black lens device, correct?
Peeled by the shrinktube and resoldered the cathode/wire joint. ...
If 'correct', then, since the PT is a transistor, (but with its "base" terminal omitted), we are dealing with leads / pins named "collector" and "emitter".

I don't care which pin it was that you actually re-soldered, I am more interested in a future traveler passing through here and picking up incorrect data.

I hope that baby keeps chugging away for you!
Post Reply