default m_period for PIDController???

[cstelter]

Hi All,
Our team (3018 Nordic Storm) has created a PIDSubsytem class and instantiated 4 of them and given them a SpeedController implementation

i.e.

class NordicSpeedController extends PIDSubsytem implements SpeedController{
...
}

In this way we can instantiate 4 separate PID Subsystems by passing a Talon and an encoder to each and then in the class we implement the set() entry from the SpeedController interface to call setSetpoint() and set up the returnPIDInput to scale the rate of the encoder such that 1.0 generates a rate that is our maximum. This can also be accomplished by the call to setDistancePerPulse() though.

Then we pass these 4 NordicSpeedControllers to RobotDrive and we of course get far better results on our mecanum drive than using a standard SpeedController (Talon) with just PWM setting without feedback.

As we were tuning the PID, we discovered that it was *very* sluggish. Upon further investigation, we discovered that in PIDController.java we have:

public static final double kDefaultPeriod = .05;
...
private double m_period = kDefaultPeriod;


From what I could tell, these are in seconds so we only revisit the pid 20 times a second by default??? I don't have last year's wpilib on my system but I seem to recall teleopPeriodic was called 50 times a second and that PID's defaulted to 100 times a second (0.01 period).

We changed our period to .005 (by passing in p,i,d,f,period constructor via super()) and things got much better, so I think we followed the breadcrumbs properly to resolve our issue.

So my question for the forum is-- did we get off in the weeds and misunderstand something? I tried searching CD for various keywords to find a discussion of the above but failed miserably-- that's not to say there are no threads,but I could not find any. I find it hard to believe others have not run across this. If we are not in the weeds-- I wanted to raise the visibility of this because a 50ms period is going to make PIDs not work well at all from our experience.

In looking at how PIDController schedules its period, it seems that an overall scheduler schedules all tasks and that the minimum resolution is 1ms. I discovered this at home after our practice so I will be having our team try 1ms instead of 5ms the next time we meet (unfortunately only 3 times a week ). Running 4 pids at 5ms period barely put the roboRio load over 20% so that was pretty cool!

We had planned to use the CAN Talon to marshal the PID for each motor in a largely similar way (to minimize effort of rio), but we didn't have the SRX when our pracitce chassis was complete. We have the Talon's now, but we still haven't wired them up yet, and I'm wondering if there will be much of a benefit.

Thoughts anyone? Anyone have similar insights to share? I think adding a Speed Controller interface to a PID Subsystem is a nifty way to use RobotDrive along with encoders which otherwise isn't terribly simple, so I wanted to throw that out there for teams to consider as well.