Subsystems
Review the subsystems paradigm first.
BunyipsLib has various built-in subsystems to assist in robot code creation. Some of these subsystems are required to use features such as RoadRunner, while other subsystems model common subsystems. Subsystems can also be internally composed (childed) through the delegate() method. This page will go over the general plug-n-play BunyipsSubsystem instances available as part of BunyipsLib.
The accompanying method documentation is available on every subsystem, which includes all the relevant methods for the with/set calls used to configure a subsystem. Be sure to read over them if you are planning on using this subsystem, as these methods may be the main ways to configure behaviours.
Important
Where required (such as when a plug-n-play subsystem is unsuitable), you are encouraged to make your own subsystem by extending BunyipsSubsystem! It is highly recommended to review the plug-n-play subsystems to copy semantics and conventions (as mentioned above).
Drive subsystems are special subsystems that implement the Moveable interface. A flowchart is provided below to indicate the relationship the drive subsystems have with the other forms of drivebase interaction, such as localization and accumulation. Further details of the specific implementations are covered in the RoadRunner section.
Localizer instances record pose deltas, passing them into an Accumulator which tallies up all pose deltas, exposed as part of the Localizable interface which is a subset of the Moveable interface. The Moveable interface exposes an additional method, setPower(), to set a target velocity vector.
drive.setPower(Geometry.vel(1, 1, 0)); // Sets power to move the drive left-forward
drive.setPower(Geometry.zeroVel()); // Stops the driveThe SimpleDrive variants exposes nullable Localizer instances, as Localizers are not expected to be used with a simple drive. This is most useful in TeleOp where you don't need to use any features from RoadRunner including localization - which may optimise your loop times if not reading from encoders.
SimpleTankDrive simpleTankDrive = new SimpleTankDrive(Arrays.asList(hw.fl, hw.bl), Arrays.asList(hw.fr, hw.br));
SimpleMecanumDrive simpleMecanumDrive = new SimpleMecanumDrive(hw.fl, hw.bl, hw.fr, hw.br);The standard MecanumDrive and TankDrive classes are used in conjunction with RoadRunner v1.0 to provide localization and tasks to run RoadRunner trajectories. These instances will always be running localization and accumulation in the background, and are moreso the standard drive instances to use in BunyipsLib. More information regarding trajectories is covered in the RoadRunner section.
// See RoadRunner section for more information on driveModel, motionProfile, IMU, and mecanumGains parameters,
// as well as configuring the localizer and accumulator using withLocalizer and withAccumulator.
MecanumDrive mecanumDrive = new MecanumDrive(driveModel, motionProfile, mecanumGains, hw.fl, hw.bl, hw.br, hw.fr, hw.imu, hardwareMap.voltageSensor);
TankDrive tankDrive = new TankDrive(driveModel, motionProfile, tankGains, Arrays.asList(hw.fl, hw.bl), Arrays.asList(hw.fr, hw.br), hw.imu, hardwareMap.voltageSensor);The HoldableActuator is one of the most important built-in subsystems, modelling a generic arm that is able to hold a position and move to any desired position. It is doubly-compatible with the Motor class and normal DcMotor instances, allowing custom PIDs to be used.
A HoldableActuator takes in an instance of a DcMotor and by default, setting the power to 0 through setPower() will switch the arm to run to position to the current position of the arm. Setting powers manually will move the arm at raw speeds. This behaviour can be switched to pure setpoint control through the withUserSetpointControl method.
HoldableActuators can have limit switches mapped to the top or bottom of their travel distance to home encoders, and can also be used to make tasks to run the arm to specific spots.
Review the full API documentation for more features the HoldableActuator is able to do, including homing, integrating several safety features such as steady-state detection and stall detection.
Caution
It is highly recommended to review and use the safety features of HoldableActuator. Many features, namely stall detection, can help you avoid dangerous conditions where the motor is forcing against a hard stop, drawing several amps and heating up rapidly. Always, when configuring a new actuator, ensure it does not stall against an endpoint and the proper safety bounds have been set to allow BunyipsLib to try to recover from stall conditions.
It is possible to find your motor's "stall current" via Hardware Tester, observing the amperage as the motor stalls against a hard stop.
The Actuator subsystem is a simplified version of the HoldableActuator.
Note
Actuator is a new subsystem as of BunyipsLib v7.2.0!
Actuator supports the DcMotorSimple interface, allowing you to assign a subsystem to a continuous servo or motor that doesn't have an encoder attached (such as a motor that does nothing but spin). The API surface is very similar to overlap with the HoldableActuator.
Tip
Especially for intakes where a certain power (1 or -1) represents intaking or outtaking, assigning these numbers to constants in your config to reference is very useful and avoids confusion!
Warning
Where possible, use the HoldableActuator subsystem if your motor supports encoder-based features and current detection. Actuator does not boast any safety features and is designed for use primarily with continuous servos.
The Switch subsystem is used for controlling a single servo as part of a subsystem. It offers bounds, toggling capabilities, and exposes several tasks for delta or positional control.
DualServos is a simplified version of Switch which only supports two fixed, known positions. It is useful for applications such as claws that use two servos and should only reflect two known positions.
BlinkinLights manages a REV Blinkin LED Driver and provides a task interface to scheduling lighting patterns. It also comes with utility methods to send raw PWM pulses for debugging factory code issues.
The Vision subsystem handles Camera operations, and is explained in further detail in the Vision section. Vision is not a traditional subsystem in the sense calculations will perform in the periodic() method, but instead offloads this to the internal VisionPortal for data to be accessed via the BunyipsLib Processor. As such, there are no viable tasks that can be affixed to Vision.
