Integration Status Updates

[aidnem]

Rather than create tickets for integrating each subsystem (which I think might get a bit cumbersome), I'm going to try posting integration status updates here. If we start integrating a subsystem, we can make a ticket -> branch -> PR for that one, but I think creating them all up front will just cause extra paperwork if we do multiple at once.

Current Status

• Hood : closed-loop tuned, works pretty well. Homing sequence also works. Closed-loop could potentially be faster.
• Spindexer/"Hopper" : Closed-loop tuned.
• Intake: Pivot & roller closed-loop tuned. Pivot may need a static negative voltage while intaking to keep it pressed down hard enough to intake a ton of fuel at once.
• Climb : PID was tuned,and bang bang controller works well enough.
• Balltower/"Indexer": It spins up to speed when commanded with closed loop.
• Turret: PIDs are tuned. However, we still see significant jitter. This is potentially vision.
• Shooter (flywheels): PIDs are tuned & a decent first-attempt shot map for hub is in place.
• Vision??? - Global pose looks good but it seems like one camera is slightly offset from the others or something. We're seeing some pose jitter.
• Stationary shooting: We can pretty much make all stationary shots, but sometimes mechanisms aren't perfectly satisfied that they're aimed correctly.
• Shoot on the move: 3/3 we made like 3 shoot-on-the-move shots but had to deal with other issues. It seems like the code infrastructure is decent for it to work.
  It seemed better on the branch for Calculate mechanism delay more properly and actually let us shoot during shoot on the move #95.

Work Remaining

Subsystems:

Coordination

• real autos (probably Thursday)

Also: we need to test red vs. blue stuff since a couple things are currently hardcoded for red side.

[godmar]

Thanks for the update. I'm a bit concerned about multiple things:

• Who is actually reading this post. Everyone should have "All notifications" turned on.

• The status of various gains, ids, targets etc. in .json files. Ideally, tuned gains should only spend very little time in an integration branch and then be shared via main. Merging conflicts with differing constants is prone to errors. Should we add a UI in settings_guid to retrieve current constants and write them to the configuration file? Or have shell scripts? How often do we expect to be repeating the tuning process this season?

• The status of the elastic tuning.json file. This is a JSON, and hard to merge. It can be handmerged, though, but -> avoid this if possible by never forking it across two different git branches. Ideally the tuning layout should stabilize really soon.

[aidnem]

Who is actually reading this post. Everyone should have "All notifications" turned on.

We can & should have a conversation about shop tonight about A) turning on notifications and B) actually checking those notifications if you believe this an issue.

The status of various gains, ids, targets etc. in .json files. Ideally, tuned gains should only spend very little time in an integration branch and then be shared via main. Merging conflicts with differing constants is prone to errors. Should we add a UI in settings_guid to retrieve current constants and write them to the configuration file? Or have shell scripts? How often do we expect to be repeating the tuning process this season?

Yes, this settings UI would likely be helpful. It would effectively take the place of curling the constants back down from the robot, right? However, I don't think this really protects us from merging the wrong gains in merge conflicts, as we can't trust that the last person to deploy deployed the right code.

The status of the elastic tuning.json file. This is a JSON, and hard to merge. It can be handmerged, though, but -> avoid this if possible by never forking it across two different git branches. Ideally the tuning layout should stabilize really soon.

I believe that, aside from missing the climb layout, it is pretty much stable. I think the climber branch should have the climb layout added and then it should be "finalized" and we should only ever accept that version of it when handling conflicts.

[aidnem]

Plan for 3/6/2026 3/7/2026 3/9/2026

Today we have to do some proper integration (transfer rollers, changing turret gearing, auto stuff) and then, if we have time, make ourselves much better scorers:

