New issue Rovio spins eternally

157 posts / 0 new
Last post
Usul
Usul's picture
New issue Rovio spins eternally

Had this with 5.00b7, still have it with b10.

Worked with b7 for weeks just fine. Then today, battery ran down. After recharge, when you give the blue button rotate to a compass heading commands, Karl (Rovio) just spins until new command given. Can still hit paths, go home, and all other commands work fine. Many reboots, and as noted, a firmware update. Repeatable with safari and firefox. Ideas?

Mich
Mich's picture

I have the same problem.
Since updating to firware b10 the left wheel spins out of control. Going back to b7 did not solve the problem.
Is it overheating? I switched of Rovio for the night, in the morning when turned on it worked properly for a little while and then started doing the same again. Left wheel spining longer time than it is supposed to.

Any Ideas?

Usul
Usul's picture

Mine doesn't seem to be heat related, but it is a case of one wheel overspinning. I've studied it with him off the ground, and when you issue a side to side command, the rear wheel goes faster, causing it to turn a bit. When you give a compass point command, the other wheels turn the right amount of time, but the rear wheel keeps going forever, causing more of a circular motion than a pure spin.

Still nothing useful from Wowee. It sure looks like software rather than hardware, though.

paco
paco's picture

I am having the same problem. but in my case its was one of the front wheels that constantly spun after a rotation command. Now it seems its both front ones that continuosly spin after a rotation command. The left or right commands move in an arc due to one tire spinning slower/faster than the other. I currently have a ticket open with Wowwee support.

Mich
Mich's picture

I openned Rovio to check the rotation sensors. With rovio off the floor, the problem stayed the same, left wheel over spinning. However I had to get more light to be able to see what is going on. At that moment the problem disappeared. What I noticed is that when a bright light is allowed to shine in towards the infrared rotation sensors, the problem goes away. The moment I covered Rovio the problem reappeared!!! then I decided to switch it off for the night after putting it together. The next morning it worked fine for some time after turning it on but then the problem reappeared. As mentionned before, downgrading to previous firmware did not solde the problem. is it a defective hardware? The rotation sensors are all the same, when I get time I will swap sensors from wheel to wheel to check if the problem moves as well... Any more info on this matter is appreciated. So until further notice moving around is by using the arrows with small mouse clicks...and no more the programmed rotation buttons!!!! Glad Rovio is still able to find HOME....

MrScott
MrScott's picture

Based on the description, it could be an out of spec IR sensor. Perhaps an early life fail of the semiconductor device.

I'm not familiar with the specifics of the Rovio hardware. Are they using an IR transmitter reflecting off a rotating pattern, and being detected by an IR receiver?

The engineer in me can think of a couple of failure modes that might be a cause.

If the sensor is losing its sensitivity, the extra ambient light shining on it might be raising it close enough to the trigger point so that the normal signal is enough to trigger it.

Conversely, if the IR transmitter is losing its power, the ambient light may be raising the sensor almost to its trigger point, and the weak IR signal is enough to trigger the sensor.

This is all conjecture, as I don't know what scheme the hardware is using to detect the rotations.

The fact that it only happens on one wheel, and that it's happening on different wheels for different robots, leads me to think that hardware is at least part of the cause. The firmware shouldn't cause different wheels to fail on different robots unless the hardware is the deciding factor.

Mich
Mich's picture

The rotation sensor uses a IR transmitter and a receiver. A disc with timing holes rotates between the two of them and is driven by the wheel motor.
Again what I noticed:
1-Additionnal light shining on the hardware solved the problem==> sensor problem
2-Switching off the robot for an extended period of time solved the problem partially==> components overheeting after some time and failing again.

MrScott
MrScott's picture

That sounds like a system consistent with what I was guessing about.

It may be an out of spec or degrading sensor, but it could still be a transmitter problem.

If the transmitter is losing strength, and the signal at the sensor is falling just below the threshold for triggering the sensor, then the ambient light might be just shy of triggering the sensor, and the small additional signal flash is enough to trigger it.

As an analogy for a bad transmitter and a good receiver, consider a mouse trap. A mouse of normal and weight will trigger the trap. A wee small mouse is so light the trigger doesn't "sense" the mouse. Now picture that a fat fly lands on the trigger, too, and the wee small mouse adds just enough extra weight to trigger it.

In the Rovio scenario, the IR portion of the ambient light is playing the part of the fly on the mousetrap. It's not enough to trigger the sensor, but it brings the sensor closer to its trigger point, so the weak IR transmitter can trigger the sensor.

The related analogy of a bad receiver is of a mousetrap with a stuck trigger. In that case, the normal mouse cannot press quite hard enough to unstick the trigger, but the weight of that extra fat fly is just enough extra weight to break it loose.

So, we're still left with the question.
You could have an undersized mouse (bad transmitter) or a stiff trigger (bad receiver).

