Team 2910 Code Release 2025

Technical Programming
1

Team 2910 is proud to release the code for our 2025 robot!

IMG_3689
IMG_36891920Ă—2560 674 KB

https://github.com/FRCTeam2910/2025CompetitionRobot-Public

Let us know if you have any questions.

70 Likes
2

The first thing I wanted to look at was your alignment code, and I noticed some stuff that I thought was really neat. I was reading this code.

At first glance, it looks like you’re running a PID controller, with a capped max velocity. But it doesn’t look like you’re doing any profiling. Is this correct? What made you decide against a more aggressive controller, like a trapezoidal profile? Or even an S-curve? Did a regular PID controller “just work” and you didn’t mind no (software) limits on acceleration?

Also, I noticed that you’ve got friction compensation for alignment, but how much of a difference did you see from this?

Another note on the friction compensation: Is there a reason that friction compensation is handled when determining the desired velocity, and not internally when the velocities are applied to the modules, with something like kS?

7 Likes
3
  1. It seems I can’t access the bindings link (in the README file). Would we be allowed to see that?
  2. What is markPunch()? (Looking in the Superstructure folder)
  3. What is your guys’ process for creating the FSM? Is there a group of students per subsystem? If so, how do you all communicate in the final Superstructure?
  4. Why do you guys have two different states for auto and teleop? Is that so you can tune the positions more easily (i.e. there’s different pos’s for each)?
  5. What’s the benefit for using voltage instead of duty cycle? For consistency?
  6. When do you guys use pose-based reef selection over rotation (and vice versa)?
  7. What is the SKEW_COMPENSATION_SCALAR?
  8. Why do you guys convert to robot relative then back to field relative?
  9. Why did you guys decide to separate the arm into three separate folders (i.e. extension, wrist, shoulder) rather than how you did it in 2023?
  10. What benefit was there to use angles for the shoulder and wrist rather than positions? Was it mainly for readability/ease of understanding?
  11. How accurate did you find your vision was/needed to be?
  12. Do you guys change the FieldConstants based on location, or is that not necessary?
  13. From what I can see, you only update your position based on the reef AprilTags. Moreover, you update your position based on the tag you wish to auto align to before moving to that tag. Is that correct? (Btw I like the front and back IDs, very clever)

Sorry for all the questions, y’alls code is just really cool and I would love to know more about it! :sweat_smile:

4 Likes
4

Find it magical to see these numbers
f4e0ee2b701b0877a513fb1970b2e40a

17 Likes
5

How did you guys do replay mode for advantagekit? Isn’t the logic unreachable? Not real means you’re robot type is SIMULATION but you need to have a robot type that isn’t sim to activate replay mode.

6

They also seem to use the regular CTRE drivetrain class, not the AK impl. Plus, they don’t have IO classes for simulated subsystems. I get the idea that they use AK for powerful logging, but don’t do replay. But I could definitely be wrong.

1 Like
7

I thought I heard it in their btb video but I could be wrong. Also, what level of simulation did you guys have? Did you find it useful to test out things before they were fully built?

8

Yea no profiling on the auto alignment. We tried out multiple methods through the season including trapezoidal profiles and dynamic path following and decided that this is what worked for us best.

We had this friction compensation specifically for our auto-alignment code and did not want it used in other cases so we kept it at a higher level.

The friction compensation definitely helped especially when we initiated auto align close to the end goal and prevented us from effectively standing still in those cases.

5 Likes
9

Thank you for all the questions!

  1. It seems I can’t access the bindings link (in the README file). Would we be allowed to see that?

The link should work now.

  1. What is markPunch()? (Looking in the Superstructure folder)

We were experimenting with ways to hit the algae off the mark for our mark auto. We did not end up doing anything with this.

  1. What is your guys’ process for creating the FSM? Is there a group of students per subsystem? If so, how do you all communicate in the final Superstructure?

