Is it because they taught us mostly in degrees in school? Trig is easier to do in radians. And before you tell me that it's easier for you to visualize, let me convince you otherwise.
A normal servo moves 180 degrees or pi radians.
Wanna move half way? 90 degrees. Or pi * 1/2 radians.
Wanna move a quarter of the way? That's 45 degrees. Or pi * 1/4 radians.
Starting to see a pattern? Well, it's been easy so far. Now, what if you want to move 13/27 of the way? For degrees you're going to have to do some calculating. I don't know that one off the top of my head. But for radians it's pi * (13/27). Doesn't get much easier.
Wanna go 34.25% of the way? pi * 0.3425 Works for percentages too.
If we use radians for servo position then we don't have to worry about converting back and forth needlessly to do trig functions. All the good trig functions want radians. That's because it's easier to do. Again, you take the pi out and the fraction left tells you where on the sin wave you are. If we just keep radians to begin with, then we can skip the whole conversion back and forth that invariably accompanies those functions.
You can store milli-radians in an int and let it go from positive 31415 to -31415. You have to do a little bit of extra math if you go more than one rotation. But you have that same problem with degrees too.
Am I missing some reason that we don't have a writeRadians function in Servo.h? Not that I'm advocating for adding it. Just wondering if there's some other reason that never caught on.
I can recall a question along the lines of, "How do I convert from radians to degrees?" Are you aware of that being in the context of of servos? In other words, do you know of folks here wanting to perform that conversion just so they can feed degrees to the servo library?
Are you aware of any servos accurate to something better than milliradians (1 mrad)?
Update: I think the servo library uses values between 0 and 1023. That would be way more granularity than 1 mrad.
Well, I'd suggest that its
partly because we are more familar with degrees as a unit;
partly because the "degrees" unit is a useful size - and thanks (its said) to the babylonians the value of 360 for a complete circle has so many factors.
For humans there is a lot to be said for units that have a practical size comparable to our own requirements. Fortunately since metrication we can still buy a pint - or a "half" of beer.
The pin spacing on DIP IC's - and your breadboard - is a tenth of an inch.
Try imagining that as a fraction of a furlong.
However in an engineering /IT environment we work with integers. Even our "real"s fundamentally are reresented by integers.
And it is not possible accurately to represent Pi() in that environment.
So work in radians - or milliradians - and over time you will see an error.
I have an aversion to using variables other than 8 bit hex or int. Most of the time, I will specify unsigned variables. Floats are acceptable when they only have soda (Mt Dew or Root Beer) and ice cream.
Of course, I have 32 bit Arduino devices. However, the 8 bit Arduinos are the ones that get used.
Ner, its SI.
In 1958, a conference of English-speaking nations agreed to unify their standards of length and mass, and define them in terms of metric measures. The American yard was shortened and the imperial yard was lengthened as a result. The new conversion factors were announced in 1959 in Federal Register Notice 59-5442 (June 30, 1959), which states the definition of a standard inch: The value for the inch, derived from the value of the Yard effective July 1, 1959, is exactly equivalent to 25.4 mm.
No, I ask - if they agreed to unify standards and changed the yard in both US and UK - why not to unify standards little further and not to start using meters and kilograms ?
Of course, computers have to use an approximation of pi. In the real world of engineering & technology it's also an approximation. (Although that doesn't stop anybody from creating a right angle.)
I have an engineering degree and my brain defaults to degrees.
If you asked 100 college students to draw a pi * 1.2 radians angle, how many could do it? Maybe one? Hopefully most math students could do it, but I'd bet less than half of engineering & science students could do it without at-least some thinking, and most would probably whip-out their phone to calculate it or look it up. ...Try asking everybody in your family to draw a pi * 1/2 radians angle!
Also. it is easy to draw a 600 angle using a protractor, but is it difficult to draw the equivalent (inaccurate) 1.0472c angle!
First, let us draw a circle and then take a chord equal to 1.0472 times of the radius and then join the intersection points of the chord with the centre of the circle. The subtended angle of the chord at the centre of the circle is the equivalent (inaccurate) radian angle for 600. I exercised this in my Class-IX on work book back in 1969!
A curious mind wishes to know the advantage of using unlimited circular/trigonometrical angle (measured in radian) over limited geometrical angle (measured in degree).
There is another unit of measuring angle -- grad (gradian); where is that?
If we'd head in this direction, we could say that mu radians makes more sense than 2pi radians. Then set it on a scale of 1000 and representing 1.000mu and you've got something that represents the percentage of rotation, fits into 16 integer bits, requires no floating-point math, and very little thought.
Drawing the two should be an equivalent exercise. I mean, can you really draw a 60.000 degree angle with a protractor and have it accurate to 4 or 5 decimal places? It just matters how your protractor is labelled.
The point I was making is that yes, radians are difficult to work with when you look at them as pure decimal numbers. But when we factor the pi out we get rid of the inaccuracy and actually make something easier to deal with.
Draw that same 60 degree angle without the protractor? You will have to divide 60 into 180 to see that it is 1/3 of a half circle and then divide a half circle into three equal parts. That's easy to do geometrically with a compass and a straight edge. With the radian measure we wouldn't write it as 1.0472. We would write pi / 3 or (1/3) * pi. That removes one calculation step.
But more importantly, is when we are doing it in code. With a geometric construction you just have an extra calculation to do. But when we write code those calculations come at a time cost that we are often times trying to minimize. In those cases you see people converting back and forth because it is easier to visualize. But I don't think that it actually is when you keep the pi factored out.
Take for instance a project to make a gauge. It would be common to see someone first calculate the percentage of scale that they wish to show, then convert that into degrees to figure how far to move the needle, and then convert from degrees to microseconds pulsewidth to move a servo. But the calculation to degrees is pointless and redundant. If you know the percentage you want to move then you should be able to just calculate your pulsewidth directly from that. The pi is factored out on both ends so all that's then needed is map your percentage onto it's pulse width limits.
@Delta_G
First of all, thanks for a thought provoking and scientific post #17.
P1 (Para 1 of post #17): If protractor is not allowed but the compass, then I have to make few trials (say: n times) to divide the semi-circle into three equal parts to create a 600 angle at the centre of the circle.
If I am to make an equivalent angle in radian using a compass, then I have to make >n trials for measurinng 472th of the radius of the said circle.
P2: Right! When pi (3.14) is multiplied by 100, it becomes a sound number like 314; as a result, it is possible to make a protractor for radians and its fractions.
P3:
Not undestood fully!
P4:
P5: For example on SG-90 Servo Motor
The SG-90 Servo Motor requires a continuous pumping of 50 Hz PWM signal to hold its shaft at a partcular position within 00 to 1800.
The Servo.h Library takes the argument of write(arg) method as an angle in degree if it is < 180; else, it is a pulse width in microsecond.
If I wish to present the charging state of a Battery as 0%, 10%, ..., 90%, 100% on a Circular Gauge, then I would prefer to using degree instead of radian to map the shaft position into percentage.
They taught us geometric constructions in junior high school geometry class. You don't need multiple trials. You just need good powers of deduction.
Or instructions. I couldn't find one for the third of a half circle, but you can imagine doing the same trick twice to get a 6th of a circle.
No, you are confused somewhere. The equivalent angle is an equivalent angle. It's still 1/6 of a circle, or 1/3 of a half circle. We can call it 60 degrees, which gives no information on how much to divide our circle, or we can call it pi/3 radians, which tells us exactly how to subdivide. We can see the 1/3 factor right there and that's the part of the semicircle we want.
It's not even like that. Every angle has a measure in both units. There is a simple mapping of one unit onto the other. For any angle you describe, I could tell what the same angle is measured in rad.
So this requires
Calculate the percentage of the scale.
Calculate that percentage of 360 degrees
Calculate the pulse width for that angle (done in Servo library)
I think the middle step is redundant. All it does is change the units. If we imagine our servo to take pulse widths from 544uS to 2400uS (defaults for Servo.h) then why can't we just map the percentage directly onto that. Why would you ever need to calculate degrees if you know what percentage of that pulse width range you want.
I would rather feed my servo the percentage that I just calculated than to have to convert that to degrees first. That is an extra step.
