FRC 1987 Progress Updates #349

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

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.

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.

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.