Go to Post Just as you and your team will make hard decisions as you struggle to build a robot, FIRST has had to make hard decisions concerning maximizing safety while making the number of rules as small as possible. - Mike Betts [more]
Home
Go Back   Chief Delphi > Other > FIRST Tech Challenge
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #4   Spotlight this post!  
Unread 03-05-2011, 19:39
JohnFogarty's Avatar
JohnFogarty JohnFogarty is offline
Trapped under a pile of MECANUMS :P
AKA: @doctorfogarty
FTC #11444 (Garnet Squadron) & FRC#1102 (M'Aiken Magic)
Team Role: Mentor
 
Join Date: Aug 2009
Rookie Year: 2006
Location: SC
Posts: 1,580
JohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond reputeJohnFogarty has a reputation beyond repute
Re: [FTC]: [FTC]: Reason found why robot runs slower in Auto

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.
__________________
John Fogarty
2010 FTC World Championship Winner & 2013-2014 FRC Orlando Regional Winner
Mentor FRC Team 1102 M'Aiken Magic
"Head Bot Coach" FTC Team 11444 Garnet Squadron
Former Student & Mentor FLL 1102, FTC 1102 & FTC 3864, FRC 1772, FRC 5632
2013 FTC World Championship Guest Speaker
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 13:26.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi