The alpha drivetrain immediately paid off, as our software team was able to use the CTRE Swerve Generator to generate new constants for this drivetrain. We had swerve code from the preseason ready to be configured, and CTRE’s tooling made it easy to update.
With the alpha drivetrain, we were able to develop the following before CAD was fully done with the robot.
Choreo Trajectories
One of the first steps was to tune the drivetrain closed-loop controllers and set up our Choreo project. Since autos this year are very segmented (i.e., wait for game piece, drive, wait until aligned, score, drive back), we don’t build full auto routines directly as Choreo paths. Instead we define our points of interest and create paths that just go between each* scoring location and each* reef position. Here’s some usage tips for this approach from the Choreo 2025 beta thread. Choreo 2025 Beta – #83 by Amicus1 3. The paths are simple enough that we can test them individually in our workshop and use them in whatever sequence we need.
With this approach and some clean path naming conventions, we created a flexible auto generator. This function in our robot code takes a set of POI enums (each corresponding to a defined Choreo pose variable used in at least one trajectory). With the start position, the intake position, and a list of alignment positions for L4 scoring, our auto generator returns the command sequence to run the given combination. This significantly reduces boilerplate, as our auto options only need one line to define, i.e.
m_autoChooser.addCmd("JKLA_FLEX", () -> flexAuto(POI.STJ, POI.SL3, POI.J, POI.K, POI.L, POI.A));
m_autoChooser.addCmd("HIJKLA_FLEX", () -> flexAuto(POI.STH, POI.SL3, POI.H, POI.I, POI.J, POI.K, POI.L, POI.A));
There are several ways this auto generator can fail before the match (missing trajectories for a given segment, etc). We are looking at ways to run unit tests on the defined auto options to catch any necessary but missing paths.
This work with flexible autonomous sequencing will hopefully prove useful as we coordinate with other teams during events.
PhotonVision
Using some old camera mounts and hardware, we set up PhotonVision as soon as it fully released. We are reusing our Arducam OV9281 and Orange Pi setup this year. With the close and angled tags this year, we expected great performance, and we were not disappointed.
We analyzed the standard deviation of the pose estimation using AdvantageScope. With one tag in view, the tag filled most of the camera frame, and we had an all-but-perfect pose estimate at our scoring location. With two tags in view (two adjacent sides of the reef), the camera pose estimation barely fluctuated a millimeter, and consistency was acceptable even when viewing the reef tags from the coral station. We identified that while it was technically possible to see three reef tags at once, this was inconsistently detected. Anecdotally, it gave accurate measurements when it did happen, but we didn’t have enough consistency to make it worth measuring.
Our tag filtering is fairly straightforward and similar to 2024. We reject estimates that are more than 0.5 meters from the ground plane. We also reject estimates where no used tags are within 15 feet. We then scale our standard deviations according to the average distance to the tags.
We chose to have two cameras facing the reef, so that we could see the reef tag when aligned to the left or right of it. We’re also currently planning to have cameras pointed more upward to observe the coral station and barge tags. Placement of these has not yet been determined.
One idea under evaluation is to give the reef cameras’ PhotonVision instance a field layout ignoring the other field tags, while giving the coral station cameras’ instance a layout ignoring the reef tags. This might help avoid difficulties from the field elements getting knocked out of alignment, but would prevent the coral station cameras from being used to align to the reef, if we needed to score that way.
Dual-Radio Setup
We started having the expected issues with the 2.4 GHz band on our robot radio. We took the time before competition robot build to learn how to run the 6 GHz configuration with a second radio at the driver station. We set it up on the driver station tray with a chopped-up DC wall block for 12V power and a chunk of scrap aluminum under it. We still wanted to preserve the 2.4 GHz access mode for demos or other quick testing. Without intending to restate or contradict VividHosting’s documentation, here’s the process we used to set up the link:
- Configure the robot radio with dip switch 3 ON. Update its firmware (which resets the team number and other settings). Access it at 10.0.1.1 (team number 1) and set the team number, SSID Suffix (ours is “alpha” and “comp”) and passwords for 6 GHz and 2.4 GHz. Save. The radio will now be accessed at 10.TE.AM.1.
- Configure the Access Point. Ours was new, and not configured before. With the robot powered off, connect the Driver Station to the access point over Ethernet, and go to the configuration panel (10.0.1.1). Update the firmware (again, this will clear settings). Access it at 10.0.1.1 and switch it to Access Point mode. Set the same team number, suffix, and 6GHz passkey as used on the robot radio. Save. The radio should now be accessible at 10.TE.AM.4.
- Power the robot back on. It should find the 6GHz access point and connect instead of creating a 2.4 GHz network. If the access point is not found, the 2.4GHz network is still created.
There are some pain points with the current radio system:
- We’ve only had luck with the 10.TE.AM.1 address, not 192.168… or radio.local. This static IP seems to be the most consistent, but changes as the team number gets cleared on every firmware update. This behavior doesn’t appear to be documented anywhere relevant, and we discovered it just by guessing that a factory default might have happened.
- This has been hashed and rehashed many times, but the FCC regulations regarding outdoor use don’t define the terms “indoor” and “outdoor”, which leads to ambiguity regarding radio placement in a garage-like setting.
- The issue with the RIO port and passive PoE described in Team Update 08 is a concern for us, because we expect to run two coprocessors alongside the RIO and the DS tethering port. We had major issues with network switches last year, which were solved in the offseason with the new radio. For now, we’re putting the roboRIO on an AUX port, but this won’t be a long-term solution.
Overall, we’re glad we set up the two-radio arrangement early in the season, so that we could practice with a field-like system and avoid the comms interruptions caused by the 2.4 GHz radio getting throttled.