Code can only deploy from Macs (Eigen Matrix)

Our programmers all use Windows except for me who is on Linux and our head coach who uses a Mac. A few days ago, whenever one programmer deployed code from his (Windows) machine, it didn’t have any errors or warnings but on enable it crashed with the following error:

/__w/allwpilib/allwpilib/wpimath/src/main/native/thirdparty/eigen/include/Eigen/src/Core/SolverBase.h:150: void Eigen::SolverBase<Derived>::_check_solve_assertion(const Rhs&) const [with bool Transpose_ = false; Rhs = Eigen::MatrixBase<Eigen::Matrix<double, 8, 1, 0, 8, 1> >; Derived = Eigen::HouseholderQR<Eigen::Matrix<double, 8, 3, 0, 8, 3> >]: Assertion `derived().m_isInitialized && "Solver is not initialized."' failed.

But when I deployed, it worked fine. Around this time another programmer tried to deploy and got the same error with code that worked fine if deployed from my laptop. Today, however, when I deployed I got the same error on enable. When the head coach deployed the same code on his Mac it worked. We have all checked for updates using VScode and are using similar development environments.


What we’ve tried:

  • Cleaning build directory
  • Rebooting RIO
  • Rebooting laptop
  • Fresh WPIlib install (only on one machine)
  • Using debugger (SIGABRT received)
Full logs
NT: Got a NT4 connection from 10.22.40.234 port 50707
NT: CONNECTED NT4 client 'Dashboard@3' (from 10.22.40.234:50707)
TeleopInitnavX-Sensor Software Yaw Reset completed.
frcUserProgram: /__w/allwpilib/allwpilib/wpimath/src/main/native/thirdparty/eigen/include/Eigen/src/Core/SolverBase.h:150: void Eigen::SolverBase<Derived>::_check_solve_assertion(const Rhs&) const [with bool Transpose_ = false; Rhs = Eigen::MatrixBase<Eigen::Matrix<double, 8, 1, 0, 8, 1> >; Derived = Eigen::HouseholderQR<Eigen::Matrix<double, 8, 3, 0, 8, 3> >]: Assertion `derived().m_isInitialized && "Solver is not initialized."' failed.
********** Robot program starting **********
NT: Listening on NT3 port 1735, NT4 port 5810
Instantiating navX-Sensor on SPI Port 4.
navX-Sensor C++ library for FRC
Swerve constuctor start
Analog module sample rate is too high: SetMSBFirst not supported by roboRIO 4
Warning at SetMSBFirst: Analog module sample rate is too high: SetMSBFirst not supported by roboRIO 4
at frc::ReportErrorV(int, char const*, int, char const*, fmt::v9::basic_string_view<char>, fmt::v9::basic_format_args<fmt::v9::basic_format_context<fmt::v9::appender, char> >) + 0x178 [0xb69c3214]
at frc::SPI::SetMSBFirst() + 0x70 [0xb6a0639c]
at RegisterIO_SPI::Init() + 0x18 [0x7ec44]
at RegisterIO::Run() + 0x1c [0x7fa8c]
at AHRS::ThreadFunc(IIOProvider*) + 0x10 [0x79388]
at + 0xae2b8 [0xb50902b8]
navX-Sensor Connected.
navX-Sensor Board Type 50 (navX2-MXP (Gen 2))
navX-Sensor firmware version 4.0
navX-Sensor startup initialization and startup calibration complete.
navX-Sensor onboard startup calibration complete.
navX-Sensor Yaw angle auto-reset to 0.0 due to startup calibration.
[phoenix] CANbus Connected: canivore (can0, 313088493353385320202034133703FF)
[phoenix] CANbus Network Up: canivore (can0, 313088493353385320202034133703FF)
Swerve constuctor end
Swerve constuctor start
Swerve constuctor end
Swerve constuctor start
NT: Got a NT4 connection from 10.22.40.234 port 50737
NT: CONNECTED NT4 client 'Dashboard@1' (from 10.22.40.234:50737)
Swerve constuctor end
Swerve constuctor start
Swerve constuctor end
Drivtrain started
Odometry putfield done
robot object created
go get em tiger
RobotInit done
********** Robot program startup complete **********
NT: Got a NT3 connection from 10.22.40.12 port 54358
NT: Got a NT3 connection from 10.22.40.11 port 38640
NT: CONNECTED NT3 client '[email protected]:54358' (from 10.22.40.12:54358)
NT: CONNECTED NT3 client '[email protected]:38640' (from 10.22.40.11:38640)
[phoenix] Library initialization is complete.
[phoenix-diagnostics] Server 2023.1.0 (Feb 17 2023, 19:52:17) running on port: 1250

Our code can be found here

Thanks for any advice on this topic, we’d really like to get this fixed before comp

1 Like

I think what’s causing it is this line (and line 18):

The problem is that this assumes a static initialization ordering between modules, which isn’t guaranteed in C++ (the code as written assumes that kinematics is initialized first, then odometry, but there’s no guarantee this is true). If odometry is initialized first you’ll get the crash.

The easiest way to fix this is to move both variables into the same source file.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.