ViperBots Progress Updates

[mray190]

ViperBots out of Austin TX is composed of 10 FTC and 1 FRC team. We will be getting student representatives from all teams to participate in the alpha.

This includes teams:
FTC 4545 OUROBOROS
FTC 4546 SNAKEBYTE
FTC 6209 VENOM
FTC 6210 STRYKE
FTC 6299 QUADX
FTC 7161 HYDRA
FTC 11503 HYPERFANG
FTC 12596 COPPERHEAD
FTC 16311 RECOIL
FTC 18030 LEVIATHAN
FRC 6800 VALOR

We received our kit on Friday, and so far have powered it up and successfully flashed beta 10. Downloaded the driver station and have confirmed connectivity over ethernet.

Built the Tank Drive Gamepad example in C++, setup intellisense, and then deployed to the Systemcore with no other motors or anything hooked up. Confirmed Enabling and Disabling via the RSL light LED ("mode").

Looks good and is ready to go for the 2 tests. Will start with the A301s and then migrate to a robot when ready.

[mray190]

Was able to download the RHC2 IPK and then upload it as a tool in the SystemCore UI. Opened up the Rev Hardware Client, attached a A301 motor, and then was able to see it in the client.

Downloaded the v2027.0.0-prerelease.12 and uploaded that firmware to the motor. Enabled using the driver station, and took control over the motor. Confirmed duty cycle, position, and velocity control all worked for the motor.

Will repeat the process with all 8 A301s!

[mray190]

Catching Up, Part 1: Bench Bringup (June)

It has been a while since I last posted, apologies! Our ViperBots student representatives started meeting in person in July, and then all of our teams went back to school full time around the middle of August. Since then, teams have been preparing for the start of the season on top of a much heavier school load. Despite the ramp-up, we were still able to make a lot of progress.

Rather than cram everything into one update, I'm going to catch up over a series of posts. My earlier posts were pretty brief, so this first one goes back to June and fills in the details of my bench bringup, up to the point where I handed the software off to our student software reps.

The Bench Setup

Everything in this post was done on my desk with a single A301:

• Power: The MotionCore runs off a Milwaukee M18 battery, and the SystemCore is powered from the MotionCore. Every connection used the pre-crimped cables included in the kit, so no crimping was needed.
• Network: Ethernet from the SystemCore to my desktop for deploying code.
• Motor: One A301 with the 215 RPM gearbox, plugged into MotionCore port D0.

June 7: Flashing the OS and First Deploy

Before plugging anything in, I read through the SystemCore README and our testing plan in FTC-Testing.md. Then I installed:

• WPILib 2027 alpha 6
• Limelight Hardware Manager 2.0.7 (Windows)
• Build 138 (beta 10) of the SystemCore OS

To flash the OS, hold the config button down with an Allen key while powering on the SystemCore. That puts it into flash mode, and Limelight Hardware Manager then recognizes it. The flash went through with no issues.

After flashing, I confirmed that the SystemCore web UI loads over all three connections: Wi-Fi, Ethernet, and USB. If you've used a Limelight camera before, the web portal will feel very familiar.

Next, I built the C++ Tank Drive Gamepad example, set up IntelliSense, and deployed it over Ethernet with nothing else connected. I enabled and disabled from the Driver Station and confirmed the mode change on the RSL/mode LED.

I also tried importing our 2026 robot code into 2027. The import itself worked, but none of the vendor libraries we depend on were available for alpha 6 yet, so it wouldn't build. CTRE looked like it would work with v2027.0.0-alpha-2, but that meant dropping back to an older WPILib alpha.

June 8: A301 Assembly and Firmware

Mechanical: I attached the 215 RPM gearbox to the A301, installed the spline output shaft, and held it in place with shaft collars.

Lesson learned: Use good Allen keys. I snapped the ball end off a key inside a shaft collar screw and spent an hour getting it out with a left-hand drill bit. I immediately ordered a set of Bondhus keys.

Firmware: I followed REV.md:

1. Downloaded the REV Hardware Client 2 (RHC2) IPK and installed it as a tool through the SystemCore web UI.
2. Downloaded the v2027.0.0-prerelease.12 A301 firmware from the same page and flashed it using RHC2 running on the SystemCore.
3. Enabled the robot from the Driver Station, took control of the motor in RHC2, and tested:
   • Duty cycle
   • Velocity
   • Position

All three worked. REV ships default PID gains, so a free-spinning motor is controllable in velocity and position mode without any tuning. That's a really nice out-of-the-box experience. The flip side is that there isn't much to configure yet, either in RHC2 or from code through REVLib.

