I do not quite understand what you are asking, but I suspect continuous rotation servos, which are not particularly high performance motors, are unlikely to be appropriate for inverted pendulum applications or for retrofitting with encoders.
The 20 mAh low end is probably because the charger cannot get the charge current low enough to charge the battery safely. I am not sure about the 100 mAh upper limit; are you sure that is not a mistake? Maybe that's a typo and it's supposed to be something like 100 Ah, though that sounds a little high (that would take almost 24 hours to charge with the 6A limit, plus 100 Ah is a pretty big battery).
Thank you for continuing to push on this. I've seen that Melexis sensor before, but I think the magnet for the AMS sensor should be pretty simple to make (and we're already working on it), so I suspect that will be the easier route.
As for your performance calculations, I definitely agree that 12 CPR is lacking if you want decent resolution per millisecond. We are targeting 8-bit MCUs with no special quadrature decoding hardware, and I think these 12-24 CPR units are very well matched to that. It's definitely good to hear from customers pushing for more, and we are aware that much better MCUs that can deal with high frequency quadrature are getting more and more available.
Your math for needing 16 Ah for two hours seems generally right, but you might be neglecting additional power requirements for the rest of your robot.
As for the long-term degradation question, yeah, a battery that gives you two hours of run time new will generally give you less as it gets older. I don't think there's a good general way of predicting that. Even without putting the battery age into consideration, you'll probably get significant variation when you consider various battery types and various loads that average out to 8A (e.g. 8A steady vs. 20A for 25% of the time and 4A for 75% of the time).
$4.21 is quite expensive for us, but I will look into those sensors and keep them in mind. I'll also add a 4 CPR version of the magnetic wheels (half N half S) to our to-do list so that even if we do not have the whole solution right away, we can have magnets for people to make their own systems like that one you linked to on tindie.
We are just starting to work on the additional resolution wheels, so we do not have availability estimates yet or even know how far we can go. It looks like 28 CPR will not be feasible, so we will try 24 CPR even though that will likely require a different sensor arrangement than the 12 CPR version.
Thanks for following up. You say "If it is a matter of fact ... then that should be verified as fully as possible", but you are not actually doing that if you reject sending drafts to those who are most likely to know and care about the facts.
I also think you should consider recalibrating if you think your example is at all extreme. I don't know why you needed to participate in that phone call for an hour, but it sounds like a minor inconvenience or unpleasantness to me. That person would probably have complained anyway when he first saw your article, and we shouldn't let the occasional unreasonable person influence our behavior so much.
Did you read the post and comments and try to do the calculation yourself? There is one wrinkle in the specs you've provided: 12V at 400mA is 4.8W, not 5.6W. If we go with the 400mA figure, your 4800mAh battery should be good for around 12 hours. If we go with the 5.6W figure, your 12V * 4.8Ah = 57.6Wh battery should be good for about ten hours. Either way, you should easily get four hours even if there are some inefficiencies or optimistic specs on your battery.
Thanks for your feedback. I'm very excited about 12 CPR because I think it's close to ideal for robots like our 3pi and Zumo. With a 30:1 gear ratio, we get 360 CPR on the gearbox output, and with a 32 mm wheel, that comes out to about 0.25mm linear resolution. You can see what kind of performance you can get with that combination on Paul's dead reckoning robot:
These motors can go up to about 30,000 RPM, or 500 revolutions per second, so with 12 CPR and two channels, that gives us about 12 events per ms for our controller to deal with, which starts getting close to the limit of what is practical on a microcontroller without needing special hardware counters. I realize not everyone needs 30k RPM, and we are working on slightly higher resolutions versions of our magnetic wheels (to give us 20 or 28 CPR).
Those absolute position sensors are very nice, but they are also very expensive, and my general sense is that they are overkill for these motors. Can you share more about your applications and why you need such high resolution?
Thanks for pointing that out. While the 3A header ratings are probably fairly conservative, you should solder wires to the regulator if you want to push it to its limits. Current limits or ratings in general are quite complicated for products like this since there are so many factors to consider, including ambient temperature, airflow or lack thereof, how many other contacts or heat-generating components are nearby, and what kind of duty cycle is necessary.
We expect to be updating these regulator pages and perhaps to be adding other resources to help specify and clarify what kind of performance you can expect at various operating points.
Yeah, they fit in there! It will still take some work to design the right corresponding PCBs and to come up with a good assembly procedure, so we're still at least a few months out from having a complete encoderized Zumo.