New issue Rovio spins eternally

157 posts / 0 new
Last post
milw
milw's picture

Also I've had pretty good results with tracing the circuits in other WowWee bots; you can find where the encoder cables plug into the main board, and the follow the traces through components until you get to the MCU. I may take a stab at this when I get home, as I have my Rovio all torn apart at the moment.

Usul
Usul's picture

OK, just did the Roborealm thing and checked the ticks from the sensors. Of my two rovios, one has the left and read sensor out, and another has the right sensor out. I'll pull all of them from the first, and put the good right one in the second. Further reinforcement of the idea that this assemblies are failing in high quantities.

MrScott
MrScott's picture

Do you have a multi-tester? Can you get some readings of the working and failed circuits?

Things of interest are whether it's the IR source or receiver that's at fault.

Once we know what's at fault, is it failed as a a short or open?

The voltage measured across the IR sender and receiver pins (with the sensor disconnected) would be of interest. Especially if the voltage is different between the working and failed circuits.

Usul
Usul's picture

Will do when I do the surgery. I presume you want resistance measurements? Hopefully no voltage when disconnected.

MrScott
MrScott's picture

There are various ways to assess the hardware.
First up is to determine whether it is the sensor that has failed, or the circuitry driving/reading the sensor that has failed.

The sensor has two parts. The IR transmitter, and the IR receiver.

Visual inspection of IR source (using a camcorder/digital_camera).

If it is dark, after removing a dead IR source from the circuit, is there a voltage across the pins it was connected to? (is it getting power)

With the diodes out of circuit, do a diode test of the IR transmitter and receiver. Normally a low resistance in one direction, and open circuit in the other.

Depending upon what multi-tester you have, it may have a diode test mode. Even without that feature, it can be done with a basic analog or digital multi-meter.

http://www.allaboutcircuits.com/vol_3/chpt_3/2.html

http://www.electronics-radio.com/articles/test-methods/meters/multimeter...

http://www.kinetics-industries.com/papers/DIODE-Testing.pdf

Some hints on testing IR LED and sensor pairs.

http://www.coilgun.info/levitation/testemitter.htm

http://elecrom.wordpress.com/2008/02/19/how-to-make-simple-infrared-sens...

RovioFan
RovioFan's picture

I will measure the voltage across and the current through the emitter of the good assembly I have and I will do measurements for each channel to see if there is a difference.