AdvantageScope: I also installed AdvantageScope as an app on the SystemCore, but it crashed when I launched it. However, RHC2 now has a Telemetry tab with signal graphing "powered by AdvantageScope." It let me plot the A301's voltage, current, and motor temperature live, along with encoder values, faults, and warnings.

Note that RHC2 lists the motor as [0] A301 3. That comes up again below.

June 10: First Motor Movement from Robot Code

I called setPower(4_V) on the A301 in TeleopPeriodic... and nothing happened. The motor was in MotionCore port D0, and I had configured bus 0, CAN ID 3 to match what RHC2 displayed.

It turns out this is a known gotcha (#286): MotionCore CAN bus IDs don't start at 0. Port D0 is bus 5, CAN ID 3. After changing the bus to 5, it worked immediately with no other changes. I was driving the A301 with an Xbox controller through the Driver Station, and I confirmed voltage and velocity control from code.

What We Learned About CAN Buses

These are already known to most of you but these were in my notes from June so I am re-iterating again:

• The SystemCore has 5 CAN buses (S0–S4), and the MotionCore has 20 (D0–D19).
• MotionCore bus IDs start at 5, so D0 = bus 5, D1 = bus 6, and so on. The A301 on a MotionCore port showed up as CAN ID 3.
• Don't hardcode bus numbers. Use the predefined enums (CANBusMap; see [hal,wpilib] Switch CANBusMap to Enum, use it for CAN API allwpilib#8977). CTRE's Phoenix 26.50.0-alpha-1 also added CANBus.systemcore(int) and CANBus.motioncore(int).

A Note for FTC Teams

For FRC, the ecosystem doesn't change much. For FTC, the change is big: FTC is adopting most of the FRC ecosystem. Some things our FRC students take for granted are brand new to FTC, and from what other FTC alpha teams are posting, they're tripping people up:

• You have to enable from the Driver Station before RHC2 can drive a motor
• Using AdvantageScope to debug logs
• SmartDashboard buttons
• WPILib/Gradle project structure and vendordeps

Because of this, our FRC and FTC students attend all of our SystemCore meetings together for cross-training.

Handing Off

With a motor spinning from robot code, I handed the software off to our student software reps. The goal: an FTC-sized mecanum chassis with four A301s running Valkyrie, with high-caliber code that works the first time it's deployed because it was already verified in simulation. In priority order:

1. Simulation and AdvantageScope working on 2027, using last year's FTC field in AdvantageScope.
2. Drivetrain-agnostic commands. Commanding "go to 0°" should work whether the robot is swerve, FTC mecanum, or a tank kitbot, so any ViperBots team can use Valkyrie's heading tracking and drive-to-point on any drivetrain. Holding a button should lock the heading to a corner of the field, mimicking the target tracking on 6800's 2026 robot.
3. AprilTag localization from a USB camera plugged directly into the SystemCore, with our vision sensors abstracted so that a Limelight, a USB camera, or eventually a ThriftyCam are interchangeable. After reading 2818 G-FORCE Progress Updates #246, we made this one optional. Running PhotonVision directly on the SystemCore doesn't appear to be possible yet, and while a single-camera OpenCV pipeline works, you shouldn't expect great performance from it.

Next post: getting that mecanum drive moving on a real FTC robot.

[mray190]

Catching Up, Part 2: One Codebase for FTC and FRC (June–July)

After my bench bringup, our student reps took over the software. From the start, our goal has been a single codebase that every ViperBots team can use: our 10 FTC teams and our FRC team. SystemCore is the first time that's realistic, because FTC and FRC now share WPILib, the vendor libraries, and the tooling. This post covers the software work from mid-June through mid-July. Most of it was done in simulation, before we had a robot to drive.

All of the code referenced here is public on the 2027 branch of Valkyrie, our shared library.

The Team

• A student software rep from FRC 6800, writing C++ in Valkyrie
• A student electrical rep from FRC 6800
• A student rep from FTC 16311 Recoil, testing in Java

The FTC rep started with the same steps I did: read through FTC-Testing.md and the README, then install WPILib, Limelight Hardware Manager, the Driver Station, and AdvantageScope. Next, they took Recoil's code from last season, stripped it down to just the drivetrain, and began porting it to Java on 2027.

Our FRC software rep pointed the FTC rep to Valkyrie's mecanum implementation as a reference. Since FTC is now on WPILib, the classes are the same whether you're in C++ or Java, so FRC code works as a reference for FTC students. That's already paying off for cross-training.

June 9–10: Porting Valkyrie to 2027

Valkyrie is our year-agnostic C++ library of wrappers around motor controllers, drivetrains, gyros, and sensors. Our FRC software rep ported it to 2027 on a separate branch, with the goal of using it for both our FRC and FTC teams. As of June 9, everything converted except code that depended on vendor libraries that weren't available yet:

• PhoenixController, CANrangeSensor, and CANdleSensor (CTRE)
• NeoController (REV)
• GrappleSensor (Grapple)
• The CTRE-based pose estimators, kinematics, and Pigeon usage in our swerve drive (stubbed out)
• Choreo path following in our trajectory follower (stubbed out)
• AprilTagsSensor and Limelight: converted, but they couldn't compile because LimelightHelpers hadn't been ported to 2027 yet. WPILib 2027 changed its JSON implementation, so we ported LimelightHelpers by hand and removed its JSON parsing.

Most of the port was renaming. For example, frc2/command/Command.h is now wpi/commands2/Command.hpp. On the REV side, REVLib 2027 now returns a rev::util::Signal<> from getters like GetPosition() and GetVelocity(), similar to CTRE's StatusSignal.

Lesson learned: Vendor readiness set our pace more than WPILib did. As each vendor shipped a 2027 alpha, that code came back online. Today the branch builds against Phoenix 6 26.50.0-alpha-1, REVLib 2027.0.0-alpha-6, PathPlanner 2027.0.0-alpha-3, and Limelight's official vendordep. The Limelight vendordep replaced our hand-ported LimelightHelpers. Only GrappleSensor is still excluded from the build.

We also set up a new barebones 2027 robot project for SystemCore testing, with just Robot.cpp/Robot.h and Valkyrie as a git submodule. Instead of hand-migrating our 2026 project, we generated a fresh 2027 project and re-applied our custom build changes on top of it. That keeps us aligned with the project structure WPILib supports.

Design Lesson: Abstract the Hardware, Not Just the Motors

Valkyrie is built around vendor-agnostic interfaces. Our swerve drive already proved the idea with BaseController: you can swap one motor vendor for another by changing a single motor definition, and the rest of the robot code stays the same. SystemCore pushed us to extend that pattern:

• Motors: A301Controller joined PhoenixController and NeoController under BaseController. We debated how far to take the abstraction. Different vendors' motors differ enough during initialization that construction won't be identical. Using a motor, though (setting power, position, and velocity, and reading sensors), should be a seamless swap.
• Gyros: We had always talked to a Pigeon directly. We pulled that out into a generic Gyro interface (rotation, angular velocity, acceleration), with implementations for the Pigeon2 and WPILib's OnboardIMU. For FTC teams, the onboard IMU means one less part to buy and wire.
• Drivetrains: On top of swerve, we added Differential (tank) and Mecanum drivetrains aimed at FTC-style robots. Both take BaseControllers and a Gyro, so they don't know or care which motors or IMU they're using. They don't support dead-wheel odometry yet. That's a real gap for FTC, since so many FTC teams rely on it.

Feedback on the A301: Writing A301Controller showed us which parts of our common motor API the A301 can't support yet. Follower mode, setting PIDF gains, changing the neutral mode, and simulation all report errors. The A301 also has no published motor model, so we're using the NEO's DCMotor model as a placeholder. Simulation is the one we feel most, since our whole plan was to verify code in simulation before it touches a robot.

Design Lesson: CAN Bus Naming Isn't Consistent Across Vendors Yet

Once CTRE released Phoenix 6 v26.50.0-alpha-1, we could port our PhoenixController. That raised the question of how to specify a CAN bus, since every vendor currently does it differently:

• CTRE: CANBus.systemcore(int) and CANBus.motioncore(int), plus string names like can_s1. The default bus with an empty string is can_s1, and we still aren't sure how that maps to WPILib's bus numbering (is can_s1 bus 0?).
• REV: A plain integer bus ID.
• WPILib: CANBusMap, which is vendor-agnostic.

We don't want each controller taking whatever its vendor prefers, because then swapping a motor also means changing how its bus is specified, which defeats the purpose of Valkyrie. Our REV-based controllers (A301Controller and NeoController) take WPILib's HAL_CANBusMap and convert it to REV's integer bus ID internally. Our CTRE devices, such as PhoenixController, still take ctre::phoenix6::CANBus. The next step we've discussed is our own CAN bus type in BaseController. It could be constructed from either a CANBusMap value or an arbitrary string (for CANivores), with each controller converting it to what its vendor expects.

Feedback: A single shared way to name SystemCore and MotionCore buses across WPILib and every vendor would remove a whole class of mistakes. That's especially true for FTC teams, who are used to plugging motors into numbered ports and have never had to think about CAN buses.

Simulation Findings

Simulation mostly worked on 2027 alpha 6, with two problems:

1. The Driver Stations wouldn't connect to simulation. Neither the new FIRST Driver Station nor the NI Driver Station connected to a simulated robot. Only the built-in simulation GUI worked. The alpha 6 FIRST Driver Station came out on July 11 and still didn't support simulation.
2. The gamepad axes looked swapped. With a regular Xbox controller, the simulation GUI and the NI Driver Station report the right stick X/Y as axes 4/5 and the left/right triggers as axes 2/3. WPILib's Gamepad expects the opposite (right stick on 2/3, triggers on 4/5). At the time, we worked around it by temporarily swapping the axis getters in our Gamepad wrapper. We haven't confirmed whether this is a WPILib issue or something specific to our controller.

Vision: Why USB-Camera AprilTags Matter More for FTC

My original plan included AprilTag localization from a USB camera plugged directly into the SystemCore. After reading #246, I suggested we skip it for now, but our software rep had already built a USB-camera AprilTag sensor. It supports two modes:

• Single-tag: Each visible tag produces its own pose estimate, and the sensor picks the best one by score.
• Multi-tag: All visible tags feed into OpenCV's solvePnPRansac to solve for a single pose.

This matters much more for FTC than for FRC. Most competitive FRC teams run vision on an off-board coprocessor, but many FTC teams will only have the SystemCore. As one of our mentors put it, running a single camera on the SystemCore is cool, but don't expect great performance.

Feedback: The current AprilTag vision example is a lot of code for an FTC student to work through. A higher-level, WPILib-provided helper for USB-camera AprilTag pose estimation would go a long way for FTC teams.

Next post: our July open labs, and the saga of updating our A301 firmware.

[mray190]

Catching Up, Part 3: July Open Labs and the A301 Firmware Saga

By early July, the software was in good shape in simulation, and it was time to get hardware in front of students. We scheduled two optional open labs at the school (July 15 and July 22, 4–8 PM) with the goal of getting a robot moving. Instead, most of July went to one problem: getting our A301s onto new firmware. This post covers what went wrong, what finally fixed it, and what we'd tell other teams.

July 15: Open Lab 1

Our FTC rep's notes from the first lab:

• Tried to open REV Hardware Client 2 (Alpha) from the SystemCore web UI and got Application error: a client-side exception has occurred while loading 172.30.0.1 (see the browser console for more information).
• Couldn't find the REV Hardware Client beta build to install locally.
• Spent the rest of the lab trying to update the A301s.

This was the same failure described in #330. We confirmed:

• It failed whether we connected to the SystemCore over USB-C or over its Wi-Fi AP.
• In the browser console, the Is leader? log showed true over USB-C and false over the Wi-Fi AP. We only checked this a couple of times each, so it's a data point, not a conclusion. I had never configured the Wi-Fi AP on my bench unit in June and never hit this problem, so our first idea was to re-flash the SystemCore without setting up the AP.
• We could see the frontend calling the backend endpoints mentioned in the issue, but we couldn't figure out how to trigger the update through them ourselves.
• We couldn't find the A301_MANUAL_FIRMWARE_UPDATE_VIA_TERMINAL.md referenced in the issue, since it lived in another team's fork.

This mattered more than just one lab. REVLib 2027-alpha-4 requires A301 firmware prerelease-15, so until the motors were updated, we were stuck on REVLib alpha-3. Everything downstream was blocked on this one firmware update.

Trying a Bridge Device

Next, we tried updating the A301s through another REV device acting as a bridge, first a PDH and then a SPARK MAX, wired to our "drybones" test chassis. Both times, RHC2 identified the A301 as a SPARK MAX. We flashed the prerelease-15 firmware anyway. The update appeared to complete successfully, but the firmware version never changed.

Feedback: When a tool doesn't recognize a device, it should say so rather than falling back to a different device type. Better still, a firmware update that didn't apply should fail loudly instead of reporting success.

July 16: Finding the Root Cause

The morning after the lab, our FRC software rep reread the docs and found the real problem. The SystemcoreTesting docs say firmware prerelease-15 is only compatible with RHC2 1.2.1. We had installed the latest stable RHC2 that morning and assumed we were current. We were actually on 1.0.7. The 1.2.1 build linked from the SystemcoreTesting repo was the alpha, but its version number had no -alpha or -beta suffix, so it looked like just another stable release.

RHC2's own changelog explained everything we had seen. A301 support was added in 1.1.0, so our 1.0.7 install didn't know the A301 existed. That's most likely why it showed our motors as SPARK MAXes, and why a "successful" update did nothing.

Feedback: Please put -alpha or -beta in prerelease version numbers. A version that looks newer than stable but is actually a prerelease is very easy to miss, especially for students.

Getting Unstuck

A few things came together over the following weeks:

• The right client. We moved to the 1.2.1 RHC2 build linked from SystemcoreTesting and installed an updated RHC2 IPK on the SystemCore.
• A documented workaround. A comment on RHC2 on Systemcore Dashboard Crashes On Load (attempting to Update A301 Firmware) #330 added exact commands for the workaround. The one that worked for us was the second option, deleting downloads.json. After that, the A301s updated and we haven't seen the issue since.
• Official fixes. On July 28, A301 Alpha 3 #346 shipped updates to RHC2, REVLib, and the A301 firmware and closed out RHC2 on Systemcore Dashboard Crashes On Load (attempting to Update A301 Firmware) #330. Valkyrie is now on REVLib 2027.0.0-alpha-6.

One more thing we noticed along the way: it's unclear whether the MotionCore itself needs firmware updates, and how to do them if it does. For FTC teams, the MotionCore is where every motor plugs in, so a clear answer here would help.

[mray190]

Catching Up, Part 4: An FTC Mecanum Drive on SystemCore (August)

With the A301s finally on current firmware, it was time to put everything on a real FTC robot. This post covers getting a mecanum drive running on SystemCore in late August, and the feedback our students collected along the way.

The Robot

Instead of building a new chassis, we borrowed the rookie camp robot from one of our FTC teams (16311 Recoil). It's a standard FTC mecanum chassis, and we swapped in four A301s with 215 RPM gearboxes. The SystemCore mounts on top, the MotionCore sits underneath, and everything runs off a Milwaukee M18 battery.

By the end of our first session with the robot, the driver's gamepad was controlling all four motors through Valkyrie. It wasn't driving like a mecanum robot yet, because two things were still wrong:

• The gamepad-to-drive mapping wasn't finished.
• One side of the drivetrain wasn't inverted.

Both were quick fixes. By August 27, we had a full mecanum drive moving on the field.

How the Code Came Together

This is where the work from Part 2 paid off. The robot uses the same Mecanum drivetrain class that we wrote in June and tested in simulation. We passed in four A301Controllers and our OnboardIMU gyro, and we didn't have to change a single line of drivetrain code to use the new motors or the SystemCore's IMU. All the vendor-specific code lives in A301Controller.

What We Verified

• Motor inversions and encoder positions on all four wheels
• Translation: forward/backward and strafing
• Rotation
• Field-relative driving, using the SystemCore's OnboardIMU for heading
• Driver input through wpi::Gamepad, via our Gamepad wrapper

IMG_6639.MOV

Lesson learned: Our one real bug was that the wheel positions we passed into Mecanum were in the wrong frame of reference. Valkyrie builds the mecanum kinematics from each wheel's Translation2d, so wrong coordinates mean wrong wheel speeds. If you're setting up WPILib mecanum kinematics for the first time, double-check that your wheel positions use WPILib's robot coordinate system (+X forward, +Y left). That coordinate system will be new to a lot of FTC teams.

Feedback

What we liked:

• The SystemCore web UI.
• IPK packaging. Installing tools like RHC2 as IPKs on the SystemCore makes the workflow much more cross-platform.
• Reliable deploys. So far, we haven't seen any of the SFTP deploy errors we'd occasionally hit on the roboRIO.
• wpi::Gamepad. It unifies controllers, so the same code works with both our Thrustmaster and Logitech controllers.
• The onboard screen. Seeing the SystemCore's IP address right on the device makes connecting much easier.
• Loop timing. We saw fewer CommandScheduler loop overruns than on the roboRIO.

Areas for improvement:

• A301 configuration. There are very few configuration options, especially for PID gains and current limits.
• A301 continuous rotation. The continuous rotation settings are hard to interpret. Here's how we ended up handling it: wrapping the target into ±0.5 turns and using the absolute position setter when continuous rotation is enabled.
• Heat. Our beta SystemCore got extremely hot during use.
• Odometry for FTC. Mecanum doesn't support dead-wheel odometry yet, which is how most competitive FTC teams localize. A WPILib-supported path for dead wheels would make the move to SystemCore much easier for them.

[Gold856]

We merged TwoDeadWheelOdometry (Java, C++) in time for alpha 7, so that should handle your deadwheel odometry concerns. We’d love feedback on those classes!