1156 Off Season Event Experience

[brunoUC]

Hey all!

With several new members to train in design, software, and fabrication, we chose to design and build a whole new robot for our off season event (hosted in our home state!). Our decision to build a whole new robot mostly came from: if you want to build better robots, you need to build more robots.
The robot is heavily inspired by 1678 and 581. The intake and indexer are a direct copy of 1678, the climber and elevator concepts also came from 1678, and the arm and carriage take cues from 581 and 1778. Working this way gives our students hands-on practice studying proven ideas, understanding the details that make them work, and validating those choices on the field.

I will go over the robot design over in Chief Delphi soon, but leaving bellow a few pictures and our experience with SystemCore so far.

Link to the code used during competition.

WhatsApp.Video.2025-10-08.at.12.59.58.mp4

Systemcore Experience

1. Telemetry with AdvantageScope Lite was plug-and-play, even with limited features. The ability to just open up my notebook, connect to the SystemCore wi-fi and start monitoring telemetry is super useful.

2. The built-in wi-fi on the SystemCore is much more useful than I initially expected. It made debugging radio issues and configuring robot networking much faster. It also simplified our driver station setup, as the only PC that need to be plugged in the AP Radio for 6GHz was the one running the DS. Development and telemetry PCs could connect straight to the SystemCore`s Wi-fi.

3. Excellent boot times, from hitting the deploy button to ready-to-enable we were consistently looking at 10-15s.

4. We struggled with the I/O pull-downs, as we usually used NPN IR sensors. We ended-up switching to 3.3V IRs connected to our Spark Flexes Hard Limit Switch port. We were happy to hear update [#187](Shipping: Digital IO Adapter for Systemcore #187) and that the official units will fix this.

5. We had a weird behavior where the robot drove by itself in [Finals 1](https://www.youtube.com/live/B9nx5DrltsQ?si=v4-4WV9ii9L7bzLq&t=26423) during the climbing sequence. We’ll dig into it over the next few weeks, high chance it’s just our code and not connected to issue [#176](SystemCore Dangerous Communication Error #176) at all, as we were able to disable the robot normally.

6. We ported most of our 2025 code features to wpilib 2027 without much issues. Including our pose estimator classes, go-to-pose algorithms and other control algorithms. You can check our 2025 code here.

7. We also used our custom Python program that reads keyboard inputs and send them over trough NetworkTables, so we could use our custom controller (photo bellow). For this, we had to update our code from NT3 to NT4, as described on the issue we opened here.

8. For auto we kept using Pathplanner for handling commands. No issues related to using the new 2027 WPIlib release. Although we had little time to really dig in and make more complex autos. In fact, if you look at the robot`s movement in the off season you will see that we did not spend much time optimizing its routines. We definetly be spending a little more time on them on the next few weeks.

9. Feature request (not sure if I should open a issue about this): it’d be awesome if the REV Hardware Client could detect all devices on the SystemCore’s five CAN buses when connected to the SystemCore USB-C port. We had a case where the USB-C on the end-effector’s SPARK Flex “failed”, and we couldn’t access the Flex’s USB-C on the carriage. That blocked us from resetting the through-bore we use as the arm’s absolute encoder. The only workaround we found was adding a SPARK MAX at the start of the CAN line.

10. We used all five CAN lines on the SystemCore, dividing it into: Swerve, Elevator, Climber, Carriage and Intake. This led us to one of our first events where we had zero CAN problems, note we fully solder all our buses, and used the 120ohm resistor as termination on all lines. Bellow is a picture of our SystemCore with all CAN buses filled.
    

11. CPU usage never exceeded 60%, and no CAN bus went past 50%.

12. The web client dashboard is excellent for networking setup. This is a huge improvement when comparing to the RIO.

13. SystemCore seems forgiving to user error. Things our students tried (not on purpose), and it held up:

    • Plugged a ethernet with PoE at 12v power straight into the SystemCore instead of the radio.
    • Several shorts caused debris in the I/O ports, webdash and status lights warned us, we cleaned, rebooted, all good.
    • Forgot the SystemCore running overnight on our test bench.
    • Connected every single CAN bus reversed at some point.

14. We’re missing an obvious way to clear memory on the SystemCore. when logs fill it up, we end up reformatting.

15. The system logs that we can access trough the we dashboard don’t feel consistent. We expected one new log file per boot, but it tends to aggregate several. Some instances just don’t show up. The log timing seems to be off on our time-zone as well.

16. During two driver practices (one day before our event) we saw a disconnect followed by the robot driving on its own without disabling, same as post [#176](SystemCore Dangerous Communication Error #176). at the time there was a short on the Systemcore I/O. After cleaning and reformatting, we couldn’t reproduce it. apparently fixed in release [#169 - Alpha 7](https://github.com/LimelightVision/systemcore-os-public).

Overall, the experience was very positive. Even with a few struggles on usability we feel like the SystemCore is a big leap on ease of use and accessibility for FRC. We will definitely miss it during the 2026 season.

Post off-season: we hosted a series of talks and workshops in our lab for all the teams competing in our state. Everything will be on our YouTube channel (in Portuguese, sorry), including a dedicated talk on how we use and our experience with Systemcore so far.