Files
allwpilib/wpimath/src/main/native/include/frc/controller/PIDController.h

248 lines
6.2 KiB
C
Raw Normal View History

// Copyright (c) FIRST and other WPILib contributors.
// Open Source Software; you can modify and/or share it under the terms of
// the WPILib BSD license file in the root directory of this project.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
#pragma once
#include <functional>
#include <limits>
#include <wpi/sendable/Sendable.h>
#include <wpi/sendable/SendableHelper.h>
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
#include "units/time.h"
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
namespace frc2 {
/**
* Implements a PID control loop.
*/
class PIDController : public wpi::Sendable,
public wpi::SendableHelper<PIDController> {
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
public:
/**
* Allocates a PIDController with the given constants for Kp, Ki, and Kd.
*
* @param Kp The proportional coefficient.
* @param Ki The integral coefficient.
* @param Kd The derivative coefficient.
* @param period The period between controller updates in seconds. The
* default is 20 milliseconds. Must be non-zero and positive.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
PIDController(double Kp, double Ki, double Kd,
units::second_t period = 20_ms);
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
~PIDController() override = default;
PIDController(const PIDController&) = default;
PIDController& operator=(const PIDController&) = default;
PIDController(PIDController&&) = default;
PIDController& operator=(PIDController&&) = default;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Sets the PID Controller gain parameters.
*
* Sets the proportional, integral, and differential coefficients.
*
* @param Kp Proportional coefficient
* @param Ki Integral coefficient
* @param Kd Differential coefficient
*/
void SetPID(double Kp, double Ki, double Kd);
/**
* Sets the proportional coefficient of the PID controller gain.
*
* @param Kp proportional coefficient
*/
void SetP(double Kp);
/**
* Sets the integral coefficient of the PID controller gain.
*
* @param Ki integral coefficient
*/
void SetI(double Ki);
/**
* Sets the differential coefficient of the PID controller gain.
*
* @param Kd differential coefficient
*/
void SetD(double Kd);
/**
* Gets the proportional coefficient.
*
* @return proportional coefficient
*/
double GetP() const;
/**
* Gets the integral coefficient.
*
* @return integral coefficient
*/
double GetI() const;
/**
* Gets the differential coefficient.
*
* @return differential coefficient
*/
double GetD() const;
/**
* Gets the period of this controller.
*
* @return The period of the controller.
*/
units::second_t GetPeriod() const;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Sets the setpoint for the PIDController.
*
* @param setpoint The desired setpoint.
*/
void SetSetpoint(double setpoint);
/**
* Returns the current setpoint of the PIDController.
*
* @return The current setpoint.
*/
double GetSetpoint() const;
/**
* Returns true if the error is within the tolerance of the setpoint.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*
* This will return false until at least one input value has been computed.
*/
bool AtSetpoint() const;
/**
* Enables continuous input.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*
* Rather then using the max and min input range as constraints, it considers
* them to be the same point and automatically calculates the shortest route
* to the setpoint.
*
* @param minimumInput The minimum value expected from the input.
* @param maximumInput The maximum value expected from the input.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
void EnableContinuousInput(double minimumInput, double maximumInput);
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Disables continuous input.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
void DisableContinuousInput();
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Returns true if continuous input is enabled.
*/
bool IsContinuousInputEnabled() const;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Sets the minimum and maximum values for the integrator.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*
* When the cap is reached, the integrator value is added to the controller
* output rather than the integrator value times the integral gain.
*
* @param minimumIntegral The minimum value of the integrator.
* @param maximumIntegral The maximum value of the integrator.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
void SetIntegratorRange(double minimumIntegral, double maximumIntegral);
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Sets the error which is considered tolerable for use with AtSetpoint().
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*
* @param positionTolerance Position error which is tolerable.
* @param velociytTolerance Velocity error which is tolerable.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
void SetTolerance(
double positionTolerance,
double velocityTolerance = std::numeric_limits<double>::infinity());
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Returns the difference between the setpoint and the measurement.
*/
double GetPositionError() const;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Returns the velocity error.
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
*/
double GetVelocityError() const;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
/**
* Returns the next output of the PID controller.
*
* @param measurement The current measurement of the process variable.
*/
double Calculate(double measurement);
/**
* Returns the next output of the PID controller.
*
* @param measurement The current measurement of the process variable.
* @param setpoint The new setpoint of the controller.
*/
double Calculate(double measurement, double setpoint);
/**
* Reset the previous error, the integral term, and disable the controller.
*/
void Reset();
void InitSendable(wpi::SendableBuilder& builder) override;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
private:
// Factor for "proportional" control
double m_Kp;
// Factor for "integral" control
double m_Ki;
// Factor for "derivative" control
double m_Kd;
// The period (in seconds) of the control loop running this controller
units::second_t m_period;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
double m_maximumIntegral = 1.0;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
double m_minimumIntegral = -1.0;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
double m_maximumInput = 0;
double m_minimumInput = 0;
// Do the endpoints wrap around? eg. Absolute encoder
bool m_continuous = false;
// The error at the time of the most recent call to Calculate()
double m_positionError = 0;
double m_velocityError = 0;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
// The error at the time of the second-most-recent call to Calculate() (used
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
// to compute velocity)
double m_prevError = 0;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
// The sum of the errors for use in the integral calc
double m_totalError = 0;
// The error that is considered at setpoint.
double m_positionTolerance = 0.05;
double m_velocityTolerance = std::numeric_limits<double>::infinity();
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
double m_setpoint = 0;
double m_measurement = 0;
Add replacement PIDController class (#1300) Originally, PIDController used PIDSource with its "PIDSourceType" to determine whether a class should return position or velocity to the controller. However, the supported languages have changed a lot over 10 years and now support lambdas. Instead of using PIDSource and PIDOutput, users can pass in doubles to the Calculate() function synchronously. This makes the controller much more flexible for team's needs as they no longer have to make a separate PIDSource-inheriting class just to provide a custom input. The built-in feedforward was removed. Since PIDController is synchronous now, they can add their own feedforward on top of what Calculate() returns. To facilitate running the controller asynchronously, there is a PIDControllerRunner class that handles that. By separating the loop from the control law, PIDController can now be composed with others and be used to control a drivetrain (a multiple input, multiple output system that requires summing the results from two controllers) much easier. Also, motion profiling can be used to set the reference over time. All the classes related to the old PIDController are now deprecated. The new classes are in an experimental namespace to avoid name conflicts. While this is a large change, I think it is a necessary one for growth. The old PIDController design was created in a time when languages only supported OOP, and we have more tools at our disposal now to solve problems. This more versatile implementation can be used in more places like as a replacement for Pathfinder's "EncoderFollower" class. There has been hesitation to add lambda support to WPILib for a while now out of concerns for requiring teams to learn more features of C++ or Java. In my opinion, this change makes PIDController easier to use, not harder. The concept of a function is a building block of OOP and should be learned before classes. The ability to store functions as first-class objects and invoke them just like variables is rather natural. Note that PID constants for the new controller will be different from the old one. The original controller didn't take the discretization period into account. To fix this, teams should just have to divide their Ki gain by 0.05 and multiply their Kd gain by 0.05 where 0.05 is the original default period.
2019-07-07 15:37:13 -07:00
};
} // namespace frc2
namespace frc {
using frc2::PIDController;
} // namespace frc