As far as the detector side, I traced the signals all the way to the outputs of U2 (part # 74hc14). It is a Hex Schmitt Inverter which basically just converts the sin wave type outputs of the detectors into a square waves for the microcontroller. They looked good for all channels.

IÂ’ll try and take the measurements tomorrow. Also, I will determine the failure mode of the original and replacement emitters.

milw
milw's picture

On the emitter side, they are run by output of transistor Q28 which goes to the VE pin (red wire of the sensor assembly). I get a diode reading between red and blue wires, and open circuit the other way, so this is likely the high side. The blue wire goes through a 430 ohm resistor to ground; each sensor has its own resistor but all three are driven in common by Q28. I remember checking the input voltages before, I think it was 5V (probably reported earlier in this very thread!).

MrScott
MrScott's picture

What I'd be interested in is whether the leg that is turning up faulty has a higher voltage, or a higher current stressing the sensor(s) that fail.

Any component can potentially be out of spec. A failing sensor can either be because a sensor couldn't take the normal beating, or was getting hammered by something off-kilter upstream.

denodan
denodan's picture

Think maybe your looking in the wrong place and it's not faulty sensors,but some other hardware causing sensor failure. If it was just the problem with the sensors, then one, or two would fail and not cause replacments to also fail.

 

Some here have moved the sensors around and the moved, or swaped sensors have failed, so I wonder if it's some other hardware causing the sensors to fail, or burn out. Seems strange heaps of sensors are all failing.

Which may lead to some other hardware causing sensors to fail.

MrScott
MrScott's picture

That would be the point of asking if the voltage and current applied to the failing, and working circuits is different.

milw
milw's picture

denodan said:
Think maybe your looking in the wrong place and it's not faulty sensors,but some other hardware causing sensor failure. If it was just the problem with the sensors, then one, or two would fail and not cause replacments to also fail.
Some here have moved the sensors around and the moved, or swaped sensors have failed, so I wonder if it's some other hardware causing the sensors to fail, or burn out. Seems strange heaps of sensors are all failing.
Which may lead to some other hardware causing sensors to fail.

The sensor modules themselves only have the IR LED and the receiver diode. There's no other circuitry on the board. I suppose it is conceivable that the modules were manufactured with (for example) a mixture of IR LEDs with different drive current limits. I'd be very curious to see images of Q28 and the current limiting resistors R5, R13 and R16 from a Rovio with IR LED failure in the sensor. BTW my main board is G7398-1B.

denodan
denodan's picture

Why look at the sensors if the sensors are not the real issue? it has to be something else causing the sensors to burn out, or fail? I very much doubt it's snything to do with bad sensors, or a bad batch, but other hardware on Rovio is stuffing up the sensors.

I think the investigation has got to be elsewhere on Rovio. The Sensors stuffing, I think has nothing to do with sensors, but some other hardware problem on Roivo.

Think the only way it could ever be linked to the sensors is wrong spec IR LEDs?

Nocturnal
Nocturnal's picture

denodan said:Think the only way it could ever be linked to the sensors is wrong spec IR LEDs?

Not really. It could be a bad batch of either the led or the sensor (bad batchs can, and do happen), it could be the wrong value current limiting resistor has been used somewhere, it could be something we haven't thought of yet. Looking somewhere other than the sensor and supporting circuitry is probably a serious waste of time.

I say probably in the sense of certainly, except I always allow for that 1% of it being something else.

MrScott
MrScott's picture

You do not just start poking around at random things to find out what may have caused a sensor to stop functioning. You determine the immediate failure, and work backwards from there to a root cause.

By comparing known good component chains to known failing component chains, you isolate where the differences are. If the two branches merge up the circuit chain, then the problem has to be between the shared component and the dead sensor you started with. You know that, because the other branch is still working.

A "sensor" consists of at least two components. The transmitter, and the receiver. Looking at those components to find out what has stopped working leads you back up the circuit chain to see what might be causing the failure.

As Millw has stated, all three sensor emitters are driven by a common transistor, that then go three a resistor for each emitter, and then to the emitter. There's not much extra "hardware" to debug between the common point and the one failed sensor. The transistor isn't dead, because the other two sensors are working. The transistor isn't grossly overdriving, because the other two sensors are working.

That leaves you with a potential "bad" current limiting resistor feeding the emitter that burned out, or it leads you to a faulty emitter that died an early death under conditions that did not kill the other emitters.

Of course, nobody has stated yet whether it is the emitter, or the receiver, that is failing. The backtracing from the receiver leads should be done if it is determined that it is the receiver at fault.

Nocturnal
Nocturnal's picture

I envy your patience MrScott.

milw
milw's picture

MrScott is the real electrical engineer amongst us, I'm just a self-taught trouble-shooter. Being methodical is the only way to go about it. How many of those who piped up with failures are still following this thread?

MrScott
MrScott's picture

I think it's time for me to just pipe down.

I don't even have one of the beasties in question, functional or otherwise.

I started out in this thread trying to get things started towards some fact finding and methodical testing. That horse should be well and truly four hooves to the moon by now.

I've spent my share of time in raised floor labs, hunched over a bench troubleshooting why such and such a component is toast. In 99.99% of the cases you start there and work back. You almost never want to start at the power source and work down to the component. There's just too many irrelevant paths that don't contribute to the failing component.

Consider this my last post on the specifics of this case. Once we're talking specific components, all I can do is look over somebody's virtual shoulder. We have electronics savvy community members who have working samples on their benches. They're better suited than I to gather measurements, compare results, and isolate a root cause.

If somebody wanted to capture some general troubleshooting techniques in a general thread, I'll be glad to add what tips and techniques I use.

CanUSRovio
CanUSRovio's picture

Hi all,

The problem persists on my Rovio.

I'm almost to the point of shipping my Rovio back for a replacement or worst case refund. Does anyone know if Hong Kong has samples of this malfunction to help them in their diagnosis?

If not, maybe the best thing might be to send them mine (and perhaps others) for study.

I'm hoping the solution is close at hand.

cmilian
cmilian's picture

I see a lot of spinning issues. Are these new Rovios? I had mine since almost the beginning with no issues (cmilian is knocking on wood)

RovioFan
RovioFan's picture

Ok, I have some interesting results

1) Voltage across factory and replacement emitters was 1.12V
Current thru factory and replacement emitters was 5ma
This was true for all channels.

2) After analyzing the original and replacement emitters I could not find anything wrong with them. This led me to testing the detectors.

3) While analyzing the quadrature outputs from the detectors I noticed that the good one had outputs of around 3Vp-p and the bad ones had outputs of about
1.2Vp-p (that is on the hairy edge of what the 74hc14 would like to see for a logic level high input)

