Store DriverStation-owned GenericHID and Gamepad instances in Java and
C++, and expose the cached objects to Python bindings.
Move hand-written command gamepad and joystick wrappers to compose
cached CommandGenericHID instances plus typed HID wrappers, including a
Python CommandGamepad.
This will let us remove UserControls, while helping ensure that we don't
have state smashing between GenericHID objects.
Another bonus is without inheritance, intellisense will no longer show a
bunch of annoying methods, and instead just what actually exists.
---------
Co-authored-by: Peter Johnson <johnson.peter@gmail.com>
The initial build file generation for robotpy projects was relatively
naive and purpose built to get `allwpilib` compiling, without supporting
all the available features.
This modifies the generation scripts to be able to support multiple
embedded libraries, which will be necessary for #8858, since `mrclib.so`
will need to be bundled along with the hal libraries. In addition some
cleanup was done to get the wheels looking more like what is in pypi.
This provides the ability to simulate parts of the Onboard IMU at the
HAL level. This allows team to use and simulate the IMU in code, and a
follow up PR could be made to the halsim_gui to add a new widget to view
and modify the data graphically.
Since the C++ IMU uses radians for angles that is what I did for the
simulator.
Partially deals with #8845
This removes the confusion of the `ExpansionHubServo` class serving both
purposes, and thus having a `set` method that functions as `setPosition`
when in servo mode and `setThrottle` when not in continuous mode. It
also removes the `setContinuousRotationMethod` which could be confused
for a method that switches the actual servo firmware itself from servo
to continuous mode, which is not a thing that is physically possible I
think.
---------
Signed-off-by: Zach Harel <zach@zharel.me>
1. Make the OpMode interface itself periodic; this means the only
differences between `OpMode` and `PeriodicOpMode` are the latter's
methods to add sideloaded periodic callbacks
2. Make OpModeRobot process callbacks in a similar fashion to TimedRobot
and
3. Add some lifecycle functions (discussed below)
4. Pull the callback priority queue from TimedRobot to a new class
called `PeriodicPriorityQueue` so that `TimedRobot` and `OpModeRobot`
have less duplication
5. Fix a typo in the DriverStationJNI class that causes a memory leak
when certain driver station sim calls
6. Port the C++ OpModeRobot tests to Java
`OpModeRobot` now possesses some `IterativeRobotBase`-stye lifecycle
functions; these functions
1. `robotPeriodic`
2. `simulationInit` and `simulationPeriodic`
3. `disabledInit`, `disabledPeriodic`, and `disabledExit`
(note that `simulationInit` and `disabledInit` may be renamed to match
wpilibsuite#8719)
`OpModeRobot` also now processes `OpMode` changes (by the Driver
Station) in its `loopFunc` method, similar to
`IterativeRobotBase.loopFunc` processing game mode changes; `loopFunc`
is, similarly to `TimedRobot`, provided as a default `Callback`
---------
Signed-off-by: Zach Harel <zach@zharel.me>
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
I left "free speed" alone since that's the technical term for it. In
general, velocity is a vector quantity, and speed is a magnitude (i.e.,
a strictly positive value).
This PR also replaces the speed verbiage in MotorController with duty
cycle.
Fixes#8423.
This hooks up the bazel build to the robotpyExamples. It can use the
(formly pyfrc or whatever) automatic unit tests for an example, as well
as exposing the ability to run the example in simulation, with or
without `halsim_gui` with a command such as `bazel run
//robotpyExamples:AddressableLED-sim`
This required building and using wheels instead of just a normal
`py_library`, so that things like `ENTRY_POINTS` can be used. I took a
bare bones approach to building and naming the wheels (for example the
native ones don't have the OS info or python version in them, so they
wouldn't be suitable publish to pypi, but that can always be updated
later.
Linear OpModes have several major downsides with no obvious solutions:
- Some things stop working automatically--e.g. in a linear opmode,
simulation will not work out-of-the-box; the user must explicitly call
sim themselves. there's a few other things we do periodically, but this
is the big one (it also forces some decisions on other parts of the
library—eg if we want Tunable to work in linear without the user
manually calling refresh, we have to run it on a background thread,
which means it must be thread safe throughout). We can help in some
areas (e.g. have sleep functions call background things), but if the
user is writing a loop that waits to drive a certain distance with no
sleep, it's an easy footgun
- Writing code with no sleeps is easy to do, and can hog an entire
processing core easily--yes, there's more than one core, but it could
still easily impact e.g. vision processing
- Many people I've talked to want robot-level periodic and periodic sim
functions. Given linear opmodes, we have two options, neither of which
is great: (1) don't provide robot-level periodic functions, and the
users who want those must set those up themselves and remember to call
them explicitly from every periodic opmode, or (2) provide them, but
only call them automatically from periodic opmodes, which could be
confusing for linear opmode users (they'd have to call them manually if
they wanted them). Currently we do (1) but someone in the community
already opened a change to do (2).
- Restarting the robot program fixes the "stuck in auto for the rest of
the match" problem but still feels like an ugly hack because the startup
time is not unlikely to make the robot not immediately ready for teleop
Removing LinearOpMode resolves these issues by moving to a periodic-only
structure. We can address the few notable use cases of LinearOpMode
(e.g. very basic autonomous sequences) in other ways such as Blocks
generated code, better state machine tutorials/documentation, etc.
Easier then the last one that put everything in a sub namespace. By
prefixing the name less things break, and intellisense will be less
confusing to new users during the transition.
Resync with `mostrobotpy`
This mostly involves the big "ignore almost everything in the HAL
project" and some fixups for the Addressable LED classes.
Required two small hand fixes to get it building over here with bazel,
and with more compiler warnings on.
I also manually zeroed out the `repo_url` field in the toml files to
avoid unnecessary churn whenever it goes from a release build to a
development build. I already did this with `version` field in there, and
will do a follow up PR that updates the copybara script to do it
automatically.
---------
Co-authored-by: Default email <default@default.com>
User code:
- OpModeRobot used as the robot base class
- LinearOpMode and PeriodicOpMode are provided opmode base classes
- In Java, annotations can be used to automatically register opmode classes
Additional user code functionality:
- OpMode (string) is available in addition to the overall
auto/teleop/test robot mode
- OpMode does not indicate enable (enable/disable is still separate)
- The HAL API uses integer UIDs; these are exposed at the user API level
as well for faster checks
- User code creates opmodes on startup (these have name, category,
description, etc).
DS:
- DS will present opmode selection lists for auto and teleop for
match/practice. During a match, the DS will automatically activate the
selected opmode in the corresponding match period.
- For testing, an overall mode is selected (e.g. teleop/auto/test) and a
single opmode is selected
Future work:
- Command framework support/integration
- Python annotation support
- Unit tests (needs race-free DS sim updates)
- Porting of examples
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
