Doesn't work that way. Download the product sheet. It contains some example code (in Prop C) and discussion on how to resolve position from the PWM output signal.
Hmmm .... I should revisit my "Proportional Feedback Application" .... Ken says "...over a year of R&D..." for the 360 Feedback Servo (360-FS) ... I put my application together over a long weekend.
With 18ms "dead time" in a standard servo signal, it's silly not to make the signal pin bi-directional and report position after the command pulse has been sent .... this would allow for using the same 3-wire connection and you wouldn't have to change any of the existing infrastructure ... i.e. 3-wire extension cables used all over Parallax products. The way the 360-FS works now you will need 4-wires. .... Yup, time to revisit my application.
"Position detection:
The code from the feedback360 function needs to be repeated rapidly, at least every ¼ turn, but between every servo pulse (50 Hz) is recommended."
If 3 wires were kept and the Signal line is made bi-directional where the position data is sent back immediately following the Command pulse, it would fit the time requirement mentioned in the datasheet and none of the existing 3-wire infrastructure would need to be changed with the exception of code. ...IOW... existing customers just switch out the old servo for the new.
10-years ago when I put that app together, I went as far as sending the position feedback exactly in this manor. My guess is that the 360-FS has a Melexis hall effect sensor inside the servo which brings up something else people should be aware of. The magnet used to communicate position, could adversely effect a nearby compass sensor.
Interestingly enough there are several Melexis hall effect sensors to choose from on Digikey, even with PWM output and coincidentally with a period frequency of approximately ~1kHz as mentioned in the Datasheet for the 360-FS .... Personally I would have used one of the Melexis hall effect sensors with an analog, or serial output.
Beau, it is what it is, and it looks like a very nice product. The Monday-morning quarterbacking isn't helpful, I'm afraid. But still, if you think you can do it better, you can always invest the bucks and come out with your own servo. Who knows? You might make a million!
Beau, The 360 Feedback Servo replicates a servo and an encoder, and none of these use just three pins. There is no 3-pin infrastructure to maintain in this scenario.
IMO, it's a bad idea to complicate software just to save a pin. Maybe that was needed in the BS2 days, but it's not now. Pins are plentiful, but what isn't as plentiful is people with general knowledge who can understand the more involved timing necessary to share a pin as both input and output. This is especially true of non-Parallax MCUs where someone else has to write a library, or come up with an example. Fortunately, this servo appears a slam-dunk to convert to an Arduino, RPi, or Micro:bit. This is a good thing; it means Ken can sell the servo to all the Luddites as well.
'Got mine today. (Thanks, Ken!) First impressions:
1. Product includes the servo and one servo horn (round, attached with a screw). There are no screws included for attaching things to the servo horn, but #1 sheet metal screws work just fine. As with any servo, do not lose the screw that attaches the horn to the motor shaft. It is not something you'll ever find in a hardware store.
2. Motion at all speeds, including dead slow, is extremely smooth: no jerking or cogging.
3. The encoder output, which I have not yet incorporated but have looked at on a scope, appears very linear with shaft angle.
4. This is important: In my haste to get things working, I sloppily put a 20ms delay between pulses. The servo ran intermittently -- running, stopping, running, stopping, ... When I changed the delay to 20ms from leading edge to leading edge, the motor ran smoothly. Shortening the delay a bit also worked. I guess the lesson is that precision entails a bit of fussiness.
So far, I'm very impressed with this servo, and I intend to try them in a robot arm that used standard servos but lacked precision and repeatability. Repeatability is the next thing I intend to check. More later ...
5. The encoder PWM resolution appears to be 200 ns. I wrote a program to record 1024 encoder values, one for each PWM cycle, while the motor was turning dead slow clockwise. Here's a graph of the results, showing the differences between cnt counts (Propeller 80 MHz) from one PWM pulse to the next:
All differences are a multiple of 16 (200 ns). Interestingly, even though the motor was always turning in a positive direction, a few of the differences are negative. This is to be expected, though, since a reading "on the hairy edge" may be followed by a reading on the other side of that edge if there was no significant position change between readings.
4. This is important: In my haste to get things working, I sloppily put a 20ms delay between pulses. The servo ran intermittently -- running, stopping, running, stopping, ... When I changed the delay to 20ms from leading edge to leading edge, the motor ran smoothly.
Sounds pretty fussy. But I wonder if it was a varying frame rate that was causing an issue with the internal error compensation circuitry. Did it have this behavior when you applied a static pulse to hold the shaft? Or did it only happen when you varied the pulse width to move the shaft.
There is no static pulse to hold the shaft. It's a continuous-rotation servo, so when it's in the dead-zone, no power is applied to the motor, and you can turn the shaft by hand (although you shouldn't). IOW, it's either turning continuously or unpowered. For standard servo operation, it's up to the programmer to apply corrections based on the desired position and the encoder output to hold that position against any external forces -- a function that regular servos perform internally, with the pot as the feedback mechanism.
Didn't really answer the question. While this is a CR servo, you'd still apply a train of pulses of a given width to move it across the floor at a certain speed. Were you changing the width or did it stay the same?
6. Ramping! The servo does its own ramping internally. I suspected this when I heard the unit go from zero to max speed. Unlike a regular CR servo, there were no jarring sounds but, rather, a smooth transition to peak speed. I confirmed it with a program to track the speed as it started up. Here's a graph of the results:
The duration of the ramp in this case is about one-third of a second.
Then that might be a problem with certain MCUs that use software timers for driving servos. Those, like the Arduino, borrows one of the AVR's hardware timers, will have a more consistent pulse repetition, but not all MCUs have this.
This is something I might be interested in learning more about. I'll have to get a couple of these servos to test.
I fiddled an old BoBot to try out this servo open loop. So far I have used the control pin and feedback from the wheel sensor.
1. Don't try running this servo on 5V. It got only to about 100 rpm and had a huge dead zone.
2. There is a LOT of gear noise. It varies as rpm suggesting one or more resonances.
3. At 7.5 volts, it is pretty linear. It runs up to 180 rpm (no load); the dead zone is pretty small.
4. The shaft is a tiny bit shorter (say 1 mm or so) than the old high speed servo. Not much but be careful repurposing an old bobot.
5. At first I found a lot of speed difference depending on shaft angle but I think now that was wheel rubbing on the sensor.
I didn't try anything other than precise 20 msec control signals.
7. The encoder output frequency is temperature-sensitive. Cooling the servo raises the frequency; heating lowers it. At room temperature mine was about 913.5 Hz, cf: 910 Hz. per the docs. What this means is that, for best accuracy, just looking at the pulse width isn't enough: you also need to compare it to the overall period.
Can you supply frequency/temperature data up to, say 450 degrees for project which may or may not involve a flamethrower?
Okaaay. Locked and loaded. You wouldn't happen to know what temperature the plastic housing melts at, would you? Um, Ken, I might need another servo...
Then that might be a problem with certain MCUs that use software timers for driving servos. Those, like the Arduino, borrows one of the AVR's hardware timers, will have a more consistent pulse repetition, but not all MCUs have this.
I really don't see this as a problem. As long as the rising-edge to rising-edge time is 20 ms or somewhat less, the servo will behave itself. Just don't let it be more than 20 ms., and you're good.
I really don't see this as a problem. As long as the rising-edge to rising-edge time is 20 ms or somewhat less, the servo will behave itself. Just don't let it be more than 20 ms., and you're good.
20ms is the nominal spec for refresh rate, and you'd naturally expect some variance either way. Again, I'm concerned about those MCUs that only drive servos via a software loop having enough time to keep this rate. It's been an old trick to reduce the frame rate from 50 Hz to maybe 40Hz or even lower in order to get in a few more clock cycles for other tasks, like reading sensors. Traditionally servos have been able to handle this (though at lower torque, if analog)
Then again, the world turns, and the majority of new controllers should have no problem meeting this spec.
8. The docs spec 91.7% as the maximum encoder duty cycle. I'm getting more like 97.1% Perhaps the former is a typo?
-Phil
Edit: The C code confirms it: 97.1%.
Edit 2: I also have a slight quibble with the "+ 1" in the denominator of the formula on page 4 of the docs. The effect that it has will depend entirely upon the scaling factor for the duty cycle figures. To make a proper adjustment, I think it's necessary to determine exactly how close to one clockwise revolution the 97.1% duty cycle corresponds to. Then use a figure for what the extrapolated duty cycle "would be" at 360 degrees for "duty cycle max." That would eliminate the necessity of the "+ 1" in the denominator.
9. I couldn't help but to peek inside the servo. After removing the horn and four housing screws, the bottom and top housing segments separated from the middle one easily. There's stuff in the middle segment that I really wanted to see, but I was afraid of pulling on too many press-fits and either breaking something or not being able to reassemble it. Anyway, what I did notice is that although the gears are plastic, the output shaft is supported by two metal ball-bearings. Nice!
10. The servo works fine with even a 5 ms control-pulse delay time. That still leaves plenty of time between pulses to read the encoder. This could be significant when holding a set position, since corrections can be applied more quickly, resulting in less vibration. (Actually, even at 20 ms, my Spin program does not produce the vibration suggested by the docs when holding a position; but, admittedly, this is without an inertial load.)
Comments
With 18ms "dead time" in a standard servo signal, it's silly not to make the signal pin bi-directional and report position after the command pulse has been sent .... this would allow for using the same 3-wire connection and you wouldn't have to change any of the existing infrastructure ... i.e. 3-wire extension cables used all over Parallax products. The way the 360-FS works now you will need 4-wires. .... Yup, time to revisit my application.
http://forums.parallax.com/discussion/84991/propeller-application-proportional-feedback-from-a-standard-hobby-servo-upda
From the data sheet: https://www.parallax.com/downloads/parallax-feedback-360°-high-speed-servo-product-guide
"Position detection:
The code from the feedback360 function needs to be repeated rapidly, at least every ¼ turn, but between every servo pulse (50 Hz) is recommended."
If 3 wires were kept and the Signal line is made bi-directional where the position data is sent back immediately following the Command pulse, it would fit the time requirement mentioned in the datasheet and none of the existing 3-wire infrastructure would need to be changed with the exception of code. ...IOW... existing customers just switch out the old servo for the new.
10-years ago when I put that app together, I went as far as sending the position feedback exactly in this manor. My guess is that the 360-FS has a Melexis hall effect sensor inside the servo which brings up something else people should be aware of. The magnet used to communicate position, could adversely effect a nearby compass sensor.
Interestingly enough there are several Melexis hall effect sensors to choose from on Digikey, even with PWM output and coincidentally with a period frequency of approximately ~1kHz as mentioned in the Datasheet for the 360-FS .... Personally I would have used one of the Melexis hall effect sensors with an analog, or serial output.
-Phil
IMO, it's a bad idea to complicate software just to save a pin. Maybe that was needed in the BS2 days, but it's not now. Pins are plentiful, but what isn't as plentiful is people with general knowledge who can understand the more involved timing necessary to share a pin as both input and output. This is especially true of non-Parallax MCUs where someone else has to write a library, or come up with an example. Fortunately, this servo appears a slam-dunk to convert to an Arduino, RPi, or Micro:bit. This is a good thing; it means Ken can sell the servo to all the Luddites as well.
1. Product includes the servo and one servo horn (round, attached with a screw). There are no screws included for attaching things to the servo horn, but #1 sheet metal screws work just fine. As with any servo, do not lose the screw that attaches the horn to the motor shaft. It is not something you'll ever find in a hardware store.
2. Motion at all speeds, including dead slow, is extremely smooth: no jerking or cogging.
3. The encoder output, which I have not yet incorporated but have looked at on a scope, appears very linear with shaft angle.
4. This is important: In my haste to get things working, I sloppily put a 20ms delay between pulses. The servo ran intermittently -- running, stopping, running, stopping, ... When I changed the delay to 20ms from leading edge to leading edge, the motor ran smoothly. Shortening the delay a bit also worked. I guess the lesson is that precision entails a bit of fussiness.
So far, I'm very impressed with this servo, and I intend to try them in a robot arm that used standard servos but lacked precision and repeatability. Repeatability is the next thing I intend to check. More later ...
-Phil
5. The encoder PWM resolution appears to be 200 ns. I wrote a program to record 1024 encoder values, one for each PWM cycle, while the motor was turning dead slow clockwise. Here's a graph of the results, showing the differences between cnt counts (Propeller 80 MHz) from one PWM pulse to the next:
All differences are a multiple of 16 (200 ns). Interestingly, even though the motor was always turning in a positive direction, a few of the differences are negative. This is to be expected, though, since a reading "on the hairy edge" may be followed by a reading on the other side of that edge if there was no significant position change between readings.
-Phil
Sounds pretty fussy. But I wonder if it was a varying frame rate that was causing an issue with the internal error compensation circuitry. Did it have this behavior when you applied a static pulse to hold the shaft? Or did it only happen when you varied the pulse width to move the shaft.
-Phil
-Phil
6. Ramping! The servo does its own ramping internally. I suspected this when I heard the unit go from zero to max speed. Unlike a regular CR servo, there were no jarring sounds but, rather, a smooth transition to peak speed. I confirmed it with a program to track the speed as it started up. Here's a graph of the results:
The duration of the ramp in this case is about one-third of a second.
-Phil
Then that might be a problem with certain MCUs that use software timers for driving servos. Those, like the Arduino, borrows one of the AVR's hardware timers, will have a more consistent pulse repetition, but not all MCUs have this.
This is something I might be interested in learning more about. I'll have to get a couple of these servos to test.
1. Don't try running this servo on 5V. It got only to about 100 rpm and had a huge dead zone.
2. There is a LOT of gear noise. It varies as rpm suggesting one or more resonances.
3. At 7.5 volts, it is pretty linear. It runs up to 180 rpm (no load); the dead zone is pretty small.
4. The shaft is a tiny bit shorter (say 1 mm or so) than the old high speed servo. Not much but be careful repurposing an old bobot.
5. At first I found a lot of speed difference depending on shaft angle but I think now that was wheel rubbing on the sensor.
I didn't try anything other than precise 20 msec control signals.
7. The encoder output frequency is temperature-sensitive. Cooling the servo raises the frequency; heating lowers it. At room temperature mine was about 913.5 Hz, cf: 910 Hz. per the docs. What this means is that, for best accuracy, just looking at the pulse width isn't enough: you also need to compare it to the overall period.
-Phil
Excellent work, PhiPi! Can you supply frequency/temperature data up to, say 450 degrees for project which may or may not involve a flamethrower?
JK, Boss. As ever, you are the MAN!
Okaaay. Locked and loaded. You wouldn't happen to know what temperature the plastic housing melts at, would you? Um, Ken, I might need another servo...
-Phil
I really don't see this as a problem. As long as the rising-edge to rising-edge time is 20 ms or somewhat less, the servo will behave itself. Just don't let it be more than 20 ms., and you're good.
-Phil
Phil, I can send you more for destructive testing - just ask. Maybe 450F is a good temperature for educational robotics contests. . .
Ken Gracey
20ms is the nominal spec for refresh rate, and you'd naturally expect some variance either way. Again, I'm concerned about those MCUs that only drive servos via a software loop having enough time to keep this rate. It's been an old trick to reduce the frame rate from 50 Hz to maybe 40Hz or even lower in order to get in a few more clock cycles for other tasks, like reading sensors. Traditionally servos have been able to handle this (though at lower torque, if analog)
Then again, the world turns, and the majority of new controllers should have no problem meeting this spec.
8. The docs spec 91.7% as the maximum encoder duty cycle. I'm getting more like 97.1% Perhaps the former is a typo?
-Phil
Edit: The C code confirms it: 97.1%.
Edit 2: I also have a slight quibble with the "+ 1" in the denominator of the formula on page 4 of the docs. The effect that it has will depend entirely upon the scaling factor for the duty cycle figures. To make a proper adjustment, I think it's necessary to determine exactly how close to one clockwise revolution the 97.1% duty cycle corresponds to. Then use a figure for what the extrapolated duty cycle "would be" at 360 degrees for "duty cycle max." That would eliminate the necessity of the "+ 1" in the denominator.
9. I couldn't help but to peek inside the servo. After removing the horn and four housing screws, the bottom and top housing segments separated from the middle one easily. There's stuff in the middle segment that I really wanted to see, but I was afraid of pulling on too many press-fits and either breaking something or not being able to reassemble it. Anyway, what I did notice is that although the gears are plastic, the output shaft is supported by two metal ball-bearings. Nice!
-Phil
-Phil
10. The servo works fine with even a 5 ms control-pulse delay time. That still leaves plenty of time between pulses to read the encoder. This could be significant when holding a set position, since corrections can be applied more quickly, resulting in less vibration. (Actually, even at 20 ms, my Spin program does not produce the vibration suggested by the docs when holding a position; but, admittedly, this is without an inertial load.)
-Phil