Mich
Mich's picture

Rovio has three such sensors, one on each wheel. I ll try to swap around and see what happens.

MrScott
MrScott's picture

If we're right, moving a faulty TX/RX pair should cause the problem to follow the faulty pair.

Can the sensors be moved independent from the IR sources, or is each encoder one, indivisible piece?

If you can swap two transmitters, and the problem moves with the transmitter, then that transmitter is the likely culprit.

If you can swap two transmitters, and the problem stays with the unchanged receiver, then the problem is either in the power to the transmitter, or in the receiver.

Rudolph
Rudolph's picture

MrScott, here is a picture showing a little bit of one of the wheel encoders. It's just a wee pcb, so moving just the sensor would require a bit o soldering.

I know it's not the best photo. Just hoping it'll help you picture the part that Mich is talking about.

MrScott
MrScott's picture

Thanks for the pic of the encoder. Not easily separable into the send and receive parts. Next best thing would be to try and measure the output of the emitter on a good one and a bad one.

You might notice a vast discrepancy by simply viewing two emitters through a digital camera's viewfinder. Most cameras are sensitive to the IR signals that remote controls emit.

The other option is to probe the voltages coming into the transmitter to see if the two are getting the same power.

Mrtommy
Mrtommy's picture

After reading this forum thread, I agree with the analogy that this could be an internal wheel encoder IR transmitter / receiver problem. The action of the Rovio corresponds to the scenario at which the firmware is turning on each wheels motor and is monitoring each wheels encoder until a set a number of pulses are received from each wheels encoder independently at which when a given threshold of encoder pulses or counts are reached for a specific wheel the firmware turns off that specific wheels motor. If one of the wheelÂ’s IR transmitter or receiver is faulty then that wheel will remain active because the firmware never reached the count threshold to turn that wheelÂ’s motor off. Hence, RovioÂ’s firmware must not be detecting pulses for a given wheel rotation therefore it spins forever as the motor remains on.

For those that posted that adding ambient light allows Rovio to work I would speculate that the problem could be with the IR transmitter. Because if the receiver is bad, I would think that by adding ambient light would not help. Adding light directly to the sensor may activate a defective-weak IR receiver but for ambient light to pass through the encoder wheel slots and properly allow the IR receiver to generate pulses, I would think the receiver is good and the transmitter is faulty.

IÂ’m starting to wish I had spent the extra cash and purchased one of those 1 or 2 year extended in store replacement options from the R-Shack now.

milw
milw's picture

It shouldn't be too hard to check the emitters. Here's a closup of the board; with Rovio off, a simple diode check can be done between VRR and IR terminals.
Rovio Motor Encoder

Business side: the emitter/detector are covered by a plastic shield, it slips right off.

The emitter is clear; detector is black. A bad emitter would be pretty easy to replace; old computer mice (ball based) usually have 2 pairs like this though maybe smaller.

IR from good emitter is easy to see with  camera.

MrScott
MrScott's picture

This discussion makes me wonder if some of the trouble people are having with navigation might be intermittent wheel encoders.

Folks who say that Rovio starts out, then just goes nuts veering around the room. If the little buggar cannot tell if its wheels have rotated, it will have trouble executing course changes of a calculated rotation.

milw
milw's picture

hmm, yeah that would make a lot of sense. Hellish to diagnose an intermittent problem, but if it were figured out perhaps could be easy to fix depending on the cause.

MrScott
MrScott's picture

Do we know if the navigation scheme is constantly monitoring beacon location to try and match Rovio to a predicted path, or whether it takes a reading, plots and drives a while, takes another reading, etcetera?

I know there's feedback to plan a drive from the current calculated location to the final stored location. I just don't know how often it checks its location.

milw
milw's picture

Well, we do know the sensor is constantly transmitting location data to the Rovio brain (about every 5 msec), but no info that I'm aware of on how often it is actually checked during path replay. On some of my path runs, Rovio seems to go about 2 feet, then stop and correct itself. Heh, maybe a simple linear path where I go along and push Rovio away from intended course would be enlightening!

milw
milw's picture

Well, that was helpful (for enquiring minds!) I tried moving the beacon while Rovio was executing a simple 3 point path, and it reacts to changes within a second or so by adjusting its motion to the new beacon location. If I were writing the nav program, I'd give higher priority to the actual beacon readings than the wheel encoder counts; in fact I'd say the wheel encoders are useful only for the precision turn commands.

MrScott
MrScott's picture

There's got to be some "drive beaconless" navigation capability, because it's pretty likely that the beacon will be obscured from time to time by driving next to an object, under a table, etcetera.

A truly "smart" system would compare the predicted motion based on wheel sensors with observed motion based on beacon readings, and update its body model to compensate for slipping wheels, stuck wheels, or anything else that might cause the actual motion not to match the expected motion.

