Loading ...
Sorry, an error occurred while loading the content.

Re: [SeattleRobotics] Re: Doing PID is (not) like being intelligent

Expand Messages
  • Peter Balch
    Randy ... Yes. I understand what the I term does. I understood it twenty years ago. I understand that it _could_ be applied to mobile robots but I don t
    Message 1 of 30 , Feb 1, 2012
    View Source
    • 0 Attachment
      Randy

      > I hope you will be able to
      > understand what the I term does, and how it learns its value
      > over time, and how that lets the power plant make its own
      > adjustments for current conditions.

      Yes. I understand what the I term does. I understood it twenty years ago. I
      understand that it _could_ be applied to mobile robots but I don't believe
      that it _should_.

      > Yes, we know. You have repeated your argument many times. But it
      > has no substance which can be addressed, because it is based on
      > mis-impressions rather than facts.

      Mis-impressions? Well, certainly a different impression of what mobile
      robots are about.

      You call my "different impression" a "mis-impression" and I call your
      "different impression" a "mis-impression".

      I thiink your more detailed explanation of your profiling method makes clear
      our different belief systems.

      I'll try one last time. From the top ...

      Imagine two robots, one is a micromouse and one is a Grand Challenge
      competitor. Both are mobile robots. Both are "navigating". But the
      micromouse definitely isn't on The Path To Robot Enlightenment. I'm sure
      that the people who build micromice are very clever and skillful and have a
      lot of fun but micromouse is not on The Path just the same as Deep Blue
      isn't on the path to general machine intelligence. The environments they
      operate in are too Clean.

      Whether a Grand Challenge competitor is on The Path, I don't know. I realise
      that Grand Challenge has its critics but I'm vey impressed. I think it's
      much closer to The Path than most (or all other?) mobile robots.

      So I'm going to assume that Grand Challenge is Good and micromouse is Bad.
      I'm going to respond to your points within that context. If you can explain
      to me why that context is wrong then I'm very keen to listen. Maybe you
      believe that micromouse is on The Path and Grand Challenge isn't.


      > The problem with a P-velocity loop is, to stop, you command a 0
      > speed. The slope gives you some bias such that you slip and roll
      > a bit. ...

      OK. That's a good illustration.

      How does micromouse shape up? Well, if the micromouse maze had slopes and
      the mouse was expected to stop on them then you would have a completely
      valid criticism.

      What about Grand Challenge? Well when I stop my car on a hill, I use the
      handbrake. If a robot wants to stop still, shouldn't it do the same? You
      wouldn't stop your car on a hill by slipping the clutch. Didn't the Urban
      Challenge robots stop for a while? I bet they didn't do it with a
      position-PID.

      One hundred-and-ninety-something message ago (it's been a long thread!) I
      said a couple of times that if you think your navigation algorithm needs a
      PID then you're doing it wrong. In this instance, if you think your PID
      should act as a parking brake then you're doing it wrong.

      > And what is the destination for again? Oh yes, the end "point",
      > the whole "point" of making the journey.

      Micromouse has several "points" - they are the end of the corridor where
      it's going to make the next turn. It would be foolish not to use a PID.
      Micromouse is in a race so you want to get to the end of the corridor as
      fast as possible and when you reach it have zero velocity so you can to a
      90deg turn. You know that the floor is clean. You (probably) know how fast
      you can accelerate/ brake without skidding so you use the best profile you
      can.

      Grand Challenge isn't like that. Although there might be a "point" somewhere
      in the far distance, you're more worried about the next corner or whether to
      slow down for that dark patch - is it a shadow or a hole? If you use a
      position-PID, you have to write it as a carrot-and-stick, with the stick
      length depending on current conditions. Because it's a carrot-and-stick,
      neither the D-term nor the I-term have any function and you might as well
      use a velocity-P controller. (Or, as you point out below, you use a very,
      very short stick and rely on the I term. Maybe you can discard the D and P
      terms.)

      > > With a position-PID, you need profiling s/w
      > > to decide on the velocity for the current
      > > conditions (mud, hill, gravel, etc.)
      > No. You miss the point. With a position-PID, you profile a
      > velocity and completely ignore current conditions (mud, hill,
      > gravel, etc) whatever!

      Yes, for micromouse you can profile the whole journey from one end of a
      corridor to the other. All corridors have identical traction, slope, etc.

      You definitely can't profile the whole journey for a Grand Challenge robot.
      Nor can you for, say, a robo-magellan going through mud, hill, gravel, etc.
      unless you know about the mud/hill/gravel in advance. If you program your
      profile for constant velocity between start and finish then, after it's gone
      through some slow mud, the robot will be so far behind the carrot that it
      will race at top-speed to catch up.

      If your algorithm assumes you can profile is all in advance then you're
      doing it wrong. (Or you're doing it in such a Clean world, your world is
      wrong.)

      > > The buggy never reaches the carrot so the
      > > I-term is redundant.
      > Assuming a long smooth roll (basically a
      > velocity-limited constant speed portion of the move, not ramping
      > up or down) the I term is the only term active. P and D are 0.

      Aha. Now that is interesting.

      Clearly, you can do it either way. You can use the P-term to force the robot
      to move (because it lags behind the target) or you can use the I-term. If
      you're using the I-term then you assume that the P-error is very small.
      Right? Ideal for micromouse.

      But it means that when the robot get's slowed-down in mud, the target must
      get ahead. The robot has slowed-down but the target, the carrot, continues
      on its pre-programmed way. The position-PID is doing its utmost to keep up
      with the carrot but the mud slows it (but doesn't stop it). When the robot
      gets through the mud, it's then way behind the target and rushes at far more
      than the pre-programmed speed to catch up. What's the point of that? Is it
      trying to catch a train? That kind of behaviour would be disasterous for a
      Grand Challenge robot. It must try to go at the right speed for the
      conditions.

      So once again, if your algorithm uses a position-PID then you're doing it
      right for micromouse but doing it wrong for Grand Challenge. And micromouse
      isn't on The Path.

      > Now if the terrain isn't as smooth as all that, it will arrive
      > later or earlier. If it arrives early (gone-too-far error), the
      > P compensates by being negative, and the I term winds down just
      > a touch. If it arrives late (hasn't-gone-far-enough error), the
      > P compensates by being positive, and the I term winds up just a
      > touch. Since these corrections are very minor, the speed is near
      > constant, and the difference between where it is supposed to be
      > and where it is, is 0 or very near it,

      The P will be huge if the robot has just been slowed down by mud. So for
      your argument to be true, the P-constant must be small so the overall effect
      on the command to the motor will be reasonable.

      > Misconceived. If you want to hold a position, you need a
      > position loop.

      But, in Grand Challenge, if I want to hold a position, I use the parking
      brake. If I use a PID, I'm doing it wrong.

      > When you read your encoders, you get position, not distance, not
      > velocity.

      And Dave makes the same point. It's a good point. To get velocity, you have
      to count encoder transitions for a fixed period and to get decent resolution
      you need a long period. And a long period slows down your control-loop time.

      Well, that's one algorithm. The other is to time, say, 10 transitions. Or
      even just two transitions and smooth it.

      Clearly, there's a relationship between the resolution required of your
      encoder and the accuracy required in your navigation. That's true for both a
      position-PID and a plain velocity control. For a micromouse, you might worry
      about knowing the length of the corridor within millimetres - but in
      micromouse, you _do_ know the exact length of the corridor. In Grand
      Challenge you don't. If the algorithm you use in Grand Challenge requires to
      know the exact length of the corridor then you're doing it wrong. In Grand
      Challenge, the resolution of the velocity-encoder must be sufficiently fine
      that it's, what, ten times "better" than the rate at which the car can speed
      up or slow down? That seems perfectly achievable.

      > Well, the other option is not to sense the bump at the level of
      > the drive plant, and just sit there and not go over the bump.
      > Let some "deus ex machina" device way up the command and control
      > structure notice, "Oh, we stopped moving, what's the problem?
      > Maybe we need to try some more power to get over a bump?"

      Yep. Because the "deus ex machina" way up the command structure is evenally
      going to have to decide whether the bump requires some other behaviour -
      like rocking or wiggling or backing up and going round. Except, of course,
      that such a "deus ex machina" is absolutely not required in micromouse. If
      you're treating your robot like a micromouse then you're doing it wrong.

      > Would you have the highest level of command and control be
      > consciously deciding what power to apply to the motors?

      No, I'd tell the car what speed it should be going at, not how far it should
      be along the road (measured in feet). That's what the accelerator pedal in
      my car does (well, that's what it _ought_ to do; it doesn't of course).

      > When did we get a current reading in this discussion? Other than
      > when Ken pointed out you'd need one to read force (torque)?

      Clearly, you don't need to know current for a micromouse. But torque would
      be a very useful quantity to know for a Grand Challenge robot.

      I expect you can do all of a micromouse speed/distance control using a
      position PID. But you can't do that for a Grand Challenge robot.

      Why on earth _wouldn't_ I use the current reading? It's useful information
      my H-bridge chip should be giving me for free.

      If you build a robot that only has a position-PID, it will work fine for
      micromouse but not for Grand Challenge.

      Once again, we get back to my original point: if you think you can do it all
      with a position-PID, you're doing it wrong.

      > But I think in the end, the argument boils down to optical
      > encoders read position. So the least complicated implementation
      > for best performance is a position PID which is profiled.

      That's a good point. Except that optical encoders can also read velocity (by
      timing rather than counting).

      > But that hasn't been the basis of this discussion. We were
      > discussing optical encoders as the sensors.

      No, it started as "Locked-antiphase" then was re-titled as "Accurate
      odometry". My point is that accurate odometry is good for micromouse but not
      for Grand Challenge. If you (Randy) use a position-PID then I'm sure you are
      doing the PID right. You're an expert on such things. But you shouldn't be
      using a position-PID in the first place.

      Peter
    • dcwjobs2004
      None, really. I was just side-stepping the non-linear brush loss problem for the sake of simplifying the argument. A brush less DC (BLDC) motor looks like a
      Message 2 of 30 , Feb 1, 2012
      View Source
      • 0 Attachment
        None, really. I was just side-stepping the non-linear brush loss problem for the sake of simplifying the argument.

        A brush less DC (BLDC) motor looks like a brushed DC motor turned inside out. A BLDC motor has a rotating magnet and coils in the stator that attract the magnet as it goes around. A combination of a shaft encoder and MOSFET switches serve as the commutator in the BLDC motor rather than a segmented cylinder and brushes.

        A typical BLDC motor has 3 coils, a 3-phase motor. The trick is to apply voltage to the coils in a sequence to cause the rotor to spin. Current is applied to the next coil ahead of the magnet to pull it forward.

        In the classical case, you have a 3 count per revolution shaft encoder (magnet + hall effect sensors) that serves as the commutator
        The encoder and switches are set up to always select the next coil ahead of the current rotor position to keep pulling the magnet in the rotor forward. The encoder output drives MOSFET switches to connect the selected coil to the DC supply. For a discussion of this for electric airplane motors, see:

        http://adamone.rchomepage.com/guide5.htm

        The singularly nice idea about a BLDC motor is you have no non-linear brush-arc voltage drop. You have the voltage drop across milliohm MOSFETs that serve as the commutator instead of brushes. So it looks like a perfect DC brushed motor to the system.

        It has been a while since I looked, but off the shelf BLDC motors are still somewhat expensive, except for the electric airplane (and helicopter, boat & car) hobby market. Examples are the motors used in electric airplanes. A 1 hp BLDC motor you can hold in your hand spins at 10-50K RPM and sells for ~$15. See:

        http://www.hobbypartz.com/motors.html?gclid=CIrZjtHb_q0CFQwzhwodNk0luw

        To use these in a robot would require some *serious* gear reduction. But you would get some serious power: an Elite 400 (4200kv) Brushless Motor puts out 200W (~1/4 hP), weighs 2.4 oz, draws 18 Amps at 12 Volts and sells for $11.90. Other alternatives are BLDC motors for helicopters, RC cars and RC boats.

        Note: These motors work with a ~$12 controller to generate the 3 phase signals to the stator coils and use the back-EMF from the motor coils for velocity feedback in an "sensor-less" approach. You apply a 0-5V control voltage to get a 0-full speed output. As in, it has a 3 phase H-bridge built-in.

        Brushed DC motors are still cheap and cheaper on the surplus market. But BLDC motors are inherently simpler and more reliable mechanically, and the electronics are also cheap these days. No brushed = no brushes to wear out. Windings in the stator are easier to cool, also. So I think that DC and servo motors will eventually all go BLDC. They will be cheaper, as well as better.

        A trivia point: A stepper motor is a 2-phase BLDC motor. Usually you get many more than 3 steps per revolution, but otherwise it is the same: rotating magnet + stator coils. The bigger thing about a 3-phase BLDC motor is that it typically spins (much) faster. And power is speed x torque, where the torque is set by the magnetics.

        But that does not mean that steppers are necessarily slow. I worked with a consultant designing a stepper motor driven fast servo system. It ran at 0 to 20,000 steps per second. This worked out to 6,000 RPM!

        Food for thought,

        Dave Wyland


        --- In SeattleRobotics@yahoogroups.com, "David Buckley" <david@...> wrote:
        >
        > Hi Dave Wyland
        > > H-bridge driving a BLDC motor
        > Which particular H-bridge / BLDCcontroller / BLDCmotor setup did you have in mind?
        > DAvid
        >
        > ----- Original Message -----
        > From: dcwjobs2004
        > To: SeattleRobotics@yahoogroups.com
        > Sent: Monday, January 30, 2012 8:38 AM
        > Subject: [SeattleRobotics] Re: Doing PID is (not) like being intelligent
        >
        >
        >
        > Hi Randy,
        >
        > I hesitate to jump in here, but I have a comment or two that might help. I think in analog terms, so I may bring a different point of view to the topic.
        >
        > In your (3rd paragraph) example of the P-velocity loop, I look at it in the following way. To begin with, I start with a pure velocity loop, like the H-bridge driving a BLDC motor. (I am cheating: BLDC = brush-less - as in no brush drop - DC motor). Stick the motor and wheel on a slope and command a zero velocity from the H bridge. (This is the same as shorting out the motor.)
        >
        > The wheel starts to roll down the slope. This will generate back-EMF from the motor. This back-EMF voltage will appear across the winding resistance of the (shorted out) motor, generating a torque that counteracts the velocity. The velocity of the wheel will increase until the torque in the motor just counteracts the increasing motor speed. The wheel will stabilize at this velocity, until you run out of hill. The resulting voltage across the winding resistance corresponds to the constant velocity error for the particular hill angle. The error will be governed by the loop gain = back-EMF constant (volts/RPM) / (winding resistance).
        >
        > If you set the H bridge voltage to apply a constant positive velocity, you can set it to just counteract the (negative) downhill roll. So a constant velocity error generates enough counter-torque to for zero output velocity.
        >
        > Now, put this inside a position loop. In the P loop, a position error generates a commanded velocity. Let us command a zero position, as in stick the wheel on the hill and tell it to stay there. A position encoder on the wheel tells us our actual position, versus the commanded position of zero. The wheel starts to roll down the hill. We start getting a negative position error. We feed the position error to the velocity loop, which commands a positive velocity to counteract the negative actual position the slope.
        >
        > As the position error builds up, the commanded velocity also builds up. Eventually, the commanded velocity is high enough to just counteract the velocity down the slope, as in the velocity loop example above. The loop stabilizes at a constant position error and a constant (commanded) velocity error. The position error generates the velocity error that generates the motor torque to counteract the roll. The size of the position error is inversely proportional to the velocity error gain times the position error gain.
        >
        > Net result: The wheel will stop at some error position just below the starting position. The position error generates a commanded velocity, and the commanded velocity velocity generates a velocity error just large enough to cause the motor to bring the velocity to zero.
        >
        > If we add an I term to make it a PI loop, the I term will drive the position error to zero. Think of the I term as slowly increasing the position error gain over time. For a pure integrator, the gain will (eventually) approach infinity. You might use an "impure" integrator and limit its gain to 10-100 to give you good enough static error fewer windup problems.
        >
        > A comment on encoders. Shaft encoders can be good for position and not good for velocity. Velocity terms want to be fast. If you are generating velocity by subtracting counts between two time samples, you can quickly run out of counts if you sample quickly. You want a couple of hundred counts per sample to avoid quantizing noise. And you want to sample at ~50-100X your loop bandwidth for minimum problems. So a 20-24-bit encoder would be good. Maybe not cheap, though. The problem is good control at low speeds = low velocity. With 256 counts/revolution, you may on get a few counts at 1 RPM.
        >
        > Common tricks are:
        >
        > 1. Put the encoder on the motor shaft before the gear reducer. This gives you lots of counts/second. Of course you get into position error problems if you have backlash in the gears.
        >
        > 2. Do the brushless DC motor trick above and use the back-EMF from the motor + H-bridge for your velocity loop. But BLDC motors can be expensive.
        >
        > 3. Use two encoders: one on the high speed motor shaft for velocity, one on the output shaft for position.
        >
        > Hope this helps,
        >
        > Dave Wyland
        >
        [snip]
      • Peter Balch
        Dave I ve read the specs of BLDC motors but haven t actually held on in my hand - even less, tried to control it. My thoughts were ... Can you use the motor
        Message 3 of 30 , Feb 2, 2012
        View Source
        • 0 Attachment
          Dave

          I've read the specs of BLDC motors but haven't actually held on in my hand -
          even less, tried to control it.

          My thoughts were ...

          Can you use the motor itself as the encoder? Maybe there's a commercial
          controller that has output pins that tells you what it's doing. Or, if not,
          then just look at the wires going to the motor winding. I imagine that if
          you look at one winding, you can count steps (it nevr loses its "cogging",
          right?). If you look at the phase of two windings, you can count positive
          and negative steps.

          Secondly, what if you built your own controller? Can you just treat a BLDC
          motor as a stepper motor? Usually, you drive a stepper motor "blind" - you
          tell it to step and you assume that it will do so. A BLDC motor controller
          is cleverer than that - it uses feedback to know at what phase in the cycle
          to switch to the next step. So it would be a pretty specialised controller
          but very useful if you could build one.

          IIRC, many or most BLDC motors get their feedback from the back EMF of the
          windings as you describe. Would that feedback work when the motor was
          stopped or going slowly - do such motors work well at low speed? Low speed
          or often changing between forward and reverse is not a requirement for
          planes or even racing cars - but it's needed if you don't have a parking
          brake ;-). Maybe the answer is to drive the motor "blind" at low speed but
          switch to feedback-mode when the back EMF is saying something useful.

          Other BLDC motors get their feedback from a separate sensor - maybe
          hall-effect. Presumably they work better at low or zero revs.

          Peter
        • l m
          Hiya, Its been a while since I have posted on here, but I would like to chime in on this subject! I have been messing around with brushless motors for a little
          Message 4 of 30 , Feb 2, 2012
          View Source
          • 0 Attachment
            Hiya,

            Its been a while since I have posted on here, but I would like to chime in on this subject! I have been messing around with brushless motors for a little while now.
            My main plan for this was to put to use the cheap brushless outrunner motors that are available from the incredibly cheap model plane/car/helicopter market.
            At the moment, I have a prototype board that is operational - well was. I cooked it and am now just waiting on new pcbs to arrive for me to build up again!
            Anyway, before the great fire that spelt the end of my prototype, I had a brushless outrunner that I had purchased from hobbycity.com running as a permanent magnet
            synchronous motor. I have been using Freescale dsc's and had loosely followed a couple of the app notes available on their site. I am please to say that this was all
            working very well. I had velocity control running through the use of a 1024 count encoder attached to the rotor, and position control from a dodgy belt drive reduction to a potentiometer. Current control was achieved via measuring the current through 2 of the phases and then calculating the 3rd.
            I am afraid to say I don't have a web page or blog at the moment, so I cant give any pictures etc.
            However, I regularly check out this blokes blog:
            http://scolton.blogspot.com.au/
            He has done a lot of work with similar motors to mine (as in outrunners from hobby city) but has been putting them to use in electric scooters. He has a lot of good info on back EMF control and open/closed loop observers. It is my understanding that back EMF control is not so good for use in servo applications (what I want) as there are problems estimating where the rotor is at slow speeds or when it is stopped. Thus I have gone the way of the quadrature encoder for my experiments.
            And thats the end of my story.
            Laurence
          • Randy M. Dumse
            Dcwjobs2004 said: Monday, January 30, 2012 2:38 AM ... Always find your posts thoughtful and worth a very careful read. I ve learned quite a bit by reading
            Message 5 of 30 , Feb 3, 2012
            View Source
            • 0 Attachment
              Dcwjobs2004 said: Monday, January 30, 2012 2:38 AM
              > I hesitate to jump in here, but I have a
              > comment or two that might help.

              Always find your posts thoughtful and worth a very careful read.
              I've learned quite a bit by reading your posts.

              > I start with a pure velocity loop, like the
              > H-bridge driving a BLDC motor. (I am cheating:

              I edit my posts quite a bit before letting them go. I thought,
              at one point, I'd made the comment the example was for 2
              quadrant sign Magnitude on a slope. So 0 velocity would
              translate to 0 power applied to freewheeling motors, which would
              then easily slide, except perhaps for inefficiencies in the gear
              train providing a bit of resistance to the slide.

              > ... Stick the motor and wheel on a slope and
              > command a zero velocity from the H bridge.
              > (This is the same as shorting out the motor.)

              I guess you're saying a BLDC would always have an energized
              coil, even if sitting at a fixed position. Yes. This would be
              true also for LAP driving the coils.

              I don't get the idea the "same as shorting out", though. But I
              don't use BLDC motors. Instead I'd think (at least) one phase
              would be powered.

              Randy
            • Peter Balch
              ... Maybe not. I have yet to find any homebrew circuits for BLDC motors suitable to robot work but, it seems to me that a homebrew driver could either treat
              Message 6 of 30 , Feb 5, 2012
              View Source
              • 0 Attachment
                > I guess you're saying a BLDC would always have an energized
                > coil, even if sitting at a fixed position. Yes. This would be
                > true also for LAP driving the coils.

                Maybe not.

                I have yet to find any homebrew circuits for BLDC motors suitable to robot
                work but, it seems to me that a homebrew driver could either treat the motor
                as stepper motor (at low speed) or a normal "model aircraft" motor at high
                speed.

                Let's assume it's a motor with a hall-effect sensor (rather than using the
                back-emf sensing that Dave described). The hall-effect sensor acts like an
                optical encoder. If the robot stops on the level then the controller sees no
                movement in the motor and doesn't need to energize a coil.

                With a normal stepper-motor, the driver acts without any feedback and so
                must always supply enough current to hold the motor in the worst case. A
                BDLC can be more intelligent. If, in the short term, a BLDC motor driver
                always energises the coils according to the rotor's position but, in the
                long term (i.e. over a few rototions) tries to keep the encoder count about
                right then you get the best of both worlds.

                It seems like a pretty good use of a BLDC motor but I can't find any
                hobbyists doing it. Maybe all the hall-effect BLDC motors cost too much.
                This company's controller
                http://www.trinamic.com/index.php?option=com_content&view=article&id=238&Itemid=350
                does it with any motor that has a hall-effect sensor. The controller can
                turn the motor into a servo using either an external encoder (e.g. optical)
                or the motor's own hall sensors. Very expensive though.

                Peter
              • dcwjobs2004
                Hi Peter, Stepper motors are BLDC motors that are interesting by themselves for historical reasons. The original of the stepper motor was for position control.
                Message 7 of 30 , Feb 6, 2012
                View Source
                • 0 Attachment
                  Hi Peter,

                  Stepper motors are BLDC motors that are interesting by themselves for historical reasons. The original of the stepper motor was for position control. You apply a current to a coil, and the rotor magnet swings around to face the pole(s) corresponding to that current.

                  The interesting part is that the stepper motor forms a classic force-position loop! The winding current generates a magnetic force on the rotor, causing it to accelerate. Its velocity toward the target pole builds up as it moves toward the pole, even as the tangential pulling force decreases. By the time it gets to the pole, the rotor has velocity, but the accelerating force has gone to zero. So the rotor overshoots, and we get the same activity in the reverse direction, etc. The result is a damped oscillation

                  The unique thing about the stepper motor system is that the loop gain is slightly less than one. When you do a step, you will see a damped sine wave oscillation of rotor motion. If you have a big mass attached to the rotor and low friction loss, the damping factor can be very low (i.e., the "loop gain" => 0.99...9. This is considered a bug of stepper motors, to be solved by damping the action.

                  The damped oscillation comes from the force-position nature of the system, coupled with a (typically) low impedance voltage drive. The motor winding resistance determines both the current and the damping factor. Some ways of increasing the damping are:

                  1. Add friction to the system to absorb the energy. Ugly, but works.

                  2. Drive with a high impedance source: put a big resistor in series with a bigger voltage, or drive with an electronic pure current source.

                  3, Sense or guess when you are near the end point and add a series resistor to cut the current by increasing the resistance.

                  Does 3. sound familiar? It means we are closing a loop around the stepper!

                  a BLDC motor operates like a brushed DC motor, not a stepper. It uses electric commutation via a shaft encoder to always keep the magnetic force *ahead* of the position of the rotor. This also is what the commutator in a brushed DC motor does. So a BLDC motor is a pure DC motor where the applied voltage determines the motor velocity with no brush losses, only the linear resistances of the windings in series with their mosfet switches.

                  If you have this situation, where the BLDC motor is a perfect velocity loop, you can add a second position sensor for the application position and close the loop around the BLDC motor. The position loop is around the motor velocity loop, and both are stable.

                  If you are clever, you can make the BLDC commutation shaft encoder do double duty as the position encoder for your application loop.

                  Hope this is helpful,

                  Dave Wyland


                  --- In SeattleRobotics@yahoogroups.com, "Peter Balch" <peterbalch@...> wrote:
                  >
                  > > I guess you're saying a BLDC would always have an energized
                  > > coil, even if sitting at a fixed position. Yes. This would be
                  > > true also for LAP driving the coils.
                  >
                  > Maybe not.
                  >
                  > I have yet to find any homebrew circuits for BLDC motors suitable to robot
                  > work but, it seems to me that a homebrew driver could either treat the motor
                  > as stepper motor (at low speed) or a normal "model aircraft" motor at high
                  > speed.
                  >
                  > Let's assume it's a motor with a hall-effect sensor (rather than using the
                  > back-emf sensing that Dave described). The hall-effect sensor acts like an
                  > optical encoder. If the robot stops on the level then the controller sees no
                  > movement in the motor and doesn't need to energize a coil.
                  >
                  > With a normal stepper-motor, the driver acts without any feedback and so
                  > must always supply enough current to hold the motor in the worst case. A
                  > BDLC can be more intelligent. If, in the short term, a BLDC motor driver
                  > always energises the coils according to the rotor's position but, in the
                  > long term (i.e. over a few rototions) tries to keep the encoder count about
                  > right then you get the best of both worlds.
                  >
                  > It seems like a pretty good use of a BLDC motor but I can't find any
                  > hobbyists doing it. Maybe all the hall-effect BLDC motors cost too much.
                  > This company's controller
                  > http://www.trinamic.com/index.php?option=com_content&view=article&id=238&Itemid=350
                  > does it with any motor that has a hall-effect sensor. The controller can
                  > turn the motor into a servo using either an external encoder (e.g. optical)
                  > or the motor's own hall sensors. Very expensive though.
                  >
                  > Peter
                  >
                • Alan
                  Hi Dave, You might also mention/discuss microstepping as a solution to the resonance bands encountered in stepper motors. High voltage drives on low voltage
                  Message 8 of 30 , Feb 6, 2012
                  View Source
                  • 0 Attachment
                    Hi Dave,

                    You might also mention/discuss microstepping as a solution to the resonance
                    bands encountered in stepper motors.

                    High voltage drives on low voltage stepper motors also aids in the top speed
                    and acceleration available to the stepper.

                    BLDC motor systems in our new robots use PWM drives on the three phases, and
                    very high resolution encoders. The normal hall-effect sensors on the motors
                    are relegated to "safety" position feedback.

                    Alan KM6VV

                    > -----Original Message-----
                    > On Behalf Of dcwjobs2004
                    >
                    > Hi Peter,
                    >
                    > Stepper motors are BLDC motors that are interesting by themselves for
                    historical
                    > reasons. The original of the stepper motor was for position control. You
                    apply a
                    > current to a coil, and the rotor magnet swings around to face the pole(s)
                    > corresponding to that current.
                    >
                    > The interesting part is that the stepper motor forms a classic
                    force-position loop!
                    > The winding current generates a magnetic force on the rotor, causing it to
                    > accelerate. Its velocity toward the target pole builds up as it moves
                    toward the
                    > pole, even as the tangential pulling force decreases. By the time it gets
                    to the
                    > pole, the rotor has velocity, but the accelerating force has gone to zero.
                    So the
                    > rotor overshoots, and we get the same activity in the reverse direction,
                    etc. The
                    > result is a damped oscillation
                    >
                    > The unique thing about the stepper motor system is that the loop gain is
                    slightly
                    > less than one. When you do a step, you will see a damped sine wave
                    oscillation
                    > of rotor motion. If you have a big mass attached to the rotor and low
                    friction
                    > loss, the damping factor can be very low (i.e., the "loop gain" =>
                    0.99...9. This is
                    > considered a bug of stepper motors, to be solved by damping the action.
                    >
                    > The damped oscillation comes from the force-position nature of the system,
                    > coupled with a (typically) low impedance voltage drive. The motor winding
                    > resistance determines both the current and the damping factor. Some ways
                    of
                    > increasing the damping are:
                    >
                    > 1. Add friction to the system to absorb the energy. Ugly, but works.
                    >
                    > 2. Drive with a high impedance source: put a big resistor in series with a
                    bigger
                    > voltage, or drive with an electronic pure current source.
                    >
                    > 3, Sense or guess when you are near the end point and add a series
                    resistor to
                    > cut the current by increasing the resistance.
                    >
                    > Does 3. sound familiar? It means we are closing a loop around the stepper!
                    >
                    > a BLDC motor operates like a brushed DC motor, not a stepper. It uses
                    electric
                    > commutation via a shaft encoder to always keep the magnetic force *ahead*
                    of
                    > the position of the rotor. This also is what the commutator in a brushed
                    DC
                    > motor does. So a BLDC motor is a pure DC motor where the applied voltage
                    > determines the motor velocity with no brush losses, only the linear
                    resistances
                    > of the windings in series with their mosfet switches.
                    >
                    > If you have this situation, where the BLDC motor is a perfect velocity
                    loop, you
                    > can add a second position sensor for the application position and close
                    the loop
                    > around the BLDC motor. The position loop is around the motor velocity
                    loop,
                    > and both are stable.
                    >
                    > If you are clever, you can make the BLDC commutation shaft encoder do
                    double
                    > duty as the position encoder for your application loop.
                    >
                    > Hope this is helpful,
                    >
                    > Dave Wyland
                  • Peter Balch
                    Dave ... As does a stepper when it s turning continuously while generating torque. ... I ve seen that statement expressed before and it s seemed rather
                    Message 9 of 30 , Feb 6, 2012
                    View Source
                    • 0 Attachment
                      Dave

                      > a BLDC motor operates like a brushed DC motor, not a
                      > stepper. It uses electric commutation via a shaft encoder to
                      > always keep the magnetic force *ahead* of the position of
                      > the rotor.

                      As does a stepper when it's turning continuously while generating torque.

                      > So a BLDC motor is a pure DC motor where
                      > the applied voltage determines the motor velocity with no
                      > brush losses, only the linear resistances of the windings in
                      > series with their mosfet switches.

                      I've seen that statement expressed before and it's seemed rather mysterious.
                      To me, a "standard" motor (i.e whith a commutator) is driven at a particular
                      speed by giving it a particular voltage. But a BLDC motor is driven at a
                      particular speed by telling the controller to go that fast (e.g. via "servo"
                      pulses). The controller is like the controller for a stepper motor except
                      that _it_ decides when to step (from the rotor feedback) rather than being
                      told when to step (by an external computer).

                      So how does "the applied voltage determine the motor velocity"? I had
                      presumed that the controller compares how fast the motor is actually going
                      with how fast it's meant to go and adjusts the pulse width and/or the phase
                      angle of the "virtual commutator".

                      > If you are clever, you can make the BLDC commutation shaft
                      > encoder do double duty as the position encoder for your
                      > application loop.

                      Assuming that it has a shaft encoder. Cheap BLDC motors look like extremely
                      good value but unfortunately none seem to have encoders. Presumably you
                      connect them to a controller that measures back emf to get a rough idea of
                      where the rotor is. I don't see how that would work when the motor is
                      stopped. So (1) it's not so useful for a robot (other than by adding an
                      external encoder) and (2) how does a BLDC motor get started? It seems as
                      though BLDC motors are great if you want to go fast but not so great if you
                      don't.

                      The other disadvantage is that, with a stepper, you just fit a wheel on it
                      or fix it to your milling machine lead-screw or whatever; with a BLDC motor
                      you need a gearbox. And the gearbox will probably cost more than the motor.

                      Peter
                    • dcwjobs2004
                      Hi Peter, A rose by any other name ... The same motor structure can have different names. A motor with a permanent magnet rotor and stator coils can be
                      Message 10 of 30 , Feb 7, 2012
                      View Source
                      • 0 Attachment
                        Hi Peter,

                        "A rose by any other name ..."

                        The same motor structure can have different names. A motor with a permanent magnet rotor and stator coils can be called a stepper motor, a brushless DC motor or a synchronous AC motor, depending on how it is driven. The stepper motor we know.

                        The brushless DC motor was originally designed to be what it says: a brushless, inside-out version of a brushed DC motor. Hall effect shaft encoders were used with the drive switches to keep the magnetic pull force ahead of the rotor, like a dog chasing a rabbit. In this configuration, it works just like a brushed DC motor, without the non-linearity of brush loss. If you apply a voltage to it, it runs at a constant speed, just like the brushed DC motor.

                        An advantage of the BLDC motor is that this works down to low speeds, unlike a brushed DC motor. It is one reason why the BLDC motor works well in the new washing machines. The same motor is used for direct drive at both wash (slow) and spin (fast) speeds. The direct drive eliminates the transmission (gears or belts), saving money and improving reliability.

                        The third mode is to just drive the stator coils in a fixed rotary sequence at the desired speed. This is the synchronous AC motor mode. This works OK, but you will still get damped oscillations with load changes, etc. Old fashioned clock motors worked like this. The 60 Hz line is trimmed to be 60.000 Hz, so the clock motor will spin at 3600.00 RPM to accurately drive the clock.

                        BTW, there is no functional difference between a BLDC motor and a stepper motor, except that the stepper motor has more poles: ~200 setps per revolution rather than 3 steps/revolution. For the same motor size (rotor, stator), you should get about the same torque. With the BLDC, you can easily get more speed = more power out. If you want more torque, you need a gearbox in either case.

                        And stepper motors can go fast, if you drive them fast. One one project, a 200 step/revolution stepper was driven at 20K steps/second = 100 RPS = 6000 RPM!

                        If you want more steps per revolution (in stepper motor mode), you can use micro-stepping in either case. 256 micro-steps/step is not hard. This means using PWM to apply sine and cosine currents to the windings. In BLDC motors, this would be 3 phases, 120 degree spacing. In steppers, it would be 2 phases, 90 degree spacing.

                        Fun stuff,

                        Dave Wyland


                        --- In SeattleRobotics@yahoogroups.com, "Peter Balch" <peterbalch@...> wrote:
                        >
                        > Dave
                        >
                        > > a BLDC motor operates like a brushed DC motor, not a
                        > > stepper. It uses electric commutation via a shaft encoder to
                        > > always keep the magnetic force *ahead* of the position of
                        > > the rotor.
                        >
                        > As does a stepper when it's turning continuously while generating torque.
                        >
                        > > So a BLDC motor is a pure DC motor where
                        > > the applied voltage determines the motor velocity with no
                        > > brush losses, only the linear resistances of the windings in
                        > > series with their mosfet switches.
                        >
                        > I've seen that statement expressed before and it's seemed rather mysterious.
                        > To me, a "standard" motor (i.e whith a commutator) is driven at a particular
                        > speed by giving it a particular voltage. But a BLDC motor is driven at a
                        > particular speed by telling the controller to go that fast (e.g. via "servo"
                        > pulses). The controller is like the controller for a stepper motor except
                        > that _it_ decides when to step (from the rotor feedback) rather than being
                        > told when to step (by an external computer).
                        >
                        > So how does "the applied voltage determine the motor velocity"? I had
                        > presumed that the controller compares how fast the motor is actually going
                        > with how fast it's meant to go and adjusts the pulse width and/or the phase
                        > angle of the "virtual commutator".
                        >
                        > > If you are clever, you can make the BLDC commutation shaft
                        > > encoder do double duty as the position encoder for your
                        > > application loop.
                        >
                        > Assuming that it has a shaft encoder. Cheap BLDC motors look like extremely
                        > good value but unfortunately none seem to have encoders. Presumably you
                        > connect them to a controller that measures back emf to get a rough idea of
                        > where the rotor is. I don't see how that would work when the motor is
                        > stopped. So (1) it's not so useful for a robot (other than by adding an
                        > external encoder) and (2) how does a BLDC motor get started? It seems as
                        > though BLDC motors are great if you want to go fast but not so great if you
                        > don't.
                        >
                        > The other disadvantage is that, with a stepper, you just fit a wheel on it
                        > or fix it to your milling machine lead-screw or whatever; with a BLDC motor
                        > you need a gearbox. And the gearbox will probably cost more than the motor.
                        >
                        > Peter
                        >
                      • Michael
                        ... I am definitely not the expert here but I wanted to point out that there are hobby style BLDC motors with integrated hall-effect sensors for commutation by
                        Message 11 of 30 , Feb 7, 2012
                        View Source
                        • 0 Attachment
                          On Mon, Feb 6, 2012 at 6:07 PM, Peter Balch <peterbalch@...> wrote:
                           
                          Assuming that it has a shaft encoder. Cheap BLDC motors look like extremely
                          good value but unfortunately none seem to have encoders. Presumably you
                          connect them to a controller that measures back emf to get a rough idea of
                          where the rotor is. I don't see how that would work when the motor is
                          stopped. So (1) it's not so useful for a robot (other than by adding an
                          external encoder) and (2) how does a BLDC motor get started? It seems as
                          though BLDC motors are great if you want to go fast but not so great if you
                          don't.
                           
                          I am definitely not the expert here but I wanted to point out that there are hobby style BLDC motors with integrated hall-effect sensors for commutation by the ESC.  Maybe not "cheap" but available nonetheless. The google search term that works for me is "crawler sensored brushless".
                          Here is a good example in a conventional 380 can size (smaller than the 540) that even mentions "robotic mode":
                          This one is $100 for motor+ESC combo.
                          Just a quick FYI.

                          Regards,
                          Michael Sprague


                        • Peter Balch
                          From: Michael ... http://www.teamnovak.com/products/brushless/mongoose_crawler/index.html It s interesting that the advert says a sensor-based commutation
                          Message 12 of 30 , Feb 9, 2012
                          View Source
                          • 0 Attachment
                            From: Michael
                            > Here is a good example in a conventional 380 can size (smaller than the
                            > 540) that even mentions "robotic mode":
                            http://www.teamnovak.com/products/brushless/mongoose_crawler/index.html

                            It's interesting that the advert says "a sensor-based commutation design to
                            ensure no hesitation before acceleration". It sounds like a back-emf sensed
                            motor has trouble at low speed.

                            It also says "can be activated in all four throttle profiles". Does that
                            mean four-quadrant? And "adjustable hill/drag brakes are active in profiles
                            one and two, which use battery power to slow the vehicle to a wheel-locking
                            stop".

                            It does make it sound useful for robotics.

                            > This one is $100 for motor+ESC combo.

                            Even without the ESC, the cheapest I can see is over $50. Whereas, back-emf
                            sensed motors cost next to nothing:
                            http://www.giantcod.co.uk/brushless-motor-c-25.html?page=10&sort=2a&showAll=1&order=products_price%20ASC

                            I presume back-emf sensed motors have to be driven "blind" when they're
                            starting up.

                            $100 is OK if you're building a 2-motor buggy but not for a 12-DOF walker.
                            And the gearboxes ... ? Sigh.

                            Peter
                          Your message has been successfully submitted and would be delivered to recipients shortly.