This is needed to support the HelixNavigator project. Maven artifacts should also be reintroduced as a CI step.

A good start would be to create a JSON specification for paths that closely matches the API.

The latest version is broken with MinGW 13.1.0, and the author seems to have abandoned the action.

See https://github.com/SleipnirGroup/Sleipnir/#dependencies for an example.

Sometimes, a trjaopt path can be split into a sequence of paths solvable individually, if the state at a certain waypoint is known ahead of time. This could improve performance if the solve time grows faster than than the dimensionality of the problem.

The library used to do this kind of splitting, but it has since been removed as the new, more flexible constraint system has made it too difficult to determine if state is known ahead of time.

All remnants of this feature should be removed. Start by removing these functions.

A trajopt CLI might allow a user to pass in a path file, then have a trajectory file generated. This could then be used as a build step in an FRC team's code that guarantees all trajectories are up-to-date.

TrajoptLib’s C++ API should allow the user to pass a callback function that gives access to the current state of the trajectory every iteration of the solver.

Here is a concept of what the interface could look like:

SwervePathBuilder path;
// add constraints, waypoints, etc.
SwerveTrajectoryGenerator gen = path.GetGenerator();
gen.SetCallback([](const SwerveSolution& currentState) {
  fmt::print(“Current x: {}”, currentState.x[0]);
});
SwerveSolution finalSol = gen.GenerateSync();

• This has already been achieved with frc-trajopt
• Copy that implementation and add new constraint types, path types, etc.

The Cargo package's build script currently refers to the rest of trajoptlib at .. relative to the package root. This does work for unvendored git dependencies, but it breaks if you vendor the dependency (with cargo vendor) or try to publish trajoptlib to a Cargo registry (e.g. crates.io).

I'm not entirely sure what the fix for this is yet, besides the obvious, inelegant solution of moving the Cargo manifest to the repository root. I think it may be possible to use relative symlinks and have Cargo resolve the symlink. I'll look into it and submit a PR unless there's a particular way you'd like to fix this.

• In CasADi version 3.6.0, macOS arm support was added
• Update the CMake scripts to target the latest version and use the arm64 version when appropriate

There should be a CMake example for building and using TrajoptLib using Cmake

A "keep in" zone is defined as a polygon on the field whose convex hull equals itself. Inequality constraints can be used to keep the robot's bumpers within the zone.