For instance, if the Rovio could/should compare it's calculated rotation with its actual rotation to diagnose that a wheel motor is running wild. It could then shut it down and try again, or calculate a drive motion using the remaining good wheels.

Rudolph
Rudolph's picture

When my Rovio gets stuck on something like a throw rug corner it'll spin the wheels for several seconds and then stop, move sideways (or whatever) and try again.

When it drives under the table and hangs up on a chair leg someone usually has to go rescue it.

Because of these two different behaviors I assume it indeed checks it's wheel spinning vs beacon readings. I imagine it could be expected vs actual beacon readings too, but I'd hope it uses the wheel encoders, since they're there :)

edit = I've not yet waited to see if Rovio will ever give up spinning it's wheels when lodged under a table. It does take longer than the usual "timeout" that occurs when stuck in the open. Think I'll go park it under the table and see what happens.

roschler
roschler's picture

@MrScott,

Someone is setting themselves up for being on the line to create a great Spykee autonomous driving demo video. Hmmm? :)

-- roschler

MrScott
MrScott's picture

At least it's making some "I think I'm moving..... Nope, I'm not moving..." determination when it gets stuck in some situations. If it that checking fails to work when the beacon is out of sight, it sounds like it is at least related to beacon checking.

I can think of several different ways this could be coded. The fact that the hardware is already in place to allow different techniques bodes well for the chance of future software updates to act smarter.

If "see beacon"
- If wheels moving, but beacon unchanged, must be stuck- call unstick routine
- If wheels not moving, but beacon changing
-- Cut power to motors to diagnose bad wheel encoder
-- If beacon still moving, outside force acting, enjoy the ride
-- If beacon not moving, cycle through each motor to see which encoder has failed

MrScott
MrScott's picture

There will be no Spykee autonomous driving without some serious off-bot processing. No Northstar, no path following. Not sure if there are any encoders, even. It's an entirely different (lower) class of telepresence.

I hesitate to even call Spykee (as sold) a robot. It's a WiFi controlled tank with a camera.

Rudolph
Rudolph's picture

Indeed, even with no nav signal Rovio will still notice a lack of movement and try to "escape". It would try driving a couple seconds, reposition, try again, repeat. I tried this both under the table with line of sight to the dock but no overhead ('cause of the table), and elsewhere with the nav sensor covered and the wheels up in the air. In both cases I got a popup saying "Nav signal is low, are you sure you wanna try this?"

Off topic; For jollies I just carried Rovio around the corner and into my son's room, then told it to "Go Home". Despite the clutter of a six-year-old's floor, it made it out of the room and into its dock in under two minutes, without using any additional beacons.

MrScott
MrScott's picture

If there were more user testimonials like yours, Rudolph, rather than the more visible testi-moan-ials from unsatisfied Rovio owners, there'd be a lot more Rovio purchases being made.

I'm not saying the folks having troubles aren't within their rights to pipe up. I'm just saying that there are some examples out there of how this beastie is supposed to work.

It's just frustrating that there seems to be an increasing number of recurring problems. The wheel spinning described here in this thread is just the latest troublesome trend.

roschler
roschler's picture

@MrScott,

As future on and off-board diagnostic software makes it's appearance, perhaps after the firmware adds additional dumps of sensor and motor states in future revisions to make that happen, all of these problems will seem like ancient history. I bet if you could find the customer complaints from the first Ford car owners you could do a Mad Libs search and replace on a few nouns and turn it into the modern day Rovio complaints.

-- roschler

Rudolph
Rudolph's picture

ROFL "HELP! My Model A just keeps spinning in circles!!!"

Usul
Usul's picture

Don't get me wrong. Love the little guy. It's well worth it, and some glitches are to be expected. Now as to the sensor issue, they are all plugged into the motherboard with connectors, and can be swapped without soldering.

So, I did. Question answered 100%. It's the sensor assembly. Rear wheel stops just fine with the good sensor from a front wheel. Unfortunately, the cables for the rear wheel are shorter than those for the front, so you'll have to do some soldering to fix front wheel. If you've got a front out, I recommend it. Rovio can still navigate, get home, etc. with the back sensor out. Probably not so with a front. I'm ordering another Rovio for spare parts.

Usul
Usul's picture

Just ordered another one from Wowee.  Price seems to have dropped!  I don't feel so bad using one for parts now.

Mich
Mich's picture

Finally I had some time. with the left rotation sensor defective, forward motion was not straight. Similarly with backwards. This will be the same if the right sensor is defective.
What I did, is swapped the left wheel rotation sensor with the rear wheel one.
Rovio can go straight forward and backward. The problem is hardly noticable on left and right turns. Of course the angular motion ( requiring signals from the three wheels) still does not work.
All together, with the right basic tools and caution a 20 mn job well worth the effort. Good luck if someone tries this temporary fix.

Pages