The servo is not made for continuous rotation, and it rotating continuously is a sign that you are asking it to go beyond its limit, which could cause it to be destroyed. The standard 1-2 ms range should get you close to the full turn, and you can gradually expand the range while keeping it centered at 1.5 ms to get to exactly one rotation of range.
By the way, you should direct questions like these to our forums or to more direct tech support.
I don't know how you expect me to be able to judge that better than you. However, from the little information I can get from your question, it sounds like you aren't getting the point. This article is about a specific approach to getting many channels of servo control. If you just need one or a few servos, you don't need anything this complicated, and if you need to do many servos, you're probably better off getting a dedicated servo controller.
It looks like you might have already asked about this on the forum some, and I don't really have a good answer. I would look around for different servos (you can get metal gears with analog servos, by the way), but if you like the ones you have, you'll have to go for the external power switch route you described. Some of the fancier servos are programmable or configurable, so you might check into whether the no-signal behavior of your unit can be changed.
My comment above already covers the easy part: you get a simple tradeoff of speed for torque, so, if you make the motor give you 20% of its stall torque, it will give it to you at 20% less RPM than the no-load RPM. However, calculating how extra weight on the robot translates to torque on the motor is not something you can easily calculate since it depends on things like friction and how the weight is distributed.
I know we need to work on the documentation for the mechanical aspects of our products, but thanks for the reminder. In general, if there is some information that you need and that isn't on the web site, you can email or call us about it. I'll ask someone to send you a drill drawing for your qik 2s12v10. By the way, the qiks are purely serial motor controllers, so they are not intended for radio control applications.
I am disappointed in your take, but I appreciate the time you took to provide the feedback, so I want to address each of your points.
I know that I don't think of potential comment readers as idiots, and it's been a while since I wrote this post, so I just reread it. I don't see the evidence to back up your claim in my post. You say it's not explicitly stated, but it's just not there. I gave the example of my own experience, where the intelligence of the reader is irrelevant when the information in a comment is just flat wrong. I talked about beginners, but that has nothing to do with being idiots or not, and I stand by the claim that comments can do those kinds of comment readers a great disservice (I have seen several cases of it).
Regarding your selfishness claim, I don't think any business would be well-served by embracing things that are bad for it. I think comments on a site like ours are bad compared to the available alternatives, and I think you're deluding yourself if you somehow think that Sparkfun thinks that comments are bad for them but that they tolerate them out of some kind of altruism. Sparkfun has made the calculation that on the balance, comments are good for them; I have presented my reasons for thinking otherwise. I don't understand the "backward looking" part.
I think I specifically addressed your "it's about engagement and interaction, not hiding and protecting" sentiment: those goals are fine, but comments on a product page are a bad way of achieving them. I think it's pretty easy for you to interact with us if you want to, but you should not have to just because there isn't decent documentation in the first place.
Regarding the occasional useful information in comments, I think I addressed that, too: the comments are not a good way of organizing and presenting information. I suspect that most competent readers digging through a hundred comments that are 95% junk do it because they are at a desperate point where that is a last resort. I think it's disrespectful for a web site to expect me to dig through a bunch of assorted comments rather than to just present the information well in the first place.
I do appreciate that you want the comments, and I suspect that on some level, it's independent of the arguments of if they are good or bad. I am genuinely interested in what others think, and I think I am open-minded enough about it that I could change my mind. In this case, though, you're speculating about an unstated (and untrue) assumption rather than arguing any of the points directly.
Your use of "context" caught my attention. In some sense, my argument is that there is a place for official, organized information and a place for informal discussion (e.g. the forums, this blog, etc.). What is special about having the discussion on the product page as opposed to in the forum? What if there were a dedicated forum thread for each product?
I don't know what to make of your last statement since I do not know what you mean by "progressive company" and therefore do not know if being a progressive company is something to strive for.
Thanks for the feedback and suggestions. I already have a long list of topics, and I don't think either of those were on there; I'll definitely add them. I also started with the BASIC Stamp and then PICs (after a few years of just electronics without any programming). It's difficult to come up with a "recommended path" when it's kind of a lot of parallel paths, and people who approach robotics can have very widely varying skills.
I am not pulling your chain; let's consider your examples:
"What screws you use with that motor" or "pot direction mislabels": This kind of basic info should definitely be in docs and not relegated to comments. I believe you can find this level of answer in comments, but the answer existing there should not be considered a virtue: it's an indication of poor documentation in the first place.
"Why I fried that thing backwards" and "need any other product to hook that up to my IMU": This *is* general knowledge, and it's also not likely to be covered well in comments.
I am not convinced of the existence of this intersection of "misc info" that is not general knowledge yet specifically relevant to a product but also should not be in the docs. I think the forum does capture the misc info aspect; if your quest is for knowledge, why do you care if you're searching in product comments or in forums and official docs? Do you at least agree that having all the info in organized documentation is a better goal than having all the info in comments?
I don't understand your statements toward the end. How would comments have answers to "questions people will not spend time to ask" any more than any other format?
Disconnecting powered stepper motors is usually a bad idea, and we've added a notice to that effect on our driver pages. By the way, changing connections while power is applied is generally bad even when you're not talking about stepper motors.
I think your reduction of comments to "Knowledge" is the logical step I disagree with; the ideal is not borne in reality. There is no shortage of information out there, and combing through comments on product pages has to be one of the worse ways of acquiring knowledge. Datasheets, web sites, and books by people who know what they are doing will have a much higher density of the "quick lines from experts" you're looking for.
The quick answer is that the torque goes in a straight line from zero at the no-load speed to the stall torque at zero speed, so at around 10% of the stall torque, you can expect 90% of the no-load speed. So, without factoring in any other potential issues such as whether the voltage range is good for your application or if the motor is convenient to mount, the motor you mentioned should be fine the application you described.