We had one student working on the arm through the whole season and the other subsystems were pretty quick to put together during bring-up. Then through this process we implemented the superstructure states and methods. During this time we usually had one person actively writing code and the rest of the programming team observing/talking out the logic.

  1. Why do you guys have two different states for auto and teleop? Is that so you can tune the positions more easily (i.e. there’s different pos’s for each)?

Can you clarify what states you are talking about here?

  1. What’s the benefit for using voltage instead of duty cycle? For consistency?

Yea the thinking is that duty cycle can vary if the battery voltage gets lower because of percentage versus voltage targets a specific voltage.

  1. When do you guys use pose-based reef selection over rotation (and vice versa)?

Pose-based is good for if we are doing the front faces of the reef and trying to put up a bunch of coral. Rotation based is good if our strategy involves a lot of field traversal (because our drivetrain pose will slip over time and then we don’t have to rely on it to auto-align and then relocalize).

Basically, pose-based is theoretically always better because the driver does not have to worry about rotation the robot to the right spot but our raw wheel odometry can slip over time if we have not relocalized with vision for some time, in which case we can use rotation-based to trigger our automatic alignment sequence.

In matches if our LEDs are purple we are in pose based and if they are yellow we are in rotation based.

  1. What is the SKEW_COMPENSATION_SCALAR?
  2. Why do you guys convert to robot relative then back to field relative?

Gonna address these together - we have that constant to compensate for robot rotational velocity while translating that causes the robot to drive off center. Assuming for #8 you are talking about chassis speeds, and we do that because it allows us to apply this constant to manipulate the rotation input into the chassis speeds calculation.

  1. Why did you guys decide to separate the arm into three separate folders (i.e. extension, wrist, shoulder) rather than how you did it in 2023?

Cleaner compartmentalization.

  1. What benefit was there to use angles for the shoulder and wrist rather than positions? Was it mainly for readability/ease of understanding?

Easier to understand.

  1. How accurate did you find your vision was/needed to be?

Very accurate when we were in our actual scoring position, but with some margin of error farther out.

  1. Do you guys change the FieldConstants based on location, or is that not necessary?

What location are you talking about?

  1. From what I can see, you only update your position based on the reef AprilTags. Moreover, you update your position based on the tag you wish to auto align to before moving to that tag. Is that correct? (Btw I like the front and back IDs, very clever)

Yup

12 Likes
10

We did not use log replay this year

3 Likes
11

We used simulation but I think this year we did a good job of actually testing out code on past robots. We were able to get our arm code fully running on our 2023 robot before bringup :stuck_out_tongue:

9 Likes
12

Where do you have your CAD files stored here for advantagescope? I’m assuming you do it like most teams do with .jlb files?

13

Great work as always! Thanks for all you guys do for the community by publishing your code every year. I know I can speak for my team when I say we’ve learned a lot from you guys.

5 Likes
14

why don’t you constantly update your wheel odometry with vision?

3 Likes
15

Is there no Pose Estimator class that filters the vision inputs at all? All I see is “resetTranslation” being called on observations from the cameras. Doesn’t this mean the poses the camera is estimating are being fed directly to the swerve subsystem and resetting its pose? Are the estimated poses that good?

3 Likes
16

I think I can ask this question in a better way. My team and I are trying to figure out state machines and advantage scope with state machines specifically simulating so we can create most of our code without a robot during the season. Did you guys use advantage scope to run simulations and create code with or was it all done with a real robot?

17

We used a combination of advantage scope simulations as well as past robots. We did not upload the CAD model to advantage scope.

1 Like
18

Because we don’t really want to reset when we are doing fast traversals, so we just limit our pose resetting to when we are auto-aligning because we get good data during that period of time.

4 Likes
19

Yea there is no pose estimator. We hard reset the swerve odometry to the poses from the camera. The poses are accurate enough for this to work. Part of this accuracy comes from the fact that we only relocalize while auto-scoring, which is a relatively more stable state and thus helps us get more accurate poses.

6 Likes