This milestone represents the first version of the trajectory generator. It was inspired by Lachlan and is quite performant. It is designed to be lightweight and fast, so that it can be used for iterative generation and fast path planning.
Pathfinder (the most popular trajectory generator) has two main problems:
A trajectory generator needs to be able to know the path length to solve the underlying motion profile for distance. Then, as the algorithm moves along the path, it samples the path based on the robot's progress on linear distance.
For example, if the motion profile says to move at 1 m/s for a timeslice of 10ms, then we assume the robot will be 0.01m along the path for the next iteration. Then, we sample the path at that distance for information like position & curvature.
<aside>
⛔ The problem is that most parametric paths like Beziers cannot be trivially distance-parametrized. The t [0, 1] interpolation parameter does not map to distance. The only way to sample the path by distance is to numerically integrate the path by iterating over small samples of t until you reach desired distance.
</aside>
This is why pathfinder is so slow - it numerically integrates the length of the entire path for every single sample.
Motor saturation happens when a motor is told to move at a higher voltage/speed than is possible. This causes significant accuracy issues.
Motor saturation is caused when the motion profile outputs full linear velocity, but the robot has to arc at the same time. For example, this causes 130% power to be sent to the left motor and 70% power to be sent to the right motor. As mentioned, this causes the robot to veer off course as it cannot properly track the curvature of the path at full linear velocity.
Compensating for this problem by leads to another: if the robot moves slower than the motion profile says to, then the robot won't properly track the path. A motion profile that outputs velocity over time to reach a desired distance won't be able to handle the robot undershooting desired velocity due to curvature, and the robot will simply travel less distance.
A solution to this, which is employed by WPIlib, is that forward and backward passes are done on the velocities of the path.