Files
allwpilib/wpilibc/src/main/native/cpp/controller/PIDController.cpp

154 lines
4.9 KiB
C++
Raw Normal View History

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
/*----------------------------------------------------------------------------*/
/* Copyright (c) 2008-2020 FIRST. All Rights Reserved. */
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
/* Open Source Software - may be modified and shared by FRC teams. The code */
/* must be accompanied by the FIRST BSD license file in the root directory of */
/* the project. */
/*----------------------------------------------------------------------------*/
#include "frc/controller/PIDController.h"
#include <algorithm>
#include <cmath>
#include <hal/FRCUsageReporting.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 "frc/smartdashboard/SendableBuilder.h"
#include "frc/smartdashboard/SendableRegistry.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
using namespace frc2;
PIDController::PIDController(double Kp, double Ki, double Kd,
units::second_t period)
: m_Kp(Kp), m_Ki(Ki), m_Kd(Kd), m_period(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
static int instances = 0;
instances++;
HAL_Report(HALUsageReporting::kResourceType_PIDController2, instances);
frc::SendableRegistry::GetInstance().Add(this, "PIDController", instances);
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 PIDController::SetPID(double Kp, double Ki, double Kd) {
m_Kp = Kp;
m_Ki = Ki;
m_Kd = Kd;
}
void PIDController::SetP(double Kp) { m_Kp = Kp; }
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 PIDController::SetI(double Ki) { m_Ki = Ki; }
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 PIDController::SetD(double Kd) { m_Kd = Kd; }
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 PIDController::GetP() const { return m_Kp; }
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 PIDController::GetI() const { return m_Ki; }
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 PIDController::GetD() const { return m_Kd; }
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
units::second_t PIDController::GetPeriod() const {
return 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
void PIDController::SetSetpoint(double setpoint) {
if (m_maximumInput > m_minimumInput) {
m_setpoint = std::clamp(setpoint, m_minimumInput, m_maximumInput);
} else {
m_setpoint = setpoint;
}
}
double PIDController::GetSetpoint() const { return m_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
bool PIDController::AtSetpoint() const {
return std::abs(m_positionError) < m_positionTolerance &&
std::abs(m_velocityError) < m_velocityTolerance;
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 PIDController::EnableContinuousInput(double minimumInput,
double maximumInput) {
m_continuous = true;
SetInputRange(minimumInput, maximumInput);
}
void PIDController::DisableContinuousInput() { m_continuous = false; }
void PIDController::SetIntegratorRange(double minimumIntegral,
double maximumIntegral) {
m_minimumIntegral = minimumIntegral;
m_maximumIntegral = 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
}
void PIDController::SetTolerance(double positionTolerance,
double velocityTolerance) {
m_positionTolerance = positionTolerance;
m_velocityTolerance = velocityTolerance;
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 PIDController::GetPositionError() const {
return GetContinuousError(m_positionError);
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 PIDController::GetVelocityError() const { return m_velocityError; }
double PIDController::Calculate(double measurement) {
m_prevError = m_positionError;
m_positionError = GetContinuousError(m_setpoint - measurement);
m_velocityError = (m_positionError - m_prevError) / m_period.to<double>();
if (m_Ki != 0) {
m_totalError =
std::clamp(m_totalError + m_positionError * m_period.to<double>(),
m_minimumIntegral / m_Ki, m_maximumIntegral / m_Ki);
}
return m_Kp * m_positionError + m_Ki * m_totalError + m_Kd * m_velocityError;
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 PIDController::Calculate(double measurement, double setpoint) {
// Set setpoint to provided value
SetSetpoint(setpoint);
return Calculate(measurement);
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 PIDController::Reset() {
m_prevError = 0;
m_totalError = 0;
}
void PIDController::InitSendable(frc::SendableBuilder& builder) {
builder.SetSmartDashboardType("PIDController");
builder.AddDoubleProperty("p", [this] { return GetP(); },
[this](double value) { SetP(value); });
builder.AddDoubleProperty("i", [this] { return GetI(); },
[this](double value) { SetI(value); });
builder.AddDoubleProperty("d", [this] { return GetD(); },
[this](double value) { SetD(value); });
builder.AddDoubleProperty("setpoint", [this] { return GetSetpoint(); },
[this](double value) { SetSetpoint(value); });
}
double PIDController::GetContinuousError(double error) const {
if (m_continuous && m_inputRange > 0) {
error = std::fmod(error, m_inputRange);
if (std::abs(error) > m_inputRange / 2) {
if (error > 0) {
return error - m_inputRange;
} else {
return error + m_inputRange;
}
}
}
return error;
}
void PIDController::SetInputRange(double minimumInput, double maximumInput) {
m_minimumInput = minimumInput;
m_maximumInput = maximumInput;
m_inputRange = maximumInput - minimumInput;
// Clamp setpoint to new input range
if (m_maximumInput > m_minimumInput) {
m_setpoint = std::clamp(m_setpoint, m_minimumInput, m_maximumInput);
}
}