Given the above findings I hypothesized that the problem was not that the current limiting resistor was too low (as I had first thought) but that it was too high. I put a 1Kohm resistor in parallel with one of the 430ohm resistors. This created an equivalent resistance of around 300ohms. I measured the quadrature ouput again (this was on one of the "bad" encoders only). The voltage was then at around 2Vp-p (a good improvement). I then tested the encoder signal using RoboRealm and low and behold the bad encoder was then working. I implemented the same mod for the other "bad" encoder and it worked as well. Being overzealous, I went ahead and did the mod on the good encoder in an attempt to prevent it from failing in the future.

After an hour of testing all of the encoders are still working. I can once again turn using the preset angles. Another effect I have noticed is that the automated docking is more precise when all of the encoders are working. I suspect the firmware is using the encoders in conjunction with the beacon to automatically dock.

In summary, I have placed 1Kohm resistors in parallel with each of the 430ohm resistors and this has fixed the “bad” encoders and has not damaged the remaining good one.

To really be sure that this is a sufficient and safe mod, the recommended current requirement for the emitters needs to be found.

I will post as soon as I detect any problems.

RovioFan
RovioFan's picture

I forgot to mention the main point which is that the emitters on the bad boards seem to have decreased in intensity and or the detectors have become less sensitive.

Usul
Usul's picture

Good stuff! Can you send some pics showing your mod? I'm tearing into both of mine tonight to do my homework for Mr. Scott. Also to swap out parts and perhaps make one good Rovio. With your mod, perhaps I can have two!

RovioFan
RovioFan's picture

Usul, I'll try and take some pictures tonight. ItÂ’s pretty ugly, I just used some 1/4 watt axial through hole resistors. Later on I might put on some 300ohm surface mounts.

Another thing I'm going to do is take a detector from a "bad" encoder and put it on the board that hasn't failed yet. This should tell me if the sensitivity is different for the detectors on the "bad" boards. Also I will test the original emitters that I thought were bad by pairing each of them with the detector on the board that hasn't failed.

I should also note that I still have the replacement emitters on the "bad" boards. I do not know the specs for them. It could be that their spectral emission is significantly different from the original. It amazes me that the more I dig the more questions I have, lol. I expected this to be a much easier troubleshooting exercise.

By the way, I just logged in to Rovio from work and itÂ’s still functioning properly. I'm keeping my fingers crossed.

milw
milw's picture

What were the part numbers/source for your replacement emitters, RovioFan? I'm also curious to figure out what type of part the detectors are- the middle lead is power and is common with the IR LED power (from VE on the main board). The detector also has the two output leads marked as 'Bit0' and 'Bit1' - does the detector really output a 4-level binary encoded signal, or are those just Signal and /Signal?

Oops, some research http://en.wikipedia.org/wiki/Rotary_encoder
Probably quadrature output, tho possibly Sin/Cos outputs.

Hubba
Hubba's picture

