Commit Graph

17 Commits

Author SHA1 Message Date
ncorrea210
8798700cec [wpilibcExamples] Add inline specifier to constexpr constants (#6049) 2023-12-14 20:52:02 -08:00
ncorrea210
d32c10487c [examples] Update C++ examples to use CommandPtr (#5988)
Co-authored-by: Tyler Veness <calcmogul@gmail.com>
2023-12-03 21:39:29 -08:00
Ryan Blue
3b79cb6ed3 [commands] Revert SubsystemBase deprecation/removal (#5634) 2023-09-14 20:56:48 -07:00
Ryan Blue
aaea85ff16 [commands] Merge CommandBase into Command and SubsystemBase into Subsystem (#5392)
Moves all CommandBase functionality into Command and deprecates CommandBase for removal.
Moves all SubsystemBase functionality into Subsystem and deprecates SubsystemBase for removal.
Adds a function to CommandScheduler to remove all registered Subsystems.
2023-07-13 22:12:01 -07:00
Starlight220
20dbae0cee [examples] Renovate command-based examples (#4409)
Refactor some examples to use newer features, such as HID factories, library-provided command factories, CommandPtr (C++), as well as new idioms such as static/instance command factories.
2022-11-28 08:55:13 -08:00
Starlight220
dcda09f90a [command] Rename trigger methods (#4210)
Motivation

Feedback from 2022 showed that the Trigger API is rather confusing, mostly due to the following:
- duplicate Trigger and Button APIs were available; users were confused searching for a nonexistent difference between them.
- the when terminology was ambiguous and unclear whether it refers to the high state or specifically the rising edge.
- the Active terminology didn't unambiguously refer to the high state; it wasn't unintuitive to understand it as "when the binding is active/polled".
- whileHeld vs whenHeld was very confusing, and the difference between them wasn't obvious. The parallel Trigger verbs, whileActiveContinuously and whileActiveOnce are much less confusing.

Solution

Deprecating Button and its binding methods. The rationale for deprecating Button (and not Trigger) is because Button uses terminology that is needlessly more specific and restricting to the button use case, making the use case of arbitrary trigger conditions unintuitive.

After consideration, deprecation of Button's subclasses was decided against:

- NetworkButton (a trigger condition based on a boolean NT entry/topic) is a use case that is not necessarily intuitive for teams to implement themselves, so it is an abstraction that should be provided in the library. A parallel class for the BooleanEvent level, NetworkBooleanEvent, was also added as part of NT4. NT listeners were considered as a alternative solution, but they require attention to thread safety, and aren't interoperable with the EventLoop API.
- JoystickButton/POVButton provide abstractions around HID buttons. The new Trigger-returning factories on the HID classes are an equal (if not more concise) alternative, but there is no reason not to keep them for those who find their use preferable.

At a later date in the deprecation cycle (perhaps for 2024), when Button is removed, these subclasses should be changed to inherit directly from Trigger.

Trigger's bindings are changed to use True/False terminology, as it should be unambiguous. Each binding type has both True and False variants; for brevity, only the True variants are listed here:

- onTrue (replaces whenActive): schedule on rising edge.
- whileTrue (replaces whileActiveOnce): schedule on rising edge, cancel on falling edge.
- toggleOnTrue (replaces toggleWhenActive): on rising edge, schedule if unscheduled and cancel if scheduled.

Two binding types are completely deprecated:

- cancelWhenActive: this is a fairly niche use case which is better described as having the trigger's rising edge (Trigger.rising()) as an end condition for the command (using Command.until()).
- whileActiveContinuously: however common, this relied on the no-op behavior of scheduling an already-scheduled command. The more correct way to repeat the command if it ends before the falling edge is using Command.repeatedly/RepeatCommand or a RunCommand -- the only difference is if the command is interrupted, but that is more likely to result in two commands perpetually canceling each other than achieve the desired behavior. Manually implementing a blindly-scheduling binding like whileActiveContinuously is still possible, though might not be intuitive.

Notes

It was considered to share BooleanEvent's digital signal terminology; however, once it was decided that Trigger should not inherit from BooleanEvent (due to overload incompatibility) the common terminology was not worth the unintuitiveness stemming from users' unfamiliarity with the signal processing terms.
2022-10-27 22:03:28 -07:00
Tyler Veness
fbdc810887 Upgrade to C++20 (#4239)
* Use explicit this capture required by C++20
* Use C++20 span
* Replace wpi::numbers with std::numbers
* Fix C++20 clang-tidy warning false positive in fmt
* Remove ciso646 include since C++20 removed that header
* Fix global-buffer-overflow asan warnings in ntcore tests
* Add DIOSetProxy constructor to HAL

* Upgrade MSVC compiler to 2022
* Bump native-utils to 2023.2.7 (changes to std=c++20)

Co-authored-by: Peter Johnson <johnson.peter@gmail.com>
2022-10-15 16:33:14 -07:00
Oblarg
d68d6674e8 [examples] Armbot: rename kCos to kG (#3975) 2022-01-31 00:16:26 -08:00
liorsagy
4a944dc397 [examples] Consistently use 0 for controller port (#3496) 2021-07-31 20:39:50 -07:00
Tyler Veness
a238cec12b [wpiutil] Deprecate wpi::math constants in favor of wpi::numbers (#3383)
The constants were moved from std::math to std::numbers before
ratification in C++20.
2021-05-26 00:09:36 -07:00
Peter Johnson
0abf6c9045 [wpilib] Move motor controllers to motorcontrol package (#3302)
Also deprecate SpeedController in favor of motorcontrol.MotorController and
SpeedControllerGroup in favor of motorcontrol.MotorControllerGroup.

The MotorController interface is derived from the SpeedController interface
so that code such as SpeedController x = new VictorSP(1) continues to
compile (just with a warning).

SpeedControllerGroup and MotorControllerGroup are independent classes;
both implement the MotorController interface.
2021-04-17 11:27:16 -07:00
Prateek Machiraju
be0ce99007 [examples] Use PWMSparkMax instead of PWMVictorSPX (#3156)
This accurately reflects the motor controllers that are distributed in
the Kit of Parts.
2021-02-12 22:14:56 -08:00
Peter Johnson
8f1f64ffb6 Remove year from file copyright message (NFC) (#2972)
Also update copyright to include "and other WPILib contributors" and clarify
license referral language to not be restricted to FIRST teams.
2020-12-26 14:12:05 -08:00
Prateek Machiraju
330b90e046 [wpilib] Enable ArmSubsystem in ArmBot example (#2752) 2020-10-01 20:03:50 -07:00
Tyler Veness
d30d1088da [wpiutil] Split units.h into separate headers for each unit (#2551)
Closes #2508.

Co-authored-by: Prateek Machiraju <prateek.machiraju@gmail.com>
2020-06-29 22:25:09 -07:00
Oblarg
6dcd2b0e2c Improve various subsystem APIs (#2130)
Improves the APIs for various prebuilt subsystems (PIDSubsystem, TrapezoidProfileSubsystem, ProfiledPIDSubsystem). Addresses #2128, and also changes the rather cumbersome getSetpoint API to a more intuitive setSetpoint one. Updates examples to match.
2019-11-25 21:46:47 -08:00
Oblarg
e0bc97f66b Add ProfiledPIDSubsystem example (#2076) 2019-11-21 20:55:16 -08:00