Skip to content

Releases: Pedro-Pathing/PedroPathing

v2.1.2

Choose a tag to compare

@BeepBot99 BeepBot99 released this 07 May 18:49

What's Changed

  • Fix heading snap to tangent after endTime in piecewise interpolation by @mxtmx in #147
  • Fix Follower.isRobotStuck() method by @DylanBPY in #141
  • fix predictive parametric end translational vector by @BeepBot99 in #159

New Contributors

Full Changelog: v2.1.1...v2.1.2

v2.1.1

Choose a tag to compare

@BaronClaps BaronClaps released this 24 Mar 03:04
db46a90

Changes:

  • Patch callbacks never firing due to getNextPathCallbacks and TemporalCallback timing

v2.1.0

Choose a tag to compare

@BaronClaps BaronClaps released this 21 Mar 16:51
ee52690

Changes:

  • Predictive braking: a new path following algorithm that is an alternative to the PIDF algorithm. It removes translational and drive PIDs and centripetal and the two zero power acceleration automatic tuners. It adds a new automatic predictive braking tuner and a new manual tuning step.
    • Uses a quadratic function derived from system identification to predict braking distance at a given velocity.
    • Goes full power until it determines it must brake. When braking, it applies negative power to slow down the bot.
    • Predictive braking is significantly easier to tune than the PIDF algorithm and makes the robot much faster for the majority of teams. However, in some cases the PIDF algorithm can be slightly faster for certain robots if a lot of time is spent on tuning, including "hidden away" constants not covered on the docs.
  • Swerve support: there is now support for swerve drivetrains! Read more about it on the docs.
  • Branding update: we have a new logo and branding!
  • Docs update: the documentation has gotten a revamp with the new branding and a reorganization of the tuning docs.
  • Automatic Offsets Tuner: automatically calculates the strafePodX and forwardPodY offset values for two wheel and pinpoint setups (only these two at the moment)

Predictive braking is much easier/faster to tune as it is automatically tuned, however it is less customizable in its braking behavior. The Heading PIDF exists alongside both methods unchanged from before.

Predictive Braking provides a quick and strong method for users to get their autonomous going; however, manual tuning allows for great customizability and adaptability.

Check out our links:

v2.0.6

Choose a tag to compare

@BaronClaps BaronClaps released this 30 Jan 04:55

Changes

  • Add: Configurable mirror length
  • Fix: 141.5 field length instead of 144 for pose.mirror()
  • Fix: coordinate system conversion
  • Fix: Only counterclockwise turning with TurnTo

v2.0.5

Choose a tag to compare

@BaronClaps BaronClaps released this 01 Jan 05:13

Changes:

Fix: Patch NaN on path completion interpolation
Fix: Change debugString() in ErrorCalculator and VectorCalculator to not mess with the derivative calculation
Fix: Make close callbacks execute in the correct order
Addition: Add setX(), setY(), and setHeading() to Follower and Localizer
Feature: Allow reusing lazily generated paths, i.e., paths with FuturePoses
Fix: Swap caught Exceptions for IllegalArgumentExceptions
Fix: Make setGlobalReversed() not broken
Refactor: Clean up piecewise heading
Fix: Correct stopping distance calculation
Fix: Allow Paths to have separate path constraints from the PathChain
Fix: Make turn and turnTo full speed

v2.0.4

Choose a tag to compare

@BaronClaps BaronClaps released this 06 Nov 01:34
a8501ed

Changes:

  • Fix: PinpointLocalizer angular velocity extraction
  • Fix: turnTo and turn
  • Fix: HeadingInterpolator facingPoint(...)
  • Fix: getDriveError velocity documentation

v2.0.3

Choose a tag to compare

@BaronClaps BaronClaps released this 17 Oct 03:09

Changes:

  • Fix: totalHeading in OTOSLocalizer and PinpointLocalizer would increase in wrong direction with heading numbers with their absolute value > 180°
  • Fix: Drive Vector faces wrong direction at parametric end
  • Fix: Custom Encoder Resolution in Pinpoint locked to be inches, now uses constants' distance unit
  • Add offsetHeading parameter for setTeleOpDrive to specific an offset for fieldCentric driving
    • For example, a user could specific Math.toRadians(180) so they can easily drive from blue drive team perspective in field centric drive without messing with their coordinates
  • Add startTeleOpDrive(boolean useBrakeMode) and startTeleOpDrive() with plans to deprecate startTeleopDrive(boolean useBrakeMode) and startTeleopDrive()
  • Add a follower.update() to startTeleOpDrive (all variants) to mitigate the Pose NPE if a follower.update is not called before.

v2.0.2

Choose a tag to compare

@BaronClaps BaronClaps released this 27 Sep 02:01

Changes:

  • Add InvertedFTCCoordinates for the Decode Field
  • Set up Maven Central Publishing

v2.0.1

Choose a tag to compare

@BaronClaps BaronClaps released this 09 Sep 03:23
5932991

Changes:

  • Fix Lazy Interpolation Gen
  • Add Filter Interface
  • Pose#Mirror for Decode Autos

v2.0.0

Choose a tag to compare

@BaronClaps BaronClaps released this 29 Aug 22:52
ebcefec

Changes

  • Custom, piecewise, reversed, facing point and global heading interpolations
  • Deceleration customizability
    • Optionally decelerating later in path
    • Deceleration throughout PathChain
    • No deceleration option
    • Control of strength and start of deceleration
  • Added support for custom path callbacks; parametric callbacks now use path completion instead of t-value
  • Added support for different drivetrains and curves
  • Pausing and resuming pathfollowing mid-path
  • Separation of Follower into Vector + Error Calculators and Drivetrains
    • Per-instance constants instead of global constants
    • No more jank initialization
    • Constant sets
  • Improved code readability and Javadocs
  • Updates to Pose class (coordinate system swapping fixes, Pose2d conversion)
  • Removal of Point class
  • Updates to Path, BezierCurve, and BezierLine classes for optimization and ease of use
    • Path Constraints able to be set as the default globally or per-path
  • Lazy Curve generation
    • Able to use follower::getPose or other Pose suppliers to generate the curve based on the pose at followPath runtime instead of initialization
  • Few Renames
    • xMovement and yMovement -> xVelocity and yVelocity
    • zeroPowerAccelerationMultiplier -> brakingStrength