Small values of kₐ make the iterative solver ill-conditioned. This
change reverts to the constant-acceleration feedforward in that case. It
gives _very_ bad results (hence why we added the iterative solver in the
first place), but it's better than hanging.
```
TEST(ArmFeedforwardTest, CalculateIllConditioned) {
constexpr auto Ks = 0.5_V;
constexpr auto Kv = 20_V / 1_rad_per_s;
constexpr auto Ka = 1e-2_V / 1_rad_per_s_sq;
constexpr auto Kg = 0_V;
frc::ArmFeedforward armFF{Ks, Kg, Kv, Ka};
// Calculate(currentAngle, currentVelocity, nextAngle, dt)
CalculateAndSimulate(armFF, 0_rad, 0_rad_per_s, 2_rad_per_s, 20_ms);
}
```
This produces 1 V and doesn't accelerate the system at all. Using
nextVelocity instead of currentVelocity in the feedforward outputs 41 V
and still only accelerates to 0.4 rad/s of the requested 2 rad/s.
I picked the kₐ cutoff by increasing kₐ until the iterative solver
started converging.
Fixes#7743.
It now uses SQP for problems without inequality constraints, which is
faster.
main:
```
[ RUN ] Ellipse2dTest.DistanceToPoint
0.203 ms
[ OK ] Ellipse2dTest.DistanceToPoint (0 ms)
[ RUN ] Ellipse2dTest.FindNearestPoint
0.019 ms
[ OK ] Ellipse2dTest.FindNearestPoint (0 ms)
```
upgrade:
```
[ RUN ] Ellipse2dTest.DistanceToPoint
0.197 ms
[ OK ] Ellipse2dTest.DistanceToPoint (0 ms)
[ RUN ] Ellipse2dTest.FindNearestPoint
0.015 ms
[ OK ] Ellipse2dTest.FindNearestPoint (0 ms)
```
This is easier to type and follows the naming of Pose2d::Nearest().
Since Ellipse2d and Rectangle2d were added for the 2025 season, we don't
need to add deprecation notices.
This reverts commit d1de7663d3.
Intellisense is still broken on Windows Athena target with the error
`incomplete type "Eigen::Matrix<double, 3, 3, 0, 3, 3>" is not allowed`.
The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues.
Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
Splitting the files didn't help readability or save compilation time and
it confused contributors. Merging them is also in line with how C++
modules will be written.
