If the model is unstable, it will almost always diverge within 10
seconds, and the results are rather dramatic. We're also reducing the
threshold to 100 meters because the drivetrain is moving in a small
circle. The translation norm is also used for this reason; the X
component alone regularly crosses zero since the drivetrain moves in a
circle.
This isn't appropriate for a RAII class. In particular, it can cause
foot-shooting in simulation mode if the result of
HALSIM_GetSimDeviceHandle is passed instead of HAL_CreateSimDevice.
Some vestigial functions were never removed, and C++ single-jointed arm
sim was missing a flag for disabling gravity simulation. This is useful
for mechanisms like turrets.
Fixes#2738.
The Gradle heap size is currently set to 1G, and that's becoming too
small for our Linux build.
Developers who want to override this without editing the project's
build.gradle can override these settings with gradle.properties in
GRADLE_USER_HOME (see
https://docs.gradle.org/current/userguide/build_environment.html for
details).
In the second constructor, a new LinearSystem is created and set to
m_plant. This takes a const ref though, so it's storing a reference to a
temporary object. After the constructor finishes, m_plant points to an
invalid object. When Update() is called, it will crash with a
segmentation fault.
This patch fixes the use-after-free by making m_plant a LinearSystem
value type. The first constructor will generate a copy, but that only
happens once.
This includes physics simulation support for arms/elevator models, as well as differential drivetrains.
Swerve might be added at a later date.
Co-authored-by: Claudius Tewari <cttewari@gmail.com>
Co-authored-by: Prateek Machiraju <prateek.machiraju@gmail.com>
Co-authored-by: Tyler Veness <calcmogul@gmail.com>
This helps reduce compilation overhead. I tried slimming down includes
of <Eigen/QR>, but the householderQr() function we use from there
requires including dependency headers from Eigen that don't fit with
lexographic ordering. It didn't seem worth the effort to work around.
This won't affect user code at all since all the Eigen feature usage
here is internal only; users generally only need <Eigen/Core>.
It was added as part of Bryson's rule described in
https://file.tavsys.net/control/controls-engineering-in-frc.pdf. It
doesn't really simplify usage though, and the same thing can be
replicated by multiplying the elements of Q by rho manually. It's easier
to do it that way, it's how 3512 has been doing controller debugging for
a while, and it's probably what other teams will do as well instead of
using the "more structured" way.
Removing these unhelpful overloads also simplifies the LQR interface.
The uid was getting incremented by 1 during registration but not decremented
by 1 during cancellation, so cancellation didn't work correctly.
As the underlying registration ensures a non-zero result, don't increment
the result.
