FRC 1987 Progress Updates

[j0n5m1th]

Previous Updates:

• Blank Display, Hardware Fault #17
• Behavior During Packet Loss #94
• Mounting Fastener Clearance #62
• 6391 and 1987 GRC Updates #199
• USB Camera visionserver Corrupt JPEG data #348

We've run the Systemcore at the following events:

• 2025 IRI
  • This was the first event for Systemcore. The main thing tested here was network stability in OS Alpha 4. In constant contact with the Systemcore team.
• 2025 GRC
• 2025 CitC
• 2025 CTTD
• 2026 IRI

Systemcore Alpha hardware has been very reliable for us both in the shop and in competition. The overall stability rapidly improved during Fall 2025 and has greatly improved now that we're in summer 2026.

Presentations & Demos:

• 2025 KC FIRST Robotics Conference
• 2025 CitC
• 2025 GRC
• Small groups

Robot Code Projects:

• 2025 Robot
• 2026 Robot

Initial bring up from time we initially received the Alpha Systemcore unit to functional teleop robot was one evening.

• Overall, we are very happy with the Systemcore as a "drop in" replacement for the Roborio. Passivity was handled very well across vendors.

[j0n5m1th]

Initial Vision Testing

Alpha 12, fresh image (no robot code running)

USB Cameras Available:

• Arducam OV2311
• Arducam OV9281
• Arducam OV9782

Tested moving a camera across multiple USB ports.

• The pipeline config does follow the camera across USB ports

Tested the Hailo-8 functionality.

• Hailo-8 module confirmed to work as expected. (detected on cameras page and was used in the Apriltag pipeline)
• It seems odd to use a thermal pad to hold the m.2 device against a plastic cover. It would feel better if the cover was aluminum, but it doesn't appear to be an issue in practice (still operating within temperature specs).

Thermals:

• Heat soaked to 72C CPU & 62C Hailo.
  • Unit was sitting on a 6"x6"x3/8" aluminum plate.
• As expected, similar thermal behavior as a Limelight 4. We did not see any obvious thermal throttling issues during an extended uptime. I doubt this would be an issue on the field at an event, but could be something teams will want to account for during prolonged shop sessions.

Multiple Apriltag cameras:

• ~44% of the CPU used for 1 camera, up to ~37fps for 1MP camera
• ~59% of the CPU use for 2 cameras
• ~95% of the CPU use for 3 cameras, ~10fps per camera

General Apriltag performance:

• OV2311
  • 1600x1200 - 25fps
  • 1280x960 - 30fps
• OV9281
  • 1280x800 @ 90fps - unstable
• OV9782
  • 1280x800 @ 30fps - 30fps
  • 1280x800 @ 60fps - 37fps
  • 1280x800 @ 90fps - unstable
• 28fps with Hailo acceleration on 1MP camera

Usability Feedback:

• Navigating away from the camera view back to the other Systemcore pages is difficult. Users need to modify the URL in the address bar to navigate away. Some of our users have tried clicking on the Limelight logo (top left) to navigate back to the Systemcore home page or cameras page. Or open a new browser tab when opening the camera page.
• If a user is on the camera page and the camera is unplugged, then the stream goes blank but the user can still modify the camera / calibration settings. If the page is refreshed after the camera has been unplugged then the page is completely dithered and cannot interact with the page. It would be great if there was some message displayed that the camera is not detected to help the user. Also still allow the user to navigate back to the other Systemcore pages.
• On the camera page, it would be nice to keep the standard status info (battery voltage / CPU % / RAM % / Temp) at the top, alongside the camera type.
• Are there any safeguards put in place to protect users from running too much vision and degrading the rest of the systemcore (robot code)?
• There should be some clear recommendations for Systemcore mounting, especially when running vision pipelines. We haven't encountered any significant issues with thermals, but running cooler is going to be better. So mounting to a flat aluminum plate can help with thermals and onboard IMU data.

Still need to test:

• Multiple of the same type of camera
• More vision pipelines
• Running robot code alongside a vision pipeline

[zachwaffle4]

Have you tested WPILib alpha 5/6 yet? Your current project uses alpha 2, which doesn't have many of the features that will be available in the actual 2027 release of WPILib. Alpha 5 or higher is also required for Systemcore images 10 and up.

[j0n5m1th]

No, we ran Alpha 2 up until last week.

• Timing of releases + vendor deps & events, along with potential compatibility issues were enough of a reason to hold off.

Now that we're past all of that, we will be looking at taking WPILib Alpha 5.

[bhjelstrom]

Thanks for the great feedback. To answer one of your questions, the vision instances have the lowest possible scheduling priority and should degrade in performance to free up cpu for robot code. You can watch the new cpu slices view in the system tab to observe this during your testing.

[j0n5m1th]

Seeing the CPU usage per service is a great addition. It was helpful for this!
Some docs to advise on how that priority works might still be helpful. So teams can understand why the vision system could degrade in performance.

[bhjelstrom]

Definitely, and just noting that there is an entirely new view called "CPU slices" if you haven't seen it. Working on adding helpful tooltips to all of these tools

[j0n5m1th]

For our 2026 robot code port, we ran Systemcore Alpha 9 and WPILib Alpha 2.

Some notes:

• Our experience has been that Systemcore is plenty tolerant of low voltage.
• Our driver commented on increased controls responsiveness.
  • This could be vibes / placebo, but also likely that the robot could keep up with the standard driver input flowing in from the DS.
  • Loop overruns aren't a thing compared to the Roborio.
  • Ran loop timings of 200hz. Increased rate of calculations for things like SOTM improved the overall performance of the robot.
    • Anecdotally, another team asked what we had done to improve the robot's performance since our last event. The Systemcore & ported code was the only robot improvement we had made.
• Overall CPU usage was around 65% while enabled.

I'm excited to see robot performance generally improve as a result of Systemcore. Programming will be in a better place:

• Don't have to refactor code just to hit a performance target of "not too slow". So teams can focus on writing readable and extensible code, hopefully leading to more long term student benefit.
• Opens the opportunities for more computationally intensive tasks, which could be more / faster periodic calculations, more complex operations, and / or more logging.