View Single Post
  #105   Spotlight this post!  
Unread 20-06-2013, 04:57
JamesTerm's Avatar
JamesTerm JamesTerm is offline
Terminator
AKA: James Killian
FRC #3481 (Bronc Botz)
Team Role: Engineer
 
Join Date: May 2011
Rookie Year: 2010
Location: San Antonio, Texas
Posts: 298
JamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to beholdJamesTerm is a splendid one to behold
Re: NI releasing/designing new controller for FRC

Quote:
Originally Posted by Tom Line View Post
Our homebrew PID normalizes for time, so the calculation itself does not need to be inside a timed loop. We place it in a timed loop so that we can attempt to match the speed controller update rate for the best 'idealized' performance. I'm not sure how you'd go about this without a timed loop.
There are a few questions I have on this:
1. How well would this work mechanically if you used a 10ms timed loop?
2. How much improvement would the cpu usage be for this?

Unfortunately, I do not know much about LabView at all, but in c++ you call GetTime() in your main OperatorControl() loop and pass this time as a parameter. For our code the entire loop consists of "void TimeChange(double dTime_s)" call delegated out to various classes including the PID controller class (per rotary system).

Here is our main loop
Code:
	double LastTime = GetTime();

	while (IsOperatorControl() && !IsDisabled())
	{
		const double CurrentTime=GetTime();
		//I'll keep this around as a synthetic time option for debug purposes
		//const double DeltaTime=0.020;
		const double DeltaTime=CurrentTime - LastTime;
		LastTime=CurrentTime;
		//Framework::Base::DebugOutput("%f\n",time),
		m_Manager.TimeChange(DeltaTime);
		Wait(0.010);
	}

Last edited by JamesTerm : 20-06-2013 at 05:27.