hey WPILib devs, is anybody working on changing the way holonomic trajectories are supported in WPILib? i’m fiddling with our trajectory support in preparation for 2024 and i’d like to make sure i’m not duplicating effort or setting myself up for a bunch of rework. Thanks!
(also please don’t suggest one of the other holonomic libraries, i know about them.)
tagging a few folk who might have some knowledge of this topic @Peter_Johnson @calcmogul @Oblarg
WPILib will have to do a complete overhaul to support holonomic trajectories; the current implementation is extremely nonholonomic-specific. We don’t know when that’ll happen because our development effort is being spent elsewhere.
I’ve been involved with GitHub - SleipnirGroup/Choreo: A graphical tool for planning time-optimized trajectories for autonomous mobile robots in the FIRST Robotics Competition., but it’s what you could consider early alpha with no planned timeline for adoption (basically just “when it’s ready”). It also doesn’t fulfill the “real-time generation” requirement some teams have.
excellent, that’s the guidance i was looking for. thank you!
Out of curiosity what exactly is the difference between this and something like pathplanner?
Hi, lead Choreo frontend developer here. Effectively, in PathPlanner, you draw the shape of the path as a curve called a Bézier curve, and it animates a point along the path with your specified acceleration and velocity limits. On top of this, the rotation is handled somewhat separately (especially from what I’ve heard about PathPlanner 2024.)
The problem with this approach for swerve is that it tends to hit maximum linear speed and maximum rotational speed at the same time, with no algorithm consideration for the top module speed making those sections impossible to follow accurately.
Choreo takes swerve dynamics into account, generating the shape and speed profile of the path simultaneously. It expresses the task as a time-minimization math problem, in which the inputs are the robot state (position and velocity in x/y/heading) at many timesteps along the path. Constraints can be applied to the solution. Waypoints can be expressed like “at step 80, have x/y/heading equal these values”, and similar constraints can significantly affect the final path. This becomes a powerful tool to describe the path in terms of what it needs to do, rather than manually fudging waypoints and control handles to get the fastest curve.
Preferably, you want to also have a ChoreoLib that provides an HolonomicController that knows to output Swerve efforts under certain robot constraints.
The robot code knows nothing of the constraints, Choreo just provides the robot state at each timestep as a big JSON for the robot code to load. We do have a ChoreoLib to load these and drive according to that data.
That sounds like a feedback controller doing trajectory generation, which is a violation of separation of concerns. MPC can sorta do what you want, but that’s not what Choreo is, and MPC is too computationally expensive to be feasible to do in real time at the moment.
MPC indeed can work that’s right, but most of the teams would be happier with a simpler solution.
Anyways the bottom line is that not only the generated trajectory should be feasible, but also the efforts you pass to the swerve after feedback control.
If the trajectory is optimal, then “catching up” to it from a disturbance, within the dynamics limits, is difficult to impossible. Effectively, if there’s no “shortcut” to get back on the path (cutting the corner on a curve or reversal), then your correction is attempting to outpace the most time-efficient movement your swerve drive can make. If there is a shortcut, then ensuring the correction is feasible throughout means constantly re-optimizing a trajectory from the current position to the moving setpoint. If you want to be able to deal with disturbances, you need to build margin into your trajectory’s dynamics limits.
Yep.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.