System Core Control Hardware – Initial Field Test Report

[cpapplefamily]

Event: MRI Minnesota Robotics Inventational
Prepared by: Corey Applegate / 4607 C.I.S.
Date: 10/04/2025

Overview
This report summarizes our first experience using the new Control System hardware during an offseason event. With two more events planned, this was our first full-scale test of System Core in a competition environment.

Notably, several members of our shop testing group were not present, so this served as a true evaluation of how a larger group of users might interact with the new hardware for the first time. It’s common at events for a team to be missing their primary programmer, so this test closely reflects a realistic user experience.

General Observations

• The event went well overall, with very few issues encountered.
• We did experience the known issue where motors can continue to run if the Driver Station loses communication. This only occurred once in the pit, but it will need to be investigated and resolved.

System Configuration

• Motor Control: All motors were connected to a CANivore, as each uses CTRE FOC control and requires CAN-FD.
• REV CAN Servo Power Hub: Connected to CAN 1. We observed no noticeable issues. This mechanism is only used briefly at the end of each match, so it was tested 11 times total.
  • The CAN Servo Hub was required due to System Core and WPIlib removing support mostly due to the 3.3v Smart IO ports and since the Smart IO port outputs a control signal even when the Robot is Disabled the use of a passive power hub can not be used because the servo will return to nutral. This has been discussed in another thread.
• PDH (Power Distribution Hub): Connected to CAN 0.

Match Performance Notes
Between Finals Match 1 and 2, our driver reported that the robot felt like a wheel was dragging. A quick visual inspection confirmed one motor was unresponsive and extremely hot to the touch.

Upon reviewing the Driver Station (DS) logs, we found no data for total or per-channel current usage. I plan to work with our programmer on Monday to review CTRE’s automatically generated logs to determine if this data was captured elsewhere, though no USB device was connected to the System Core during the event.

Our team has historically had mixed levels of in-code logging implementation. We typically rely on automatic logs, which have been sufficient for most troubleshooting. As a result, we’ve never prioritized adding third-party logging tools.

Additional observations:

• CAN Usage Logs: Data was present. Should we expect five channels of CAN activity?
• Voltage Trend: Normal activity observed.

Fortunately, our substitute robot helped secure a victory in Finals Match 2, allowing our nearly completed motor swap to transition from an urgent repair to post-match celebration.

Open Questions

1. Are there any software or hardware changes in the new control system that could cause the Driver Station logs to omit power usage data?
2. Should teams expect any differences in how current or voltage logging is handled under System Core compared to previous control systems?

[ThadHouse]

Power distribution logs are not in the image yet. Which is why they’re not there. Additionally since it’s still the old ds, it’s only able to log 1 can bus. I don’t recall if any bus is passed through yet for that or not.

As for the disconnect issue, that is fixed in the newest image that was released on Friday.

[cpapplefamily]

Thanks, is there a formal road map of unimplimented new and feature parity features.

[ThadHouse]

Not really. The whole point of alpha was hardware testing, not fully feature parity. It was mostly just minimal to allow testing all hardware features.

[cpapplefamily]

Sure makes sense, as we test we will make note as not implemented those issues.