Add Phoenix Pro features #6
Conversation
src/main/java/org/team1540/robot2024/subsystems/drive/ModuleIOSim.java
Outdated
Show resolved
Hide resolved
src/main/java/org/team1540/robot2024/subsystems/drive/ModuleIOTalonFX.java
Show resolved
Hide resolved
src/main/java/org/team1540/robot2024/subsystems/drive/ModuleIOTalonFX.java
Show resolved
Hide resolved
src/main/java/org/team1540/robot2024/util/PhoenixTimeSyncSignalRefresher.java
Outdated
Show resolved
Hide resolved
src/main/java/org/team1540/robot2024/util/PhoenixTimeSyncSignalRefresher.java
Outdated
Show resolved
Hide resolved
| public static void refreshSignals() { | ||
| if (Timer.getFPGATimestamp() - lastRefreshTimestamp < Constants.LOOP_PERIOD_SECS) return; | ||
| lastRefreshTimestamp = Timer.getFPGATimestamp(); | ||
| if (isCANFD) BaseStatusSignal.waitForAll(0.01, signals); |
There was a problem hiding this comment.
Does this wait for them to send after calling, wait for an update since last time you checked, or prompt them to respond?
If the first or third (I can't find it in a cursory search of the phoenix docs), waiting up to half the loop time might be a little long
There was a problem hiding this comment.
It is the second one, however I can see how this can cause problems, especially since the signals only refresh every 0.01s, so you could still end up waiting 0.01s every time if your main robot loop and the status signal refresh loop are synced in just the right way (Status signals refresh just before waitForAll() is called, causing it to wait close to the full 0.01s before recieving an update).
This is pretty easily fixed by just increasing odometry signals to 250hz. Alternatively, I could just reduce the timeout threshold here, but then we would sometimes use stale data (and would probably be better off not using timesync). An even more scuffed way to do this would to put all of the waitForAll()s on a separate thread like is done here.
…, and error checking
mimizh2418
dismissed
rutmanz’s stale review
Review is stale, code has been considerably changed
src/main/java/org/team1540/robot2024/subsystems/drive/ModuleIOTalonFX.java
Show resolved
Hide resolved
src/main/java/org/team1540/robot2024/util/PhoenixTimeSyncSignalRefresher.java
Outdated
Show resolved
Hide resolved
* feat: use SwerveDrivePoseEstimator for odometry tracking * stop using scuffed AdvantageKit Twist2d way * feat: AprilTag vision IO and implementation for Limelight * feat: AprilTagVision subsystem * feat: fuse vision poses with drivetrain poses * fix: null vision poses no longer causing issues * fix: actually fix null vision poses * feat: limelight positioning adjusts based on elevator height * fix: properly update rear camera tag poses * feat: block vision updates with moving elevator * fix: correctly pass in suppliers * im dumb lol * fix: use optionals for getting vision pose * feat: change how vision pose accepter is used * we can now change the code to filter out input from a single camera if the elevator is moving, instead of all cameras * feat: untested vision sim io with photonvision sim support * fix: use vision pose in sim * fix: sim values as constants * refactor: remove unnecessary IO input * refactor: april tag layout declared in sim io instead of constants * fix: correctly check robot rotational velocity
Adds CANivore timesync and Fused CANCoder (still needs to be tested on actual robot)