|
Wolflib 0.1.0
PROS differential-drive motion, mapping, and Monte Carlo localization
|
Wolflib motions move a differential-drive chassis to absolute field coordinates. Distances are inches and angles are degrees. The field origin is at its center, positive X points right, positive Y points forward, and headings increase clockwise from positive Y.
Every controller reads getPose(). That pose is raw odometry when MCL fusion is disabled, or confidence-gated odometry plus a bounded MCL correction when fusion is enabled.
Calibrate, establish the known starting pose, and load the map before issuing autonomous motions:
Tune the angular and lateral PID controllers with setMclFusionEnabled(false). Re-enable fusion only after straight distances, turn angles, tracking-wheel signs, and IMU direction are correct.
Motion calls are asynchronous by default. A successful call adds a copied command to the FIFO queue and returns immediately:
Set async to false when the next line must not run until the motion exits:
The Boolean return value says whether the command was accepted. It does not distinguish settling from a timeout. An asynchronous command can be rejected when the configured motion queue is full.
turnToHeading turns in place to an absolute heading:
Use direction to force the longer or shorter side of an obstacle instead of letting Wolflib choose the shortest turn:
Forced direction applies to the entire command. Use AngularDirection::Automatic for normal shortest-angle behavior.
turnToPoint continuously aims at a field coordinate. This is useful when the target may be approached from slightly different starting poses:
Set forwards = false to point the back of the robot at the coordinate:
Avoid a point at or extremely close to the robot's current position because the target bearing becomes poorly defined there.
A swing turn holds one side of the drivetrain at zero and drives the other:
DriveSide::Left means the left side is locked; DriveSide::Right locks the right side. Swing turns need their own real-robot testing because their effective turning geometry and traction differ from an in-place turn.
moveToPoint drives to an absolute X/Y coordinate while steering toward it:
It is the simplest choice when the final heading does not need to be exact. Drive backward without changing the coordinate by setting forwards = false:
moveToPose drives to X/Y and also controls the desired final heading. Its boomerang-style controller aims at a moving carrot point behind the target pose; this is a single pose motion, not path following or pure pursuit.
lead is clamped from 0 to 1. Larger values place the carrot farther behind the target and generally produce a broader approach. horizontalDrift controls how strongly heading correction is allowed while the robot is still far away; a non-positive value uses Drivetrain::horizontalDrift. Treat both as geometry-dependent tuning values, not universal constants.
For a reverse pose approach, set forwards = false and verify the approach and settling behavior on the real drivetrain before using it near field elements.
All option structures inherit these fields from MotionOptions:
| Field | Meaning |
|---|---|
maxSpeed | Maximum motor command magnitude, from 0 to 127. |
minSpeed | Minimum nonzero command. Useful for chaining through an early exit, but too much can overshoot. |
slew | Maximum output change per motion update. Negative inherits the tuned controller value, zero disables it, and positive overrides it. |
earlyExitRange | Optional error threshold for leaving while still moving. It is active only when both this and minSpeed are positive. |
async | Queue and return when true; wait for this command when false. |
TurnOptions adds forced turn direction and front/rear point-facing behavior. MoveToPointOptions adds forward or reverse travel. MoveToPoseOptions adds forward or reverse travel, lead, and horizontalDrift.
Every motion also receives a timeout in milliseconds. It is a hard safety limit, so allow enough time for the slowest expected legal movement without using it as a substitute for correctly tuned exit conditions.
Asynchronous calls are queued in issue order:
For point and pose motions, earlyExitRange is inches from the target. For turn and swing motions, it is degrees from the target. The next queued command starts as soon as the current command exits. This is motion chaining, not a continuous path follower, so it does not calculate one smooth trajectory through all targets.
Check enqueue results if queue saturation must be handled explicitly:
waitUntil lets mechanism actions overlap a motion. Progress is accumulated distance for point/pose moves and accumulated rotation for turn/swing moves:
Call waitUntil immediately after the command it should observe. It tracks the most recently issued command at the time of the call and returns early if that command finishes before reaching the requested progress.
cancelMotion() requests cancellation of only the active command. Already queued commands remain:
cancelAllMotions() stops the active command and clears the queue. Use it for an autonomous abort or before deliberately taking direct control of the drive:
isInMotion() reports true while a command is running or waiting in the queue. waitUntilDone() blocks until both are empty.
The sample values are placeholders. Tune PID gains, exit conditions, slew, minimum output, timeouts, lead, and horizontalDrift on the actual robot.