2020-12-26 14:12:05 -08:00
|
|
|
// 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.
|
2016-01-02 03:02:34 -08:00
|
|
|
|
2014-05-02 17:54:01 -04:00
|
|
|
#pragma once
|
2013-12-15 18:30:16 -05:00
|
|
|
|
2016-09-05 13:55:31 -07:00
|
|
|
#include <memory>
|
|
|
|
|
#include <string>
|
|
|
|
|
|
2018-04-29 23:33:19 -07:00
|
|
|
#include <wpi/deprecated.h>
|
|
|
|
|
#include <wpi/mutex.h>
|
2017-11-13 09:51:48 -08:00
|
|
|
|
2018-07-20 00:03:45 -07:00
|
|
|
#include "frc/Base.h"
|
|
|
|
|
#include "frc/Controller.h"
|
|
|
|
|
#include "frc/Notifier.h"
|
|
|
|
|
#include "frc/PIDBase.h"
|
|
|
|
|
#include "frc/PIDSource.h"
|
|
|
|
|
#include "frc/Timer.h"
|
artf4154: Get rid of raw pointers in C++.
This deals with the majority of the user-facing code
in wpilibC++Devices and a substantial portion of it in
wpilibC++. wpilibC++Sim and wpilibC++IntegrationTests
are untouched except where it is necessary to make them
work with the rest of the libraries.
There is still a lot to do in the following areas:
-The HAL (which we may not want to touch at all).
-The I2C, Serial, and SPI interfaces in wpilibC++Devices,
which I haven't gotten around to doing yet.
-Most wpilibC++Devices classes have void* pointers
for interacting with the HAL.
-InterruptableSensorBase passes a void *params for
the interrupt handler.
-I haven't converted all the const char* to std::strings.
-There are plenty of other cases of raw pointers still
existing.
-This doesn't fall directly under raw pointer stuff,
but move syntax and rvalue references could be introduced
in many places.
-I haven't touched vision code.
-The Resource classes conflict (one is in the hal, the other
in wpilibC++). Someone should figure out a more
permanent fix (eg, just renaming them), then doing
what I did (making a new namespace for one of them,
essentially the same as renaming it).
A few other things:
-I created a NullDeleter class which is marked as deprecated.
What this does is it can be passed as the deleter to a
std::shared_ptr so that when you are converting raw pointers
to shared_ptrs the shared_ptr doesn't do any deletion if
someone else owns the raw pointer. This should only be
used in making old raw pointer UIs.
-I had to alter the build.gradle so that it did not
emit errors when deprecated functions called deprecated
functions. Unfortunately, gradle doesn't appear to be
actually printing out gcc warnigns for some reason.
The best way I have found to fix this is to patch
the toolchains (https://bitbucket.org/byteit101/toolchain-builder/pull-request/5/make-gcc-not-throw-warnings-for-nested/diff)
so that a deprecated function calling a deprecated
function is fine but a non-deprecated function calling
a deprecated function will throw a warning (which we
then elevate with -Werror). I believe that clang
deals with this properly, although I have not
tried it myself.
Change-Id: Ib8090c66893576fe73654f4e9d268f9d37be06a2
2015-06-30 15:01:20 -04:00
|
|
|
|
2016-11-01 22:33:12 -07:00
|
|
|
namespace frc {
|
|
|
|
|
|
2013-12-15 18:30:16 -05:00
|
|
|
class PIDOutput;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Class implements a PID Control Loop.
|
2014-08-05 14:02:11 -04:00
|
|
|
*
|
2017-11-16 00:33:51 -08:00
|
|
|
* Creates a separate thread which reads the given PIDSource and takes care of
|
|
|
|
|
* the integral calculations, as well as writing the given PIDOutput.
|
2016-06-20 23:25:23 -07:00
|
|
|
*
|
|
|
|
|
* This feedback controller runs in discrete time, so time deltas are not used
|
|
|
|
|
* in the integral and derivative calculations. Therefore, the sample rate
|
|
|
|
|
* affects the controller's behavior for a given set of PID constants.
|
2020-03-31 20:43:04 -07:00
|
|
|
*
|
|
|
|
|
* @deprecated Use frc2::PIDController class instead.
|
2013-12-15 18:30:16 -05:00
|
|
|
*/
|
2018-05-16 19:51:37 -07:00
|
|
|
class PIDController : public PIDBase, public Controller {
|
2015-06-25 15:07:55 -04:00
|
|
|
public:
|
2018-05-31 20:47:15 -07:00
|
|
|
/**
|
|
|
|
|
* Allocate a PID object with the given constants for P, I, D.
|
|
|
|
|
*
|
|
|
|
|
* @param Kp the proportional coefficient
|
|
|
|
|
* @param Ki the integral coefficient
|
|
|
|
|
* @param Kd the derivative coefficient
|
|
|
|
|
* @param source The PIDSource object that is used to get values
|
|
|
|
|
* @param output The PIDOutput object that is set to the output value
|
2018-09-12 00:38:19 -04:00
|
|
|
* @param period the loop time for doing calculations in seconds. This
|
|
|
|
|
* particularly affects calculations of the integral and
|
2020-08-31 00:33:11 -07:00
|
|
|
* differential terms. The default is 0.05 (50ms).
|
2018-05-31 20:47:15 -07:00
|
|
|
*/
|
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
|
|
|
WPI_DEPRECATED("Use frc2::PIDController class instead.")
|
2016-11-20 07:25:03 -08:00
|
|
|
PIDController(double p, double i, double d, PIDSource* source,
|
|
|
|
|
PIDOutput* output, double period = 0.05);
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Allocate a PID object with the given constants for P, I, D.
|
|
|
|
|
*
|
|
|
|
|
* @param Kp the proportional coefficient
|
|
|
|
|
* @param Ki the integral coefficient
|
|
|
|
|
* @param Kd the derivative coefficient
|
|
|
|
|
* @param source The PIDSource object that is used to get values
|
|
|
|
|
* @param output The PIDOutput object that is set to the output value
|
2018-09-12 00:38:19 -04:00
|
|
|
* @param period the loop time for doing calculations in seconds. This
|
|
|
|
|
* particularly affects calculations of the integral and
|
2020-08-31 00:33:11 -07:00
|
|
|
* differential terms. The default is 0.05 (50ms).
|
2018-05-31 20:47:15 -07:00
|
|
|
*/
|
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
|
|
|
WPI_DEPRECATED("Use frc2::PIDController class instead.")
|
2016-11-20 07:25:03 -08:00
|
|
|
PIDController(double p, double i, double d, double f, PIDSource* source,
|
|
|
|
|
PIDOutput* output, double period = 0.05);
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Allocate a PID object with the given constants for P, I, D.
|
|
|
|
|
*
|
|
|
|
|
* @param Kp the proportional coefficient
|
|
|
|
|
* @param Ki the integral coefficient
|
|
|
|
|
* @param Kd the derivative coefficient
|
|
|
|
|
* @param source The PIDSource object that is used to get values
|
|
|
|
|
* @param output The PIDOutput object that is set to the output value
|
2018-09-12 00:38:19 -04:00
|
|
|
* @param period the loop time for doing calculations in seconds. This
|
|
|
|
|
* particularly affects calculations of the integral and
|
2020-08-31 00:33:11 -07:00
|
|
|
* differential terms. The default is 0.05 (50ms).
|
2018-05-31 20:47:15 -07:00
|
|
|
*/
|
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
|
|
|
WPI_DEPRECATED("Use frc2::PIDController class instead.")
|
2017-11-19 19:06:00 -08:00
|
|
|
PIDController(double p, double i, double d, PIDSource& source,
|
|
|
|
|
PIDOutput& output, double period = 0.05);
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Allocate a PID object with the given constants for P, I, D.
|
|
|
|
|
*
|
|
|
|
|
* @param Kp the proportional coefficient
|
|
|
|
|
* @param Ki the integral coefficient
|
|
|
|
|
* @param Kd the derivative coefficient
|
|
|
|
|
* @param source The PIDSource object that is used to get values
|
|
|
|
|
* @param output The PIDOutput object that is set to the output value
|
2018-09-12 00:38:19 -04:00
|
|
|
* @param period the loop time for doing calculations in seconds. This
|
|
|
|
|
* particularly affects calculations of the integral and
|
2020-08-31 00:33:11 -07:00
|
|
|
* differential terms. The default is 0.05 (50ms).
|
2018-05-31 20:47:15 -07:00
|
|
|
*/
|
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
|
|
|
WPI_DEPRECATED("Use frc2::PIDController class instead.")
|
2017-11-19 19:06:00 -08:00
|
|
|
PIDController(double p, double i, double d, double f, PIDSource& source,
|
|
|
|
|
PIDOutput& output, double period = 0.05);
|
2018-05-31 20:47:15 -07:00
|
|
|
|
2017-12-04 23:28:33 -08:00
|
|
|
~PIDController() override;
|
2015-07-21 01:23:34 -07:00
|
|
|
|
2018-05-31 20:47:15 -07:00
|
|
|
/**
|
|
|
|
|
* Begin running the PIDController.
|
|
|
|
|
*/
|
2016-07-10 17:47:44 -07:00
|
|
|
void Enable() override;
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Stop running the PIDController, this sets the output to zero before
|
|
|
|
|
* stopping.
|
|
|
|
|
*/
|
2016-07-10 17:47:44 -07:00
|
|
|
void Disable() override;
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Set the enabled state of the PIDController.
|
|
|
|
|
*/
|
2017-12-04 23:28:33 -08:00
|
|
|
void SetEnabled(bool enable);
|
2018-05-31 20:47:15 -07:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Return true if PIDController is enabled.
|
|
|
|
|
*/
|
2018-05-16 19:51:37 -07:00
|
|
|
bool IsEnabled() const;
|
2015-06-25 15:07:55 -04:00
|
|
|
|
2018-05-31 20:47:15 -07:00
|
|
|
/**
|
|
|
|
|
* Reset the previous error, the integral term, and disable the controller.
|
|
|
|
|
*/
|
2016-07-10 17:47:44 -07:00
|
|
|
void Reset() override;
|
2015-06-25 15:07:55 -04:00
|
|
|
|
2017-12-04 23:28:33 -08:00
|
|
|
void InitSendable(SendableBuilder& builder) override;
|
2015-06-25 15:07:55 -04:00
|
|
|
|
|
|
|
|
private:
|
artf4154: Get rid of raw pointers in C++.
This deals with the majority of the user-facing code
in wpilibC++Devices and a substantial portion of it in
wpilibC++. wpilibC++Sim and wpilibC++IntegrationTests
are untouched except where it is necessary to make them
work with the rest of the libraries.
There is still a lot to do in the following areas:
-The HAL (which we may not want to touch at all).
-The I2C, Serial, and SPI interfaces in wpilibC++Devices,
which I haven't gotten around to doing yet.
-Most wpilibC++Devices classes have void* pointers
for interacting with the HAL.
-InterruptableSensorBase passes a void *params for
the interrupt handler.
-I haven't converted all the const char* to std::strings.
-There are plenty of other cases of raw pointers still
existing.
-This doesn't fall directly under raw pointer stuff,
but move syntax and rvalue references could be introduced
in many places.
-I haven't touched vision code.
-The Resource classes conflict (one is in the hal, the other
in wpilibC++). Someone should figure out a more
permanent fix (eg, just renaming them), then doing
what I did (making a new namespace for one of them,
essentially the same as renaming it).
A few other things:
-I created a NullDeleter class which is marked as deprecated.
What this does is it can be passed as the deleter to a
std::shared_ptr so that when you are converting raw pointers
to shared_ptrs the shared_ptr doesn't do any deletion if
someone else owns the raw pointer. This should only be
used in making old raw pointer UIs.
-I had to alter the build.gradle so that it did not
emit errors when deprecated functions called deprecated
functions. Unfortunately, gradle doesn't appear to be
actually printing out gcc warnigns for some reason.
The best way I have found to fix this is to patch
the toolchains (https://bitbucket.org/byteit101/toolchain-builder/pull-request/5/make-gcc-not-throw-warnings-for-nested/diff)
so that a deprecated function calling a deprecated
function is fine but a non-deprecated function calling
a deprecated function will throw a warning (which we
then elevate with -Werror). I believe that clang
deals with this properly, although I have not
tried it myself.
Change-Id: Ib8090c66893576fe73654f4e9d268f9d37be06a2
2015-06-30 15:01:20 -04:00
|
|
|
std::unique_ptr<Notifier> m_controlLoop;
|
2013-12-15 18:30:16 -05:00
|
|
|
};
|
2016-11-01 22:33:12 -07:00
|
|
|
|
|
|
|
|
} // namespace frc
|