I just finished some servo code and before I release it as a library, I was wondering how people might like to see servos handled. There are some choices:
Allow a user to take digital 9 and digital 10 away from their analog output functions and make them servo drivers. You only get two servo channels, but it is dead simple code and fully handled in hardware . You can't make it glitch.
Implement software servos, you could use any combination of digital pins as servo drivers, but every 20ms the servo code is going to take over and disable interrupts for about 2ms. That is going to effectively blind your program 10% of the time. At 9600bps you can lose a byte or two of serial data. If you disable interrupts for too long (40ms?) your servos will give up on you and return to their home positions.
I realize the easy answer it to say BOTH. But I'd rather not do both since that would be confusing to users. So, for the sort of things that have inspired you to dream of servos on arduinos, how many servos do you need? (And what is it you would use them for.)
I can fit into that class, but I'm a little mystified by it. I don't think the servo timing "standard" says anything about degrees. Just 900ms to 2100ms with a center at 1500ms. The mapping to degrees depends on the service and how far it swings, typically less than 180 degrees. If they went 180 degrees like the wiring docs say they would bind in your typical RC airplane pushrod application.
The gibberish that passes for spec sheets at Hitec seem to say the ones I'm testing with go 60 degrees each way for a 120 degree swing, or maybe 40 each way but I think it is going further than that in my test rig.
Unless someone shows up with knowledge, I guess I'll just make the input go 0 to 180, map that to full swing output and ignore the fact that it isn't really degrees.
The read() method will have to return the result of the last write(), the actual position is not available.
The servo travel will depends on the servo you use, some of them will do more than 180, you can even get linear servos. There's no real standard. I doubt that one timing that gives 120 degrees on one servo will give exactly the same angle on a different one. It may be better to just use say 100 for full travel one way and -100 for full travel the other, or 0 to 200 to avoid negative numbers. To avoid excessive travel, you can do what the RC manufacturers do, which to limit the travel to maybe 80% of the availible. Just a thought.
As far as i know there is a standard that says:
1 ms = - 45 degrees
1.5 ms = 0
2 ms = + 45
but:
the feedback of a servo is done with a potmeter, correct me if i'm wrong but they have a tolerence of 10%.
the joystick in the transmitter is made with potmeters having the same tolereance, each channel also has a trim, again a tolerance, to my knowledge there is a adjustment inside a good (analog, don't know about digital) zeroing out the errors of the transmitter.
This leaves us in the best case with a 10% error and worst case more than 20% but planes and cars have a mechanical trimming.
To compensate all this the servos travel more +-45 degrees some even go beyond +-90 degrees.
Notice that when you buy multiple 'identical' servos that each of them will be different in behavior, one cannot just replace a servo without trimming the plane, car.... as the zero degrees position wil have shifted, there is no adjusment inside a servo.
Because in RC moddeling only +-45 degrees is used, the travel error wont be noticed, if one goes beyond specs as on this board most of us do, nothing is guarenteed.
I would propose that we search for the limits of each and every servo we use, trim the software and never exchange one servo with another to avoid retrimming of the software.
I think a software servo library (which I assume is what the Wiring example is) would be great. Yeah there have to be some coveats but thats ok. I come from using the PICAXE platform which has a "servo" command that allows the pin to be specified and the angle to be specified.
Because of the .75 to 2.25ms pulses every 20ms they simply used a servo position that ranged from 75 to 225. This worked nicely within a byte variable you just have to be sure not to give it a number beyond that range. Also not all servos could drive the full 180 (sometimes not 2 servos of the same make & model) so it would sometimes require testing the limits of each particular servo by starting with a smaller range.
