Confirm Phoenix 6 automatic alerts reach the AdvantageKit log

[nlaverdure]

Goal

Make sure the automatic Phoenix 6 alerts reach the AdvantageKit log.

Background

• What CTRE says. The Phoenix 6 changelog for 26.70.0-alpha-2 states: "Added support for Alerts. Firmware/API version mismatch, CANivore disconnects, config failure, and Signal Logger disk space warnings are automatic."
• Why it matters. A firmware mismatch or a failed config is the kind of fault we want to see before a match, not after.
• How AdvantageKit logs alerts.
  • AdvantageKit v27.0.0-alpha-5 has AlertLogger, which Logger calls on every cycle. It reads every group in WPILib's native alert registry (AlertDataJNI.getAlerts()) and records each group as outputs (akit/.../junction/AlertLogger.java at v27.0.0-alpha-5).
  • Measured in a 45 s sim run on 2026-09-25: /RealOutputs/Logger/AlertLogMS had 2180 samples, and the default Alerts group was logged.
• What is still unknown. Phoenix creates its alerts in native code (com.ctre.phoenix6.alerts.PhoenixAlert calls AlertsNative.c_ctre_phoenix6_alert_create). No Phoenix group appeared in the sim log. There are two possible reasons:
  • Phoenix does not register its alerts in WPILib's alert registry, so AdvantageKit never sees them.
  • Phoenix creates the alerts only when a fault happens, and none happened in sim.

Tasks

• Trigger a Phoenix alert on the robot, for example by unplugging a CANcoder or by flashing mismatched firmware on a spare device. Check whether a Phoenix group shows up under /RealOutputs.
• If it shows up, there is no code to write. Note the group name here and close this issue.
• If it does not show up, find out where Phoenix publishes its alerts (NT topic or DS) and add a reader that logs them as inputs.

Done when

• A robot log shows a Phoenix alert that was triggered on purpose.

[nlaverdure]

Phoenix 6 automatic alerts do not reach the AdvantageKit log. Follow-up: #52.

Findings

• Robot. Phoenix creates its alerts directly in WPILib's MrcLib (MRC_Alert_CreateAlert). This comes from a symbol scan of libCTRE_PhoenixTools.so, 26.70.0-alpha-2, SystemCore build.
• WPILib's SystemCore alert backend returns only the alerts WPILib itself created. MrcLibGetAlerts loops over its own handle table (hal/src/main/native/cpp/mrclib/MrcLibAlert.cpp, allwpilib v2027.0.0-alpha-7). AlertDataJNI.getAlerts(), which AdvantageKit's AlertLogger reads, never includes Phoenix's alerts.
• MrcLib's Alert.h has no call that lists all alerts. Every alert function takes a single handle.
• Sim. Phoenix alerts are a no-op off a robot controller. CTRE's PhoenixAlert Javadoc says so, and a sim test measured PhoenixAlert.isValid() == false. In the same test, a WPILib Alert appeared in getAlerts() and no Phoenix group did.
• Upstream, allwpilib #8731 (open) tracks robot-side alert logging.