I am having the same problem as well now :( - any news on a fix from WowWee? - I don't think I am technical enough to deal with the stuff above :(

RovioFan
RovioFan's picture

Milw, I think the detector is a dual phototransistor setup with the collectors of both connected. Bit 0 is the emitter of one transitor and Bit 1 is the emitter of the other. If you watch the signals on an oscope you can see that they are out of phase slightly and that the phase lag changes as a function of direction.

The following link shows a device which I think is a pretty good example of the component we are dealing with (on the detector side).

http://www.datasheetcatalog.org/datasheet/vishay/83755.pdf

However, the geometry and orientation of the photo input area may be very different. If you look at the above linked datasheet they show pull down resistors connected to the transistor emitters in the test circuits. When I traced the signals to the 74hc14 I don't remember there being any other components. Did you happen to trace out that circuit and if so what other components did you see? I will check again when I get a chance.

I have searched and searched for some 3 lead detectors like the one on our encoders and have not been able to find any like it. Maybe someone else will have more luck.

RovioFan
RovioFan's picture

Milw, I'm sorry I forgot to answer your first question. I don't have a part number for the replacement emitters. I had a few surplus slotted photo switches and I tore the emmitters out of those. Unfortunately the casings don't have anything written on them.

Oh yeah and the signals from the detector are sin waves. The 74hc14 converts them to square waves.

milw
milw's picture

RovioFan said:
...When I traced the signals to the 74hc14 I don't remember there being any other components. Did you happen to trace out that circuit and if so what other components did you see? I will check again when I get a chance...

Yup, there are 103 (10k) resistors to ground on all 6 of the bit lines from the detectors, right next to the 74hc14. The outputs of the 74hc14 appear to go directly to the MCU under the epoxy blob. I don't see any other components involved in the decoder outputs.

Usul
Usul's picture

OK, my results are a bit dated given the above. Still, good troubleshooting info for folks willing to buy rovios for spare parts, and not wanting to solder surface mount resistors:

I'm a control systems engineer (the kind the gets to put P.E. after his name in some states) and I started out doing board level electronics and firmware for oilfield test equipment. The Rovio doesn't do anything technologically amazing, given the state of the art. The fact that it can do it in a package that now retails for $200 is friggin awesome. This is the kind of engineering that will make robotics practical. Hats off to Wowee. (now if they'd just let me buy a dozen of the encoder assemblies....)

My bad luck may be due to the fact that my two Rovios (Karl and Kera, to keep them straight) are continuously polled by Security Spy from Ben Software. I set them up using the getimage API. Works great. I have captured some nice movies that way, too.

On to my homework:

Using RoboRealm, Karl showed no counts on left or rear sensor. Kera showed no counts on right. Both spun hopelessly when a compass command was given.

I took Karl down and photographed the LED on all three sensors. All showed up. (Thanks for the tip that digital cameras can see the IR!) All of Karl's motherboard outputs were around 3.3V VRR to to IR. The same connectors on the disconnected assemblies read 23.85 to 24 Mohm one way, and open circuit the other. So, no smoking gun there. Took all sensors offline, and Karl drives straight now. One side effect, the sideways motion is now a rotation. Makes docking pretty darn ugly. Still, it's nice to be able to go straight. If you only have the rear sensor out, leave well enough alone. It will drive straight if the left and right still work. Just won't rotate to compass heading.

Next I took Kera down, and took out the offending right assembly. First disappointment, crushed the tiny connector. Luckily, Roborealm was not dyslexic, and that was the dead assembly. Same readings from motherboard, 3.29 V VRR to IR. Xmit diode resistance 24 MOhm. Oddly, the bit 0 and bit 1 on Kera read .43 MOhm rather than .5. I only tested the bad one, as I was down to no more spare parts to make a fully functioning rovio. Put in Karl's good right sensor assembly, and Kera was restored to full functioning. Compass points and all.

So, we don't know whether the motherboard is frying the subassemblies over time, or if they degrade on their own. We do know that they take time to fail, and that the failure appears to be permanent, and fixed in the affected subassembly.

It also appears that the drive motors are VERY consistent, and that the firmware could be feasibly modified to perform pretty well without the sensors, just by using timing, even without a good nav signal. It's only critical when docking, and then you have a nav signal. Wowee should consider this option, as it would pretty well fix the symptoms without requiring tools or expertise on the user's behalf. Additionally, if the compass point commands were driven by timed firing of the rear wheel, ignoring the sensors, it'd be pretty decent.

So, is Wowee listening here?

Thanks everybody for your help! Especially Mr. Scott.

Rovio fan, looking forward to your pics. I might try the resistor soldering on Karl if I can figure out a good way to reconnect the assembly whose connector I crushed.

MrScott
MrScott's picture

Excellent detective work, folks.
Good to see you're on the trail of the ultimate culprit.

So it seems we have identified at least one instance of an immediate cause, i.e. the detector not generating strong enough sine waves as the slots pass in front of the dual IR sensitive receivers. The voltage swing is too small to be seen as a good signal by the next set of components.

RovioFan's fix was to decrease the current limiting resistance, thus driving the detector harder and increasing its voltage swing.

For those who haven't had their Intro to Circuits course yet, the reason RovioFan could add a resistor and end up lowering the effective resistance, is because he added it in parallel with the factory installed one. Resistors added in parallel provide additional current paths, so the total effective resistance after adding a resistor is actually less resistance than you had before.

Think of it as trying to drink a soda as fast as you can through a narrow straw. The narrower the straw, the higher the resistance. Adding a second straw next to the first makes it easier to suck it up faster. The resistance is less, because their are more paths for the soda to flow through.

The question remains "why" is that one detector putting out less voltage than its neighbors when all three have the factory equipped resistors? Is that one resistor out of spec compared to the two assemblies that were working with the factory installed hardware?

If the three resistors were the same, and the three circuits were otherwise balanced, then having just one sensor fail to perform still points back to a sensor out of spec.

I'm enjoying the detective story. Carry on, Mr. Sherlock.

Pages