Shop OBEX P1 Docs P2 Docs Learn Events
New Parallax 360 Feedback Servo - Page 2 — Parallax Forums

New Parallax 360 Feedback Servo

2456789

Comments

  • WhitWhit Posts: 4,191
    edited 2017-09-15 21:25
    Ran mine through the sample code today. What a neat servo this is! Can't wait to get it on a bot!

    @Phil - thanks for the photo of the innards!

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-09-13 03:28
    Whit wrote:
    What a neat servo this is!

    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
  • If Parallax offered a submicro/micro version (not sure if this is possible) I would implement it into my product today.

    I think at least in R/C, standard size servos aren't still commonly used.
  • 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.

  • ercoerco Posts: 20,256
    xanadu wrote: »
    I'll whip up a Halloween device using the two servos, programmed in Blockly.

    I just knew you would! :)

  • Heater.Heater. Posts: 21,230
    These sound like excellent motors.

    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?
  • heater wrote:
    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
  • ercoerco Posts: 20,256
    @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...
  • Heater.Heater. Posts: 21,230
    @Phil,

    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.



  • Heater. wrote: »
    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.

  • Heater.Heater. Posts: 21,230
    I don't want to apply limits. I'm curious as to what a suitable control loop update rate needs to be for an inverted pendulum.

    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....



  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-09-14 18:46
    '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.

    -Phil
  • Are there arduino libraries available?
  • W9GFOW9GFO Posts: 4,010
    Heater. wrote: »
    I don't want to apply limits. I'm curious as to what a suitable control loop update rate needs to be for an inverted pendulum.

    The original Segways used a 100 Hz update rate.

  • pwiecek wrote: »
    Are there arduino libraries available?

    The new servo should work with the CR libraries:

    http://learn.parallax.com/KickStart





  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2017-09-15 20:46
    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.
  • pwiecekpwiecek Posts: 21
    edited 2017-09-16 00:58
    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

    }
    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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-09-16 01:02
    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.)
  • pwiecek wrote:
    At this point, I've given up on the arduino and I'm getting a propeller.

    Good move -- for so many reasons! :)

    -Phil
  • I would have done it from the beginning but I already have an arduino and a 1Sheeld. Hopefully the 1sheeld will work with the ASC+.
  • 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 might want to use pulseIn or another technique (see the link below) rather than trying to catch the PWM with digitalRead.

    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.
  • pwiecekpwiecek Posts: 21
    edited 2017-09-16 21:44
    Okay, that seems to be working.

    The arduino does not have simpletools.h library, but pulse_in is included in the base language.

    Thanks Gordon & Phil
  • pwiecek wrote: »
    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.

  • pwiecekpwiecek Posts: 21
    edited 2017-09-17 01:38
    As FYI, many worker functions including pulseIn (note spelling and capitalization) are defined in Arduino.h...

    ...which is included in the sketch automatically without a #include.
    If you have some demonstration code showing reading the PWM line from the servo perhaps you could share it for others.

    Of course.
  • 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.

    -Phil

  • pwiecekpwiecek Posts: 21
    edited 2017-09-18 09:54
    I'm switching to the ASC+ so I probably won't be converting anything to the Arduino.
  • 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. :-)
  • ercoerco Posts: 20,256
    ... 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!"

    https://www.legalseafoods.com/restaurants/boston-long-wharf-63

    https://cheersboston.com/locations/beacon





Sign In or Register to comment.