I wanted the facts - so it's time for the rigerous scientific approach. Well - OK - the half-assed semi-scientific Steve Baker method :-)...
Sensor 1 Sensor 2 792 792 790 790 788 788 784 784Well, at standard 'new Mindstorms' motor speeds (about 300 rpm), we can conclude that either no counts were lost at all or the lossage happens identically for both sensors.
OK - change the setup so that the first rotation sensor is on the motor shaft - and the other is on another shaft that's geared down 5 times. The second sensor is now rotating exactly five times slower than the motor. If counts are dropped for both sensors at the same time then we'll be able to tell because the number of counts for the second sensor will not be exactly one fifth of the count for the first sensor:
Sensor 1 Sensor 2 Sensor2 * 5 778 156 780 774 155 775 772 154 770 771 154 770Although the numbers for Sensor1 and Sensor2-multiplied-by-five are not exactly the same, this is fine. We are using integer math, and dividing by five (in the gear train) and then multiplying by five again would produce an error of up to 4 units even if the system never loses a count. Since (sensor2 * 5) was always within two units of sensor1 - that's as good as it gets. We didn't lose any counts in the experiment.
I swapped the gears so that the second sensor is now geared up 5 times. The second sensor is now rotating exactly five times faster than the motor.
Sensor 1 Sensor 2 Sensor2 / 5 752 2517 503 749 2494 498 749 2499 499 748 2480 496Woah!! BIG TIME Lossage. It's pretty clear that the rotation sensor doesn't work at 1,400 RPM without losing data. The good news is that it's pretty consistent in that it loses about one count in three. This could be useful to know in some applications. The number of lost counts will vary as a function of speed in some manner - but the result is clear - I don't recommend cranking the rotation sensor faster than the motor.
Sensor 1 Sensor 2 Sensor2 * 25 790 32 800 785 32 800 784 29 725 <===== Oops! 779 31 775As with experiment 3, we can expect an error of one count in the second sensor because of integer math - but an error of two or more would indicate inaccurate counting.
And on the third run, you can see that Sensor2 should have read 30,31 or 32 counts. It only read 29 and that MUST mean an error in reading the sensor.
So at slow speeds (about 12 RPM in this case) we lost at least one count over about 40 seconds of testing.
Try to stick to rates around 50 to 300 RPM - the range may be a little higher - but we know that <12 RPM or >1400 RPM are definitely bad news.
Someone (not me!) should probably figure out a bunch of gear trains and motor loadings to check the actual limits - and run the tests over MUCH longer periods than 10 seconds to get some measure of reliability.
I also wonder if it's possible to make the thing lose more counts by giving the firmware more work to do. If I run 6 threads all doing lots of sensor and motor work - and run the light sensor at the same time - and play lots of beeps on the speaker...would that load the firmware down enough to make it drop counts at all speeds? That's an open question.
The 'obvious' way to correct this is to place a rotation sensor on each wheel and count the revolutions of each. Whichever wheel is running fastest can be slowed down a little (typically by 'floating' the motor output) until the counts are again equal and unless the wheels are slipping, you will be going in a nice straight line.
That design is OK - but knowing what we learned from these experiments, it might be better to place the rotation sensor on the motor output shaft where the speed is likely to be in the 'sweet spot' of 50 to 300 RPM where the sensor is accurate - rather on the wheel axle where the speed will probably be much lower and into the 'danger zone' where the rotation sensor loses counts.
Obviously, you'll still lose counts when the robot starts or stops - or if you steer by completely stopping or reversing one motor - fixing that would be very hard.
One commonly suggested improvement on this design is to insert a differential gearbox between the two drive wheels and place a single rotation sensor on the output. This saves a sensor input on the RCX and in theory allows you to correct for speed mismatches by looking to see whether the sensor is rotating clockwise or anticlockwise. That works because the output of the differential is half the sum of the speeds of the two wheels. Since one is rotating clockwise and the other anticlockwise, the sum of their speeds is zero when the robot is going straight, positive if it's turning one way and negative if it's turning the other way.
On paper, that design is quite clever. You lose the ability to measure the overall speed that the robot is travelling - but saving a valuable RCX input is well worth the sacrifice in many cases!
However, the rotation sensor will be spinning VERY slowly - if at all. Since we know that the sensor will lose counts at such low speeds, we can tell that this approach isn't a good one. Every time the sensor loses a count, the robot will veer a little off-course without the RCX knowing about it.
Probably the best design for a robot like this is to use two motors via a pair of differentials so that one controls the average speed of the two wheels and the other controls the difference in their speeds. This 'adder-subtractor' drive doesn't need a sensor at all. If the 'difference' motor is using active braking then the robot will go in a straight line for sure. You may still want to use rotation sensors to calculate the rate of turn or the forward speed - but in each case, they can measure the motor speed with reasonable precision.