Announcement

Collapse
No announcement yet.

Initial Motor Controller test results are odd.

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

  • Initial Motor Controller test results are odd.

    Hi

    I've just started doing my typical motor controller tests. Each year I like to determine if the motor control logic has changed (due to software and firmware updates) and this year more than most others I expect/hope/fear that there will be many changes

    My first look at the motor controllers was to run a single Neverest motor up though the speed range, in 10% power steps.
    My program just runs the motor for five seconds at each power level.
    I will eventually measure the speed, but for now I was just getting a feel.

    I first ran the sequence using the "RUN_WITHOUT_ENCODERS" mode flag to see what 0-1 looked like in raw speed.

    Then I ran with "RUN_USING_ENCODERS" to see the closed loop performance.
    Since the Neverest encoders put out less pulses per revolution than the TETRIX ones, in this mode, I expected to see the control voltage max out at less than the 1.0 requested power level (about 78%).

    In "RUN_USING_ENCODERS" mode, I got almost exactly what I expected.

    BUT in "RUN_WITHOUT_ENCODERS" the motor response was not at all what I expected.
    Without using encoders, the speed seemed to jump up quickly and then max out very early on. Initially I thought it was just exhibiting a no-load speed condition, but even loaded, it acted the same.
    I resorted to hooking up a DVM to see what voltage was actually going to the motor at each power setting. Results below:

    Note: The battery voltage was being reported at 13.5V.

    RUN_WITHOUT_ENCODER
    Pwr Voltage
    0.00 0 V
    0.10 6.56 V << BIG JUMP
    0.20 9.85 V << Another Big Jump
    0.30 10.97 V << Small jump
    0.40 11.47 V << Tiny Jump
    0.50 11.69 V << Miniscule jump
    0.60 11.94 V
    0.70 12.06 V
    0.80 12.16 V
    0.90 12.22 V
    1.00 12.28 V

    RUN_USING_ENCODER
    Pwr Voltage
    0.00 0.00 V
    0.10 1.80 V
    0.20 3.46 V
    0.30 5.13 V
    0.40 6.85 V
    0.50 8.39 V
    0.60 10.01 V
    0.70 11.69 V
    0.80 12.31 V << Limiting at 78% as expected
    0.90 12.31 V
    1.00 12.31 V

    You can see that WITH the encoder, the voltage steps up nicely with each power increment (which is actually a speed request), but with NO encoder being used, the voltage starts at 6.5V when 10% power is requested, gets to almost 10V by 20% and then hardly changes at all between 30% and 100%.

    Note: I'm not disconnecting the encoder, I'm just telling the code not to use it

    This doesn't seem like a desired voltage curve for this (or any other) motor in open loop mode.
    Have I messed up this test, or is this what the encoder is meant to do.

    I've posted the applicable section of the code below for completeness.

    public class SpeedTest extends OpMode {

    DcMotor mLeftDrive;

    // Members for tracking state information
    private ElapsedTime mStateTime = new ElapsedTime();
    private double mWaitTime;
    private double mSpeed;

    /**
    * Constructor
    */
    public SpeedTest() {
    }

    /*
    * Code to run when the op mode is first enabled goes here
    * @see com.qualcomm.robotcore.eventloop.opmode.OpMode#sta rt()
    */
    @Override
    public void start() {
    mWaitTime = 0;
    mSpeed = 0;
    mLeftDrive = hardwareMap.dcMotor.get("Left Wheel");
    // mLeftDrive.setChannelMode(DcMotorController.RunMod e.RUN_WITHOUT_ENCODERS);
    mLeftDrive.setChannelMode(DcMotorController.RunMod e.RUN_USING_ENCODERS);
    }

    /*
    * This method will be called repeatedly in a loop
    * @see com.qualcomm.robotcore.eventloop.opmode.OpMode#loo p()
    */
    @Override
    public void loop() {
    if (mStateTime.time() > mWaitTime){
    mLeftDrive.setPower(mSpeed);
    telemetry.addData("Power", "Power: " + String.format("%.2f", mSpeed));
    mSpeed += 0.10;
    mWaitTime += 5;

    if (mSpeed > 1.0)
    mSpeed = 0;
    }
    }


    /*
    * Code to run when the op mode is first disabled goes here
    * @see com.qualcomm.robotcore.eventloop.opmode.OpMode#sto p()
    */
    @Override
    public void stop() {
    }

    }

  • #2
    It took me I long time to figure out that the motor speeds were not linear in their output, as I originally expected the motor output to be. I hope the motor speeds form a gentler curve in the future to have a finer control with motor speeds and power. Do you post your documentation regarding information like this anywhere else?

    Comment


    • #3
      Originally posted by dmssargent View Post
      It took me I long time to figure out that the motor speeds were not linear in their output, as I originally expected the motor output to be. I hope the motor speeds form a gentler curve in the future to have a finer control with motor speeds and power. Do you post your documentation regarding information like this anywhere else?
      Hi.

      I often create white papers to discuss testing I've performed, and I've posted on Chief Delphi.
      My user name is Philbot. To see my papers, go here http://www.chiefdelphi.com/media/search/results and search for "Papers" uploaded by Philbot

      I usually document my projects on the National Instruments site (NI.com) because much of it related to LabVIEW.
      Also post as Philbot. See my papers here: https://decibel.ni.com/content/peopl...view=documents

      I'm not sure where the best place to post is now..... Most of these FIRST forums get archived or deleted each year.
      Official docs are saved but user generated data doesn't have much of a lifetime.

      Chief Delphi is probably still a good place.

      Phil.

      Comment


      • #4
        Okay, Chief Delphi and National Instruments are were to find that information at, I forgot about Chief Delphi. (I am still new to FIRST robotics, it is my rookie year in our team, but I am not new competitive electronics and programming.) If you want I am more than willing to mirror your information of our teams website.

        Comment


        • #5
          Originally posted by dmssargent View Post
          Okay, Chief Delphi and National Instruments are were to find that information at, I forgot about Chief Delphi. (I am still new to FIRST robotics, it is my rookie year in our team, but I am not new competitive electronics and programming.) If you want I am more than willing to mirror your information of our teams website.
          Hi

          Since I started with FIRST and FRC, CD (Chief Delphi) really was THE place to go for FIRST related technical information.

          When FTC began, there wasn't much activity on CD, so NI made more sense.

          Now, FTC activity is growing on CD, so it makes sense for me to go back there.

          CD is really THE ultimate team website. Most others tend to fall into disrepair as teams evolve and change members.
          There are exceptions of course, but they are hard to find.

          I think it's a bit soon to mirror this motor information. I'm posting it here to draw attention to a possible issue.
          I'm expecting to find several other anomalies that I'll collect together in a paper and forward to those concerned (and possibly able to fix it).
          I have hope, but I'm not optimistic. My 2011 paper about the "Anomalous RunToPosition speeds" fell on deaf ears at Hitechnic when I sent it to them. Consequently we've lived with this flawed operation for 4 years.

          It will be interesting to see if the new controller has the same deficiency.

          Phil.

          Comment


          • #6
            I agree with your statement that team websites quite often need repair and to be updated, so your request to wait is an excellent thing to ask for now. If our school admins still approve, our team is going to host crash course in Computer Science and CAD, though our head mentor thinks that getting people proficient in Computer Science is not going to take awhile. Though, most of them are going to have a bad taste in Computer Science, due to our intro course being of Alice. I think JavaScript or Python would be much better, but I am getting off-topic.

            I don't know if they are going to fix issues with their control systems, or if they don't remember certain bugs, or if they are going to redesign the entire subsystem, without heavily referencing their old control systems, or if they have been working on this for a long time. I hope they fix any issues that have been reported and can be reasonably fixed. I still want them to implement multiple channels of updating software and/or associated "official" patches. I can't wait for them to update their FTC preview SDK (I still think that repo is alpha code).

            Comment


            • #7
              Originally posted by Philbot View Post
              ...
              RUN_WITHOUT_ENCODER
              Pwr Voltage
              0.00 0 V
              0.10 6.56 V << BIG JUMP
              0.20 9.85 V << Another Big Jump
              0.30 10.97 V << Small jump
              0.40 11.47 V << Tiny Jump
              0.50 11.69 V << Miniscule jump
              0.60 11.94 V
              0.70 12.06 V
              0.80 12.16 V
              0.90 12.22 V
              1.00 12.28 V..
              .


              Hi Phil,

              I got the same results using your code as well as using the game controller. Have you tried the run_to_position control? I don't have an encoder motor at the moment. We could never get position control to work with Matrix system last year.

              Comment


              • #8
                Originally posted by CraigRochester View Post
                Hi Phil,

                I got the same results using your code as well as using the game controller. Have you tried the run_to_position control? [/INDENT]
                Yes, I've just been able to a full test of the three control modes: Open Loop (Without Encoders), Closed Loop (Using Encoders), Run to position (Also using encoders).

                I now know why Modern Robotics didn't respond to me earlier query about the Bug that was in the old Hitechnic controller. It's in the new one as well.

                Here is my report that I've added to my papers on ChiefDelphi.

                http://www.chiefdelphi.com/media/papers/3157

                Phil.

                Comment


                • #9
                  Thanks Phil for posting your work- good stuff! I should be getting the new 12V Matrix motors soon and will perform a similar test.

                  Comment


                  • #10
                    Originally posted by CraigRochester View Post
                    Thanks Phil for posting your work- good stuff! I should be getting the new 12V Matrix motors soon and will perform a similar test.
                    Has anyone seen a spec sheet for the new 12V Matrix motor?

                    As for the other motors, there is a great post on CD with prices and performance data

                    http://www.chiefdelphi.com/forums/sh...d.php?t=137724

                    Notice all the new NeveRest gear ratios that are now legal as per the new Manual Part 1. Even a motor without the gearbox (we can finally do fans

                    Repeat Question.

                    Does anyone have the ability to do a hardness test on the shafts of these motors (AndyMark vs TETRIX)?
                    I'm convinced that the AndyMark motors have a much softer shaft metal (based on set screw tearing and deformations I'm seeing)

                    If it is softer, the higher gear ratio motors will be great for slower movements, but may not be suitable for the resulting higher torque.

                    Phil.

                    Comment


                    • #11
                      Originally posted by Philbot View Post
                      Has anyone seen a spec sheet for the new 12V Matrix motor?

                      As for the other motors, there is a great post on CD with prices and performance data

                      http://www.chiefdelphi.com/forums/sh...d.php?t=137724

                      Notice all the new NeveRest gear ratios that are now legal as per the new Manual Part 1. Even a motor without the gearbox (we can finally do fans

                      Phil.
                      If anyone(or myself) finds information on those motors, as well as the vex one, I will update the list in the link that Philbot posted. (Yes, I am MattRain)

                      YAY FANS!
                      2015 FTC World Champion - Valley X Robotics 2844 - Founding Memeber

                      Comment


                      • #12
                        Originally posted by Philbot View Post
                        Hi

                        I've just started doing my typical motor controller tests. Each year I like to determine if the motor control logic has changed (due to software and firmware updates) and this year more than most others I expect/hope/fear that there will be many changes

                        ….

                        You can see that WITH the encoder, the voltage steps up nicely with each power increment (which is actually a speed request), but with NO encoder being used, the voltage starts at 6.5V when 10% power is requested, gets to almost 10V by 20% and then hardly changes at all between 30% and 100%.

                        Note: I'm not disconnecting the encoder, I'm just telling the code not to use it

                        This doesn't seem like a desired voltage curve for this (or any other) motor in open loop mode.
                        Have I messed up this test, or is this what the encoder is meant to do.

                        .
                        Modern Robotics Motor Controller

                        It appears there is a basic misunderstanding of how the Modern Robotics Motor controller, and the HiTechnic Motor Controller for Tetrix, for that matter, actually work.

                        Firstly, the Modern Robotics and HiTechnic Motor controllers do not control motors by adjusting the voltage. This is a common misconception and it is not how the motor controller works. They control motor power using a PWM signal and, rather than adjust the voltage, the controller sets the amount of time power is applied to the motor. Measuring the voltage output from the motor controller with a meter gives little or no meaningful information.

                        The figure below shows a basic schematic of the motor controller setup with a motor / encoder.

                        Control Loop.jpg

                        When a power value is set by the user, the controller applied 12v (or the battery voltage) to the motor for a prescribed period of time as a PWM signal. A PWM, or Pulse Width Modulation signal turns the power on and off for specified time periods. If a power of, for example, 50% is set, the input voltage is applied to the motor for a period, and then switched off for an equal period. If a power setting of 60% is selected, the motor is powered for 60% of the time and then switched off for 40% of the time. The PWM signal operates at 200Hz so when running at 50% power, 12v is on for 2.5ms and off for 2.5ms.

                        5.jpg


                        This will result in the motor running at 50% power*.

                        Modes of Operation
                        The Modern Robotics Motor controller operates in three modes,
                        Run with power control only
                        Run with constant speed
                        Run to position

                        Run with Power Control
                        In this mode the user requests a power level to run the motor at, from 0 - 100%. The controller sets the PWM signal to apply power for the specified period to keep the power to the motor at a constant level. Note that to accurately measure the performance of a motor in this mode, the motor must be under load. If the motor is not under load it will reach maximum RPM at around 30% power because, without load, nothing is dissipating the power being input to the motor. Any further increase in power will have little effect on a motor with no load. This is shown clearly in the graphs in a previous posting. With a suitable load, the power increase will graph at close to a straight line.*

                        Run with Constant Speed
                        In this mode the speed of the motor is monitored by the control loop which is receiving encoder input to monitor the speed of the motor. This function is particularly useful for driving a robot in a straight line in autonomous mode. If two motors are run in this mode and one encounters an obstacle or other impediment which slows it down, the control loop will apply additional power to this motor to "catch up" to its target.

                        In this mode the power tops out at about 80% so as to leave some "headroom" to allow the motor to catch up as necessary. If it was run closer to 100% it may never be able to catch up to its target. Again, this feature is often misunderstood and thought to be a bug in the firmware but it is a carefully designed feature.

                        Run to Position
                        This mode allows a target position to be set and then the controller will run the motor until it reaches the target position, at which point it will hold the motor at that position. If a load attempts to move the motor from the target position, the controller will apply power, +ve or -ve, to hold the motor at the target position. Note that the motor will initially run at the speed selected, but as it approaches the target position it will slow down to enable it to arrive at the target position without overshooting.

                        To use the Modern Robotics Motor Controller successfully, a clear understanding of its function and features is important.


                        *Testing Motor Controller performance
                        To test the performance of a motor controller, a suitable test rig must be set up with an appropriate motor load. Such a load can be a second motor coupled to the motor under test. The second motor should have a 10 ohm resistor connected across its terminals. With this test rig motor performance can be more accurately assessed. Also note that with such a rig, the 10 ohm resistor will get hot.

                        Comment


                        • #13
                          Excellent information Steve Barker - Thanks!

                          Comment


                          • #14
                            I also thank Steven for his response to the concerns I raised.

                            I’m glad to hear that the open loop response is expected, because I did think something else must have been going on here.
                            I’m quite familiar with PWM control, but my own experience with other speed controllers was that the output voltage (average) was usually linear with requested power.
                            It’s good to hear that the speed will be more linear with a load. (I did make a point of stressing that this was a no-load result)

                            I also understand the concept of headroom, and I’ve never intimated that the top speed of the “run with constant speed” mode had been clipped.
                            Having that extra 20% power available to maintain the top most speed under varying load is an excellent practice.

                            My ongoing problem/frustration with the way the controller works (and the cause of my BUG reference) is that fact that during a “Run to position” action, when the controller is trying to reach a certain target encoder value, it NEVER moves faster than 65% of the max “Run constant speed” speed.

                            That is:

                            If I issue a 100% “run at constant speed” command I will a stable motor speed of 4000 counts per second out of my encoder (which allows for some headroom under the open loop speed of 4100).

                            But

                            If I issue a 100% “run to position” command for 1,000,000 counts, the max speed of the motor will top out at 2560 counts per second from the encoder. This is only 65% of the available closed loop top speed.

                            To me this is a clear problem.
                            It's not so bad for an arm, but it's the kiss of death for an autonomous routing trying to navigate the field in a short amount of time.

                            Phil.

                            Comment


                            • #15
                              Hi, Steven,

                              We are trying to do some test to confirm the Motor outputs. Can you show us how to setup the test with load? With hitechnic controller, we had issues that two ports are not identical in output. Port 2 is always smaller than port 1. So we had to put our left and right wheels on port1 of two different controllers to match them. Thanks.

                              Fang

                              Comment

                              Working...
                              X