[FTC]: [FTC]: Reason found why robot runs slower in Auto

[PhilBot]

This post is primarily for you FTC teams that use encoders with your drive motors, and issue "Move Fixed Distance" commands in Autonomous.

We could never work out why our robot seemed much faster in Teleop than Auto. Even though we were using constant speed (rather than power) in both modes.

After our first regional (once we knew we wwere going to Worlds) we decided to find out why this was so.

We ran a series of bench tests on a "dummy bot". The interesting thing we discovered was that the DC Motor controllers would run up to full speed (4000 counts per second) if you were issuing a "Constant Speed" command. But when you issued a "Run to position" command (which was also meant to run at constant speed) the motors only ramped up to 65% speed. After that they clipped and never ran any faster.

So if you were trying to go a fixed distance at 95% speed, you only got 65%.

This isn't a LabVIEW effect, since LabVIEW just sends essentially the same command to the motor controller. It's clearly a Hitechnic motor controller thing.

I created a white paper report and included the test code (which charts the results) and sent it off to Hitechnic several months back. The reply I got was basically "it may be doing that". Which I found very unsatisfying.

I've uploaded the white paper/report here.

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

As a result, we completely rebuilt our drive VI's to ONLY use the Constant Speed commands, and we have LabVIEW checking the end of travel. We did some other tweaks along the way, which effectively eliminated the occasional "glitch" which used to terminate some moves prematurely.

The end result was that our Auto sequences ran MUCH faster. A doubler routine which used to take the full 40 secs now had 10 seconds to spare at the end. We had so much time that we could score in the rolling goal, cross the bridge, dispense 5 battons from the high dispenser, and then get back on the bridge to ballence.

Phil.

[JohnFogarty]

I believe your problem is that the LabVIEW based code move fixed distance command uses PID. in RobotC you will encounter the same thing unless you disable PID control.

[PhilBot]

Originally Posted by John_1102

I believe your problem is that the LabVIEW based code move fixed distance command uses PID.

Why do you say that? Did you read the paper?

Are you saying that 1) the LabVIEW code is implementing it's own PID to control the speed, or that 2) it is using a PID control function in the DC Motor Controller?

If you are saying the former then you are dead wrong. LabVIEW is NOT doing PID in either instance.

If you are saying the latter, then I don't see your point..

"Constant Speed", and "Run to Position" BOTH use a closed loop control function (possibly PID) to regulate the motor speed, but why should one run all the way up to 100% while the other is limited to 65% of full speed? Makes no sense.

It's completely logical that Robot C will see the same speed decrease if it's also using the DC Motor Controller's Encoder based moves. Have you studied C's low level Motor Controller calls to see what commands are being sent via the I2C bus? Do you know what commands are being sent?

Phil.

[JohnFogarty]

The first thing that made me think the problem had something to do with PID was your performance data graph.

It doesn't necessarily have to be within your block diagram of your code to be running. In RobotC the motors and sensors setup has a built-in PID control function. Which I have personally noticed does not allow the motors to reach a speed past 65%.



In RobotC the run to position command is the same as our Encoder-target command. We assign a fixed motor power to move the motor to the specified target. The motor uses that speed as the maximum "allowed speed." It then begins to approach the speed based upon Proportional gain. The Integral is defiantly what you see on your graph where the curve is created approaching the set target. Then if you notice there is a oscillation there is your Derivative.

Here your problem is noted basically on how the PID is based.

Speed = ⌂ANGLE/⌂TIME

There is a line of code in RobotC to fix this though and there should be a similar code in LabVIEW.

nSyncMotors = motor[motorD] && motor[motorE]

My first thought is that LabVIEW DOES have it's own PID algorithm running in the motor.vi. In RobotC this is the case.

[PhilBot]

Originally Posted by John_1102

The first thing that made me think the problem had something to do with PID was your performance data graph.

Well, I think you've independantly found the same effect in Robot C, but you've assumed it was hapenning in the C code, when in fact it's hapenning in the Motor Controller.

That Motor configuration page looks like it's being used to set the mode bits that are being sent to the DC controller when commands are issued. (just like with LabVIEW's Motor Configurator utility)

eg:

The "Reversed" checkbox decides whether to set the "Invert" bit in the Controller that is used to flip the motor polarity and encoder count direction.

The "PID" checkbox sets the bit that decides whether the controller should run in Constant Power, or Constant Speed Mode.

I would propose that if you ran some tests you'd find that running a motor at a speed of 100% with the PID box checked, it would run at full speed, but if you ran the same motor at 100% with the PID box checked AND telling it to go 10000 encoder counts, it would run at 65% speed. Indicating that it's not the Speed PID that is causing the problem. It's the Run to position code.

You may not believe me, but please don't refute it until you actually run this very specific test.

As for LabVIEW running a PID function... I assure you it's not. I've traced these calls all the way down to where they assemble and issue the specific I2C register commands to the Motor Controller. I've mapped the individual bits the published Hitechnic control registers and there is NO LabVIEW PID running. It's all in the DC Motor controller.

If you are interested, here is the Motor Controller Register Specification.

http://stuyfissionfusiondevelopment....ief%20v1.3.pdf

Phil.