Announcement

Collapse
No announcement yet.

Modern Robotics Motor Controllers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Modern Robotics Motor Controllers

    Modern Robotics Support has received a number of emails about the motor controller and maximum motor speeds when using the different motor controller run modes.

    As background, the motor controller has three modes,
    1. Run with power control (RUN_WITHOUT_ENCODER)
    The speed of the motor is determined by the power setting, 0% - 100%

    2. Run at constant speed (RUN_USING_ENCODER) ,
    The speed is selected by setting the power and the controller with maintain a constant speed based on that setting. This is particularly useful when a robot uses two drive motors, one on each side and you want the robot to run as straight as possible, set both motors to run at constant speed. If one wheel runs over an obstacle or an uneven surface that may add additional load to that motor causing the robot to veer from driving straight, the motor controller will increase power to that wheel so its encoder can “to catch” up to maintain a constant speed.

    3. Run to position (RUN_TO_POSITION)
    The motor will run until it reaches the desired encoder position, and then hold that encoder position.

    To ensure these modes run correctly, the motor controller will run the motor at approximately 80% of the maximum speed in RUN_USING_ENCODER mode, and at approximately 70% of maximum speed in RUN_TO_POSITION mode. This may vary depending on the motor used.

    The motor controller runs motors at these speed settings to give “head room” to allow the controller to increase motor speed to compensate for high loads that can slow the motor and prevent it from maintaining the target speed setting. In both these modes the controller will apply more power in an attempt to maintain the target speed and may increase the speed above the target for a short time to maintain an average constant speed.

    For more information and a tutorial on using the motor controller and motor encoders go to http://modernroboticsedu.com/course/...p?categoryid=5

    If you have questions about Motor Controllers or any other MRI controllers or sensors contact us at [email protected] and if the discussion would be of interest to others we will post information on the forum.

  • #2
    For case 2, Run_Using_Encoder, where, and how, do the kids set the counts-per-rotation value for motors with different encoder count rates? Is there a bit of example code somebody could post here? thanks!

    Z

    Comment


    • #3
      Originally posted by zain View Post
      For case 2, Run_Using_Encoder, where, and how, do the kids set the counts-per-rotation value for motors with different encoder count rates? Is there a bit of example code somebody could post here? thanks!

      Z
      Once you have changed the run mode to Run_Using_Encoder you just use the setPower() command. A value of 1 is about 80% as stated above. AFAIK there is no way to set a specific encoder steps per time.

      Comment


      • #4
        But then how could #2 work as described? If RUN_USING_ENCODERS uses encoder feedback in order to maintain constant velocity, it would have to be doing some math and closing the loop between the voltage the motor controller applies to the motor and the rate/frequency of encoder counts being read back. Said another way, 80% of WHAT? Max speed of the various motors the kids are allowed to use is actually different numbers of counts per second at a given voltage and corresponding velocity.

        Comment


        • #5
          The motor controller has PID control built in. HiTechnics (and MR) tuned the PID loop for for Tetrix motors. When you are in "run using encoders" mode you are not sending a power, but a speed number. The specs do not tell us how the encoder counts per second correlates with the number we send in setpower. We are told it is 80%. What I haven't seen is whether it is 80% of the max unloaded speed of 150 rpm, or some selected load rpm. Maybe I can get my team to run a test.

          The Neverest are close enough that the tuning in general works, but it has been reported that the Neverest can have problems if you set the power (speed) setting too high. Since the Neverest are 1120 instead of the 1440 of Tetrix, the Neverest might not achieve the expected encoder/sec setpoint and behave poorly. I believe I saw a post stating not to exceed a setpower of .8 in this runmode with Neverest. I forget if it was integral windup or something else.

          I think I saw a post that we will be able to select which motor is connected to the motor controller, which will have appropriate PID constants, and rpm settings for the motor selected.

          Hitechnic description of their motor controller. I haven't seen anyone report any differences between Hitechnic and MR yet.
          http://www.hitechnic.com/blog/wp-con...cification.pdf

          Comment


          • #6
            So the 1120 obviously was for the 40. My kids successfully used the 60s with run to position last year, but it was for an arm that they didn't want to move too fast.

            More research and found in this link in the "working with encoders" section which has some helpful links -
            http://www.andymark.com/NeveRest-60-...-p/am-3103.htm

            Which led me to check the javadocs dcmotor section again to find this -
            void setMaxSpeed(int encoderTicksPerSecond)
            When the motor is running in one of the PID modes the value set using the setPower() method is indicative of a desired motor velocity rather than a raw power level. In those modes, the setMaxSpeed() method provides the interpretation of the speed to which a value of 1.0 passed to setPower() should correspond.
            Parameters:
            encoderTicksPerSecond - the maximum targetable speed for this motor when the motor is in one of the PID modes, in units of encoder ticks per second.

            Comment


            • #7
              Got it. Thanks.

              Tricky thing with Andymark v Tetrix is the encoder is on the other side. So it doesn't "see" the gearbox. So if, not so hypothetically, kids were to put a 4:1 gearhead on an andymark motor and tried to use RUN_USING_ENCODERS to get the speed of two counter rotating motors driving 4" wheels to match RPM, picking ticks-per-second to keep the PID stable, for high speed, might require some thought. Might even be handy to mess with the PID coefficients, but I think that'll be beyond them. Probably just need to set for 1120-ish since that should imply close to full speed (from the POV of the shaft encoder) on the AM the way 1140 implies it on the Tetrix. Hmm... gotta think about that...

              Just trying to see some problems ahead of where the kids are now as they build.

              - Z

              Comment


              • #8
                I can’t help jumping into this discussion as I’ve been trying to figure out the HiTechnic (and now Modern Robotics) Motor-controller for many years now.

                Caveat: My opinions on what and why the controller does what it does ARE NOT in line with the official stated operation of the devices.

                My understanding is based on the originally published spec for the Hitechnic controller, and my extensive tests used to understand what I’ve seen our robots do.

                Also note that I have not done any tests with the new 2.0 firmware on the MR Motor controllers, so please don’t extrapolate anything I say here to those devices. Despite assertions to the contrary, we know the interface has changed, but we don’t know to what extent.

                Having said that, here’s what I know.

                In RUN_WITHOUT_ENCODERS mode, the controller is simply applying a ratio of full voltage to the motor, so 0-1 spans 0 to 100% output voltage. And you will get what the motor gives you using this range. As with all motors it depends on load, and battery voltage.

                Once we move over to RUN_USING_ENCODERS or RUN_TO_POSITION, the assumed “Top Speed” is based on the original TETRIX motors, and is stated to be 1000 degrees per second, or 4000 encoder counts per second. This seems reasonable at about 160 RPM.

                So a request for 50% power (or more accurately 50% speed) will result in a measured speed of 2000 counts per second (CPS). The controller will attempt to regulate the power to obtain this speed. It will max out the voltage if that’s what’s required to reach 2000 CPS under a heavy load.

                My own tests have shown that RUN_USING_ENCODERS are RUN_TO_POSITION are far from consistent in how they apply this “Top Speed”.

                In RUN_USING_ENCODERS, the top speed seems to be clipped at about 3550 CPS (88%), and RUN_TO_POSITION is clipped at about 2560 CPS (65%).

                Note: The 0-1 range is not scaled to smoothly cover this range.
                The requested CPM starts out scaled to the full 4000 cmp (eg: a power request of 0.5 gets you 2000 cps), but at some point the controller just says “nope, I won’t let you request a higher CPM.”

                So, this means that your RUN_TO_POSITION speed is limited to MUCH less than you can obtain with RUN_USING_ENCODERS. This can be a burden for Autonomous.
                I personally don’t see why there should be such a large difference between the two, since both are regulating the power to obtain a constant speed… but that’s how it is.
                I maintain it's a bug... but if it's not a bug, it's a really annoying "feature".

                Notice that since different motors have different top speeds and different encoder count per revolution, the net effect is that none will perfectly match the “standard” characteristics of the controller.

                Note that a NeveRest motor only puts out about 3000 CPM at full voltage, so it can only achieve 75% of “Top Speed”. So the 65% RUN_TO_POSITION speed limit isn’t quite so apparent on these motors.

                On the other hand, the new 12V MATRIX motors can reach higher CPS values at full voltage, so they are handicapped when it comes to RUN_USING_ENCODERS are RUN_TO_POSITION.

                Note: This data is illustrated on the linked spreadsheet. I will help interpret this data if required, but I’m not defending it. Data is Data

                http://gearsinc.org/images/motordata.xlsx

                Comment


                • #9
                  Thanks Phil for all of the data, as usual!

                  To confirm, these were with HiTechnic motor controllers and Neverest40 motors, yes? Did you use a battery for the source or a power supply? I see that the peak power is always about 12.3V. Is this regulated down on the motor controllers if the source voltage is higher, or were you just using a 12.3V supply or battery? If a 13.5V battery is used, will the peak voltage be 13.5V or still 12.3V?

                  If/ when you have some spare time (I know, haha, stop laughing ), it would be great to run some similar tests with the 2.0 firmware for the Modern Robotics controllers. The newest version of the MRI Core Device Discovery app let's you set the type of motor on the controller itself (though the documentation hasn't been updated to reflect this). I think the options are something like Tetrix, AndyMark, Matrix, and Custom (!). It would be interesting to see how the different motors actually operate in these different mode (including "wrong" modes like operating with Tetrix motor controller settings but using an AndyMark motor), if you could find custom settings that allowed a RunWithEncoders mode that came closer to the full speed of the motors, etc.

                  It would also be interesting to see how the setMaxSpeed() method in the DcMotor class operates, if it overrides these stored motor controller settings, etc.

                  Thanks again!

                  Comment


                  • #10
                    Maybe Modern Robotics could just tell us how the new firmware works... MR?

                    Originally posted by Cheer4FTC View Post
                    Thanks Phil for all of the data, as usual! If/ when you have some spare time
                    Originally posted by Modern Robotics Support View Post
                    Modern Robotics Support has received a number of emails about the motor controller and maximum motor speeds when using the different motor controller run modes.

                    Comment


                    • #11
                      Phil that helps a ton. Thanks. I also think I can see how their closed loops have to work. If you think about it, MR has a tricky problem with the controller since it has to remain stable under any load. So it can't really be that tightly tuned a simple PID, if it even is running an "I" all the time. Which it probably isn't since there are all kinds of conditions where things are stalled or at a max RPM. But before I think about what the XLS tells me can I ask a few questions about how the data was taken?

                      1. Were all the motors/gearheads running with no load on them?
                      2. For the AM motor, if it had a gearhead, was it one with sorta the same ratio (and thus friction/damping/etc) as the Tetrix? Say an AM 40 or 60, not a 20 or none at all? (Looks like it was an AM 40:1, am I right)
                      3. Voltage was on the motor leads I presume, and you didn't see any major differences in the "ripple" from the PWM of the motor controller amplifier between the different motors, right? (Were you looking with an oscilloscope or with a DC multi-meter?)
                      4. Was this test done with the controllers (albeit last year's un-updated ones) in all their default settings? You didn't try to make corrections for the CPS differences between motor types, right? (Presumably we can do this now with the new ones, if we can figure out how...)

                      FWIW if the answers to the above are:
                      1. All same no load
                      2. Stock tetrix and AM-40:1
                      3. There was no ripple or other odd stuff the L-R constants of the motors is more than enough to low-pass filter the class D amplifiers' outputs
                      4. All default settings...

                      Then...

                      I think the data here is totally consistent with a motor controller meant to be able to handle everything from a stalled motor to kids using a motor as a robot arm elbow with a bunch of moment-load on it, without needing a lot of extra (even any) servo coefficient tuning. And if I worked for MR, I would possible end up at the same place in terms of design and results. And at first glance (again presuming 1-4 answers above) then the top speed difference between AM and Tetrix in RUN_USING is consistent with the difference encoder counts ratios on the motors. And the AM motor "spoofs" the servo into running to max at roughly 1120/1440 or 78% of where the controller maxes out a tetrix. RUN_TO seems similar. But as you point out, they baked in more headroom for that case vs the Run_USING case.

                      You could call that a bug. And if you imagine both modes being used for driving a robot across the floor, then one would reasonably think that they might have similar "headroom" needs to handle instability and over-runs and the like. But... position servos are going to have one more "intrinsic" integrator in them if you do the math with respect to motor voltage. And that bit of esoteric control theory aside, RUN_TO_POSITION may have been designed with more margin in a number of ways so that kids could use the DC motors to drive cantilevered masses like on shoulder and elbow joints. Which certainly requires some margin for needing to have "gone to far and stably come on back" without oscillations. Whereas velocity servos like RUN_USING wouldn't need that. So MR may have simply made different trade offs for each.

                      But like you I am guessing. But my guesses are vastly improved by your data. To this point I've just been watching the kids robot do things... and FWIW, taking their last year robot, and swapping in the updated MR controllers and using RUN_USING seems consistent with both your data and my interpretation. We have not, as yet, played with RUN_TO as much.

                      Thanks again!



                      - Z

                      Comment


                      • #12
                        Originally posted by zain View Post
                        Phil that helps a ton. Thanks. I also think I can see how their closed loops have to work. If you think about it, MR has a tricky problem with the controller since it has to remain stable under any load. So it can't really be that tightly tuned a simple PID, if it even is running an "I" all the time. Which it probably isn't since there are all kinds of conditions where things are stalled or at a max RPM. But before I think about what the XLS tells me can I ask a few questions about how the data was taken?

                        1. Were all the motors/gearheads running with no load on them?
                        2. For the AM motor, if it had a gearhead, was it one with sorta the same ratio (and thus friction/damping/etc) as the Tetrix? Say an AM 40 or 60, not a 20 or none at all? (Looks like it was an AM 40:1, am I right)
                        3. Voltage was on the motor leads I presume, and you didn't see any major differences in the "ripple" from the PWM of the motor controller amplifier between the different motors, right? (Were you looking with an oscilloscope or with a DC multi-meter?)
                        4. Was this test done with the controllers (albeit last year's un-updated ones) in all their default settings? You didn't try to make corrections for the CPS differences between motor types, right? (Presumably we can do this now with the new ones, if we can figure out how...)

                        FWIW if the answers to the above are:
                        1. All same no load
                        2. Stock tetrix and AM-40:1
                        3. There was no ripple or other odd stuff the L-R constants of the motors is more than enough to low-pass filter the class D amplifiers' outputs
                        4. All default settings...


                        - Z
                        All the motors were running stock with gearhead and no load.
                        Since the Andymarks monitor the motor shaft speed rather than output shaft speed, the gear reduction is moot.
                        They were running from a 12V battery with the voltage being measured with a DVM on the motor terminals. PWM frequency is high enough not to be visible.
                        Under no load, open loop, the motors showed odd voltages at low power levels. Somewhat confusing. Voltages looked better with a resistive load.

                        Since they had to "guess" at how much headroom was required, I wouuld have preferred them to just let us determine that based on the motor, load and speed demands.
                        Let us request 100% with the understanding that requesting too high will have consequences (integrator run up etc).

                        Phil

                        Comment


                        • #13
                          Thanks again Phil.

                          Minor point: I don't think the gearbox being on for the the AM is actually "moot." While I obviously agree it won't effect encoder count rates in any sort of direct ratio way, the gearboxes actually represent a fair amount of friction/damping load on the motor itself, and the coefficients for whatever kinds of control laws MR is using probably took that into account to some extent. Thus by having similar gearboxes on both your tetrix and AM motors in this test you removed that difference and its potential effect on the result. (FWIW your data also shows the Tetrix gearbox having reasonably more friction, especially startup "sticktion" than the AM one - which is why I asked if there was a gearbox on the AM one)

                          This was relevant to me mostly because my kids, and probably lots of others, are likely to try AM motors with *much* lower ratios (and thus way less friction/damping) to toss balls. And those teams who select two wheel baseball pitching machine type throwers are likely to notice that most DC motors at these price points are not so well tuned/assembled as to spin at exactly the same speed clockwise vs CCW. My kids already have some iPhone high speed video of theirs, and are tracing ball paths and whatnot. And have noticed that simply wiring two motors in paralell with opposite signs and the same controller isn't making them spin at the same rate in RUN_WITHOUT. I figure it's just a matter of time before one of them suggests running with encoders on separate motor controllers to match their velocities. At which point this whole business of just how many counts per second the controller is expecting and how much headroom vs top speed and all that will come up.

                          And presuming this all works like I suspect your data will be hugely helpful in their learning.

                          Now, unfortunately, while I'm savvy on old fashioned control theory, this OOP Java stuff seems to be of-the-devil to me and I need to figure out how to help them change what needs changing should they want to make any of these kinds of changes; CPS rates, servo coefficients, etc etc...

                          Because the question is sure to come up: coach, how do we decide what to set the counts-per number to on the AM motors with 4:1 ratios if we want full speed but *ALSO* for the motor controller to have the headroom to be able to match the motors to one another?

                          thanks again!

                          - Z

                          Comment


                          • #14
                            Could someone provide some sample code as to how Run_Using_Encoders would work in TeleOp with 4 drive motors (1 for each wheel).

                            Comment


                            • #15
                              Originally posted by FTC5501 View Post
                              Could someone provide some sample code as to how Run_Using_Encoders would work in TeleOp with 4 drive motors (1 for each wheel).
                              After the hardwaremap.dcMotor.get lines in your program put in
                              myMotorNameInMyProgram.setMode(DcMotor.RunMode.RUN _USING_ENCODER);
                              for each motor. Now when you use setPower() you're sending the speed you want the motor to run at rather than a power setting. You still use the same -1 to 1 range.

                              Comment

                              Working...
                              X