• - Re-zero drive encoders (the back right magnet was unglued and the front left module sort of exploded 🤦 )
• - Test the turret gear ratio change; make sure the turret can actually aim at the hub; probably bump vision std devs up until it doesn't jitter/push field elements around/cover 2/3 cameras if needed
• - test & tune climber bang-bang controller to see if it can climb more reliably and merge
• - Integrate transfer rollers and
• merge transfer rollers
• - Get 1 person to begin work on an autonomous climb command (should be ~10 minute task if we're skillful)
• - If nathan's auto stuff is ready to test, merge main into it and test it. The auto climb stuff should be able to go onto this branch if we get the climber to work.
• - Add spindexer dejam routine and make it wiggle while idle to keep fuel agitated; imo the biggest enemy to our BPS right now is that we can't actually start indexing when we want to
• - Tune spindexer and uptake to hit max speed; probably use shooter closed loop mode to just dump balls out while testing this to try for high bps
• Test if the CANdi can home subsystems correctly.
• - test where on the field the robot can shoot accurately; retune shot map as needed; test shoot on the move. Use branch for Calculate mechanism delay more properly and actually let us shoot during shoot on the move #95 for this one. Status update 3-7: We're up to 4.3m, we still need to tune the remaining points in the map so that we can shoot from as far away as possible.
• Tune a shot map for passing/slightly rewrite the passing code to just reuse the hub shot map somehow
• Make a real auto and get it to actually work. This needs to be ready to test on monday.
• Driver practice - This one is a non-negotiable; at some point we have to give up on all the other stuff and do this instead. It's better to drive a mid-tier robot well than a great robot horribly.
• - Work on fixing more cycle time issues/adding featureflags for debug-only logging fields and such

[godmar]

I'm somewhat concerned about the jiggle we experience with our vision (that causes the turret to constantly adjust).
Should we debug this before shotmap tuning?

In particular, if the robot's position is unstable with just one camera looking at the two hub april tags, we may have a problem. (I think that irregularities in how the field is built may explain variance when using multiple cameras.)

[PChild]

We need to add the CANdi at some point and validate homing behaviors. Josh tested the button and CANdi settings already on the test chassis, should be quick to do today if you all want.

[aidnem]

Sure.

[aidnem]

Update 3-9

We finally had driver practice! Unfortunately, we weren't very fast or efficient at picking up fuel and passing it to our side of the field. I believe that this can be solved by giving us less strict thresholds for passing than for shooting at the hub. We should also block off our field so that less fuel become inaccessible by getting stuck on stuff like the ladder and the old robots.

We also need to get better at the hub:

• Fix what I can only assume was a bad pose estimate caused by crossing over the bump
• Don't trust shoot on the move so much while very far away
• Shot map seems to be a little bit undertuned when very far away; try just artificially bumping RPM by ~25-50 when over 4.7m away.

[aidnem]

Update after shop 3-10

We tested the CANdi, and it works marvellously. I wish we had LEDs to indicate homing state but that's still waiting on a connectorX update.

We improved the intake, and it can now pick up fuel quite well. It could still be made much better with a roof/deflector.

We did a lot of testing while going over the bump; our vision seems to recover quickly so this likely wasn't as much of an issue as we thought. In my opinion, our biggest priority should be increasing indexer speed and then driver practice. We're indexing pretty slowly right now.

Still needs to be done:

• Index faster
• Much more driver practice
• Test out artificially bumping up the shot map RPMs from far away so that we sink more shots

[godmar]

When flying over the bump, what made the swerve module wheel turn perpendicular and rip up the carpet?
Do we need to worry about not ripping up the carpet at the competition?

[aidnem]

I believe it was because I let go of the drive stick while in the air, so the wheel landed while not spinning (and probably also braking).
I don't think we need to worry about ripping it up, because when I tried keeping the stick held down the same amount throughout the course of the air-time, it didn't seem to tear the carpet or cause any stutter on landing.

[aidnem]

Looking at the graph, it might be valuable to get rid of the point at 1.69 meters, it seems to have a bad measurement for time of flight:

[aidnem]

https://frc-staging-events.firstinspires.org/2026/VAGLE/practice

[aidnem]

Update 3/21/2026

Today at shop we:

• massively improved intake with a hold-down voltage
• Played around with an improved spindexer
• Fixed spindexer oscillation by coasting it when goal velocity is zero
• Tuned shooter using voltage (seemed to produce better results/was easier to tune)
• Tried new flywheels, switched back to the old ones, as the new light ones were super inconsistent
• Tested a path-planner based auto which drove at full speed into the trench wall :(

TLDR: We're better/faster at indexing and shooting than before, and still don't have a good solution for autos.

[aidnem]

Plan for 3/23/2026

• Verify that all cameras have multitag pose estimation enabled in PhotonVision
• Test/improve shot map points in the corner so that we can reliably shoot from there (this might include speeding up the turret for better shoot on the move performance)
• Turn hood max angle back up and see if we can pass/what changes need to be made to passing (hopefully our new intake aids our throughput enough for passing to become viable)
• Run autos

[aidnem]

@godmar Do you have any changes to suggest here? Do we want to update AdvantageKit and PhotonVision to the latest release today as well?

[godmar]

Not unless there's a bug fix to pick up. Unfortunately upgrading photonvision also requires a coppercore update

[godmar]

Look like akit fixed a bug affecting log replay of Unit measures 4days ago

[godmar]

And photonvision fixed a bug affecting teams with 3digit team numbers (!!!). Maybe we will have to update.