Initial Motor Controller test results are odd.

[R2D2]

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!

[Steve Barker]

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.

[FTC4250]

Excellent information Steve Barker - Thanks!

[Philbot]

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.

[Fang Wang]

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