Truly. It not only replaces standard servos and CR servos in their traditional apps, but it also opens up a world of entirely new apps as well. For example, you could couple two motors to chains or belts on a pair of linear slides to make a simple (small) X/Y positioning device. This is facilitated by the software keeping track of both the shaft angle and multiple rotations and replaces steppers and their drivers in not only this but many similar apps.
Perhaps, once this servo gains a foothold, Parallax might consider offering a larger, higher-powered model based on the same principles.
Neato! It's going to be hard to keep calling these servos servos. They feel light, and I like the matte finish. Same sliver of backlash as the previous CR servos. It appears they do not abruptly turn when power is applied, very nice. I love how quiet they are. The PropC demo is fun, and shows off the actuator capability nicely.
I'll whip up a Halloween device using the two servos, programmed in Blockly.
@Heater: Great question, I agree, you do not want any ramping on a balance bot. Instant response is everything. And you definitely need wheel encoder info to track location with a balancing robot, both to know where you are, and to return to station (the Integral portion of the PID loop).
Many digital servos have factory pre-programmed acceleration curves (on some, like the higher end Hitec's, you can change this and other parameters). I imagine this is what we're seeing.
In any case, a good all-metal gear motor of the appropriate ratio is the better bet for a balancing robot. Direct PWM at higher frequencies provides better control. You're at a disadvantage at 50 Hz, somewhat limiting what you can do. Pololu has some nice ones at about the same price as the 360 servo, though I'm sure Erco knows where to find them for about three fitty...
That's right. I would not want a position feed back servo for a balancing bot. I want my balancing control loop to do the feed back. I probably don't want any ramping between me and the action my control loop demands. Perhaps this is not a suitable motor.
@erco
Why do I "definitely need wheel encoder info to track location with a balancing robot"? There have been plenty of inverted pendulum systems that work really well without knowing absolute position. One might want it for navigation but that is another problem beyond just balancing. I might get my position by other means.
@Gordon.
Why am I "at a disadvantage at 50 Hz"? Assuming my balancing bot is not really small it's not going to be falling over very fast. I would have thought 50Hz is quite enough.
Why am I "at a disadvantage at 50 Hz"? Assuming my balancing bot is not really small it's not going to be falling over very fast. I would have thought 50Hz is quite enough.
You're already applying limits. How about adding "as long as it's slow" to its features? The really cool self-balancing robots are fast, zippy, and nimble, the difference between R2-D2 and BB-8.
On wheel encoders, Erco was talking about odometry. The feedback of the 360 servos can be used for that as well. The decoupling of its encoding hardware is what makes it so useful for various use-cases.
'Hadn't considered the odometry aspect in my response to Heater. A balancing bot with odometry surely would be the Full Meal Deal. So I wonder whether the small corrections needed to maintain balance really would be affected that much by ramping. Disclaimer: I've never programmed a balancing bot.
The other thing I need to check is whether a 200Hz pulse refresh rate (vs. 50Hz) affects the servo's ramping slope. I suspect that it does not.
As a note, the KickStart library for operating a CR servo only applies to running the motor. There is no component in the KickStart library example for reading the PWM signal line to determine position.
This is a new product so it's still early, but you might see if someone on the Arduino forums already has received one of these new servos. Maybe they've created some example code. PropC is similar to Arduino C, so converting it shouldn't be too hard. I plan on doing something with it, but it'll be a month or so before I have the opportunity.
If I could read the feedback signal at all, I could start figuring things out, but I get a constant high on the output. I've connected the feedback directly to pins 8 and 9 (maybe I need pull down resistors?)
I'm trying to get any kind of reading using this code
#include <Servo.h> // Include servo library
const int lFeedback = 8;
const int rFeedback = 9;
long tLow;
long tHigh;
Servo servoLeft; // Declare left servo
Servo servoRight; // Declare left servo
void setup() // Built in initialization block
{
Serial.begin(9600);
servoLeft.attach(12); // Attach left signal to pin 12
servoRight.attach(13); // Attach left signal to pin 13
pinMode(lFeedback, INPUT);
pinMode(rFeedback, INPUT);
servoLeft.writeMicroseconds(1400); // 1.5 ms stay still signal
servoRight.writeMicroseconds(1400); // 1.5 ms stay still signal
I'm not a C programmer, but I suspect these two lines are your problem:
const int lFeedback = 8;
const int rFeedback = 9;
I believe these assign the feedback to pins 8 and 9, rather than your specified 10 and 11.
-Phil
Addendum: 'Hope to get back to more servo testing soon. Today was IRS form 1120 final deadline day, after filing for an extension in March. (Why do I always file for an extension when the weather is crappy, so I have to do the work when its nice? Ugh! Soul-sucking.)
I'm not a C programmer, but I suspect these two lines are your problem:
const int lFeedback = 8;
const int rFeedback = 9;
I believe these assign the feedback to pins 8 and 9, rather than your specified 10 and 11.
-Phil
Addendum: 'Hope to get back to more servo testing soon. Today was IRS form 1120 final deadline day, after filing for an extension in March. (Why do I always file for an extension when the weather is crappy, so I have to do the work when its nice? Ugh! Soul-sucking.)
I originally user 10 and 11 but switched to 8 & 9 because 10 & 11 are for 2 more servos.
You could greatly simplify your testing by removing the servo drive aspect, and just connect the PWM pin of one servo to the controller. Slowly back-drive the servo to see any change in the PWM value. Your test code really only needs to be a few lines long.
The arduino does not have simpletools.h library, but pulse_in is included in the base language.
As FYI, many worker functions including pulseIn (note spelling and capitalization) are defined in Arduino.h, which is comparable to simpletools.h. It's the main include file that is automatically compiled with each sketch, even if you don't explicitly add it.
When using pulseIn, remember to include the third optional parameter, timeout (it should be passed as a long data type). Make the duration value as short as you can. In addition to the docs that come with the servo, Phil has done some research that shows the lower and upper pulse widths. I recall he found some discrepancies in the original docs (which may be amended by now).
If you have some demonstration code showing reading the PWM line from the servo perhaps you could share it for others.
It might also be interesting to add a timer interrupt to periodically read the PWM, rather than include it as part of the program loop. There are numerous ways to set this up, with the Arduino MsTimer2 library being one of the easiest. Doing it this way would more closely mimic how the PropC example works, where reading the position is done in a separate cog.
Phil mentioned the duty cycle, as it relates to angle, can vary depending on temperature, so it'll be necessary to regularly update the tHigh width against tCycle. This is pretty common in PWM applications, and it can be pretty easy if you connect the PWM inputs to pins 2 and 3 of the Arduino, and make use of the external hardware interrupts.
It occurs to me that two kinds of static positioning functions will be required with this servo:
1. One that moves via the shortest path from the current position to the final position, and
2. One that never crosses the zero position (or some other designated position) to get to the target.
The latter is important when the servo is rotating a device (e.g. Ping))) ) with wires attached, so that the wires do not get wrapped around the spindle.
The underlying irony is that I will be at "Elmo Motion Control" in Boston all next week working with one of their prototype Servo control units that comes with a $12k price tag. I'm sure I will learn something. :-)
... I will be at "Elmo Motion Control" in Boston all next week...
XLNT, great town! Why didn't they just call it Elmotion?
Give my regards to Legal Seafood and Bull & Finch (oops, renamed to Cheers now, I'm showing my age). I still gotta thang for Diane. "Good lord, Sam Mallone. Wim with Jim!"
Comments
@Phil - thanks for the photo of the innards!
Truly. It not only replaces standard servos and CR servos in their traditional apps, but it also opens up a world of entirely new apps as well. For example, you could couple two motors to chains or belts on a pair of linear slides to make a simple (small) X/Y positioning device. This is facilitated by the software keeping track of both the shaft angle and multiple rotations and replaces steppers and their drivers in not only this but many similar apps.
Perhaps, once this servo gains a foothold, Parallax might consider offering a larger, higher-powered model based on the same principles.
-Phil
I think at least in R/C, standard size servos aren't still commonly used.
I'll whip up a Halloween device using the two servos, programmed in Blockly.
I just knew you would!
About that ramping. If one were building a two wheel self balancing bot, or some such, wouldn't that ramping mess up the control loop?
Perhaps. But you would not use a position-feedback servo in such a system anyway, since your feedback is coming from accelerometers and gyros.
-Phil
In any case, a good all-metal gear motor of the appropriate ratio is the better bet for a balancing robot. Direct PWM at higher frequencies provides better control. You're at a disadvantage at 50 Hz, somewhat limiting what you can do. Pololu has some nice ones at about the same price as the 360 servo, though I'm sure Erco knows where to find them for about three fitty...
That's right. I would not want a position feed back servo for a balancing bot. I want my balancing control loop to do the feed back. I probably don't want any ramping between me and the action my control loop demands. Perhaps this is not a suitable motor.
@erco
Why do I "definitely need wheel encoder info to track location with a balancing robot"? There have been plenty of inverted pendulum systems that work really well without knowing absolute position. One might want it for navigation but that is another problem beyond just balancing. I might get my position by other means.
@Gordon.
Why am I "at a disadvantage at 50 Hz"? Assuming my balancing bot is not really small it's not going to be falling over very fast. I would have thought 50Hz is quite enough.
You're already applying limits. How about adding "as long as it's slow" to its features? The really cool self-balancing robots are fast, zippy, and nimble, the difference between R2-D2 and BB-8.
On wheel encoders, Erco was talking about odometry. The feedback of the 360 servos can be used for that as well. The decoupling of its encoding hardware is what makes it so useful for various use-cases.
Given that all the mechanical stuff can't respond instantly there must be an update rate beyond which no benefit is gained.
For example a 1 meter stick takes about a second to fall over. So a 1GHz control loop is pretty pointless. Don't you think?
What about 1MHz. Or 1KHz? or 100Hz?
There does not seem to be much point in going much over the frequency response of the whole system. Say 10Hz for my 1 meter high balancing bot.
Still, what do I know, I have never tried to build one. Perhaps I should....
The other thing I need to check is whether a 200Hz pulse refresh rate (vs. 50Hz) affects the servo's ramping slope. I suspect that it does not.
-Phil
The original Segways used a 100 Hz update rate.
The new servo should work with the CR libraries:
http://learn.parallax.com/KickStart
This is a new product so it's still early, but you might see if someone on the Arduino forums already has received one of these new servos. Maybe they've created some example code. PropC is similar to Arduino C, so converting it shouldn't be too hard. I plan on doing something with it, but it'll be a month or so before I have the opportunity.
I'm trying to get any kind of reading using this code
#include <Servo.h> // Include servo library
const int lFeedback = 8;
const int rFeedback = 9;
long tLow;
long tHigh;
Servo servoLeft; // Declare left servo
Servo servoRight; // Declare left servo
void setup() // Built in initialization block
{
Serial.begin(9600);
servoLeft.attach(12); // Attach left signal to pin 12
servoRight.attach(13); // Attach left signal to pin 13
pinMode(lFeedback, INPUT);
pinMode(rFeedback, INPUT);
servoLeft.writeMicroseconds(1400); // 1.5 ms stay still signal
servoRight.writeMicroseconds(1400); // 1.5 ms stay still signal
}
void loop() // Main loop auto-repeats
{
tHigh = tLow = 0;
while (tHigh < 10000 && tLow < 10000)
{
int encoderState = digitalRead(lFeedback);
if (encoderState = 1)
{
tHigh++;
}
else
{
tLow++;
}
delay(1);
}
Serial.print("tLow = ");
Serial.println(tLow);
Serial.print("tHigh = ");
Serial.println(tHigh);
}
At this point, I've given up on the arduino and I'm getting a propeller.
I believe these assign the feedback to pins 8 and 9, rather than your specified 10 and 11.
-Phil
Addendum: 'Hope to get back to more servo testing soon. Today was IRS form 1120 final deadline day, after filing for an extension in March. (Why do I always file for an extension when the weather is crappy, so I have to do the work when its nice? Ugh! Soul-sucking.)
Good move -- for so many reasons!
-Phil
I originally user 10 and 11 but switched to 8 & 9 because 10 & 11 are for 2 more servos.
http://www.benripley.com/diy/arduino/three-ways-to-read-a-pwm-signal-with-arduino/
You could greatly simplify your testing by removing the servo drive aspect, and just connect the PWM pin of one servo to the controller. Slowly back-drive the servo to see any change in the PWM value. Your test code really only needs to be a few lines long.
The arduino does not have simpletools.h library, but pulse_in is included in the base language.
Thanks Gordon & Phil
As FYI, many worker functions including pulseIn (note spelling and capitalization) are defined in Arduino.h, which is comparable to simpletools.h. It's the main include file that is automatically compiled with each sketch, even if you don't explicitly add it.
When using pulseIn, remember to include the third optional parameter, timeout (it should be passed as a long data type). Make the duration value as short as you can. In addition to the docs that come with the servo, Phil has done some research that shows the lower and upper pulse widths. I recall he found some discrepancies in the original docs (which may be amended by now).
If you have some demonstration code showing reading the PWM line from the servo perhaps you could share it for others.
It might also be interesting to add a timer interrupt to periodically read the PWM, rather than include it as part of the program loop. There are numerous ways to set this up, with the Arduino MsTimer2 library being one of the easiest. Doing it this way would more closely mimic how the PropC example works, where reading the position is done in a separate cog.
Phil mentioned the duty cycle, as it relates to angle, can vary depending on temperature, so it'll be necessary to regularly update the tHigh width against tCycle. This is pretty common in PWM applications, and it can be pretty easy if you connect the PWM inputs to pins 2 and 3 of the Arduino, and make use of the external hardware interrupts.
...which is included in the sketch automatically without a #include.
Of course.
1. One that moves via the shortest path from the current position to the final position, and
2. One that never crosses the zero position (or some other designated position) to get to the target.
The latter is important when the servo is rotating a device (e.g. Ping))) ) with wires attached, so that the wires do not get wrapped around the spindle.
-Phil
XLNT, great town! Why didn't they just call it Elmotion?
Give my regards to Legal Seafood and Bull & Finch (oops, renamed to Cheers now, I'm showing my age). I still gotta thang for Diane. "Good lord, Sam Mallone. Wim with Jim!"
https://www.legalseafoods.com/restaurants/boston-long-wharf-63
https://cheersboston.com/locations/beacon