Build Season Week 4: Update Simulation Code and Push Vision Setup to 'Master'#2
Build Season Week 4: Update Simulation Code and Push Vision Setup to 'Master'#2Kachow2323 merged 41 commits intomasterfrom
Conversation
…e-2026 into test/2026/vision
| private static final double DRIVE_AND_SHOOT_ANGLE_D = 0.4; // experimental value | ||
| private static final double ANGLE_MAX_VELOCITY = 8.0; | ||
| private static final double ANGLE_MAX_ACCELERATION = 20.0; | ||
| private static final double ANGLE_MAX_VELOCITY = 999; |
There was a problem hiding this comment.
Revision: Return to reasonable values
Units: Rad/Sec
| private static final double ANGLE_MAX_VELOCITY = 8.0; | ||
| private static final double ANGLE_MAX_ACCELERATION = 20.0; | ||
| private static final double ANGLE_MAX_VELOCITY = 999; | ||
| private static final double ANGLE_MAX_ACCELERATION = 999; |
There was a problem hiding this comment.
Revision: Return to reasonable values
Units: Rad/Sec^2
| 0.0, | ||
| ANGLE_KD, | ||
| new TrapezoidProfile.Constraints(ANGLE_MAX_VELOCITY, ANGLE_MAX_ACCELERATION)); | ||
| PIDController angleController = new PIDController(5, 0.0, 0.0); // Broken atm |
There was a problem hiding this comment.
Revision: Tune this kP parameter
There was a problem hiding this comment.
On my branch there is tuned values for the pidController (fuelJosh)
| // .beforeStarting(() -> angleController.reset(drive.getRotation().getRadians())); | ||
| // } | ||
|
|
||
| public static Command joystickDriveAndShootHub( |
There was a problem hiding this comment.
Revision: Unused Command, Rm post-merge
|
|
||
| public static enum FlywheelIOOutputMode { | ||
| COAST, | ||
| DUTY_CYCLE_BANG_BANG, |
There was a problem hiding this comment.
Revisiting Flywheel Implementation Concepts:
Knowns: System with X (2) DC motors with a spinning mass that has non-negligible inertia.
Voltage Compensation: Current Spikes result in downturn of Nominal Voltage:
Thus, use normalized voltage relative to the powered rail
Vnew = Vcmd (Vnominal/Vrail)
Note: Reciprocal can also work (even possibly better): Vnew = Vcmd (Vrail/Vnominal)
PID Controversy:
In typical postional control, large values of Kp can lead to overshoot and Kd is commonly used to reduce overshoots.
But does Kd in Velocity control provide sufficient damping of Kp?
PID is 1st and 2nd Order Control Loops, which gives it 3 degrees of freedom
Kp and Kd for target acquisition, kI for steady-state error removal
"With higher order systems like a one input, seven state system, there aren’t enough degrees of freedom to place the system’s poles in desired locations. This will result in poor control."
Why?
Math in the PID doesn't factor in Motors or Voltage.
Meaningfully only figures out the intergral and derivative of the original input/setpoint
But since we are using Motors, which are 2nd order, PID can work out.
Note: V = kP(angular rotation setpoint - current angular rotation)
Thus, kD is often unnecessary in Flywheel control.
It may be used to compensate for accelerating projectiles slowing down the flywheel at the cost of recovery time.
"Kd drives the acceleration to zero in the undesired case of negative acceleration as well as well as the actually desired case of positive acceleration"
Derived from 6328's Flywheel IO's:
| double atanParam = deltaY / deltaX; | ||
|
|
||
| if (isRedAlliance()) { | ||
| angleToTargetRad = Math.atan(atanParam) - Math.PI + (Math.PI / 2); // Testing: + (Math.PI / 2) |
There was a problem hiding this comment.
Revision: Angular Offset to be removed on Competition Robot.
| if (isRedAlliance()) { | ||
| angleToTargetRad = Math.atan(atanParam) - Math.PI + (Math.PI / 2); // Testing: + (Math.PI / 2) | ||
| } else { | ||
| angleToTargetRad = Math.atan(atanParam) - (Math.PI / 2); // Testing: + (Math.PI / 2) |
There was a problem hiding this comment.
Revision: Angular Offset to be removed on Competition Robot.
| @Override | ||
| public void periodic() { | ||
| robotPose = swerveSubsystem.getPose(); | ||
| updateTargetByAlliance(); |
There was a problem hiding this comment.
Revision: Optimize this function to reduce jitter in Periodic block.
| targetLocation = new Pose3d(blueHubTarget, new Rotation3d()); | ||
| } | ||
| } else { | ||
| targetLocation = new Pose3d(blueHubTarget, new Rotation3d()); |
There was a problem hiding this comment.
Note: Required field. Robot Init doesn't like targetLocation to initialized as blank.
| public class SwerveConstants { | ||
| public static final double maxSpeedMetersPerSec = 5.74; // <- Check | ||
| public static final double odometryFrequency = 50.0; // Hz, tune | ||
| public static final double odometryFrequency = 250; // Hz, Test faster than periodic block timing |
There was a problem hiding this comment.
Note: To be tested for consistency boost. Higher sampling rates have been quoted for reducing standard deviation error in odometry-restricted autonomous pathing like PathPlanner routes without vision-estimate corrections. Does not affect accuracy (Mean Error).
| private SwerveDrivePoseEstimator poseEstimator = | ||
| new SwerveDrivePoseEstimator(kinematics, rawGyroRotation, lastModulePositions, Pose2d.kZero); | ||
|
|
||
| boolean isFlipped = |
There was a problem hiding this comment.
Note: Critical patch that fixes MT2 measurements. Tested on Red DS Hub Tags (9, 10).
There was a problem hiding this comment.
Additionally, this also corrects for Gyro-Flipping used in JoyStickDrive after strict trust factors were enabled on all Vision-Pose estimates (MT1 and MT2). Prior to this patch, we were unaware that our trust factors for angular measurements were being bypassed and accepted into the addVisionMeasurement queue. This caused the robot to correct for the unhandled Alliance Flip which we assumed was already handled in the SwerveSubsystem.
| @@ -0,0 +1,82 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
| @@ -0,0 +1,116 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
| @@ -0,0 +1,10 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
| @@ -0,0 +1,15 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
| @@ -0,0 +1,30 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
| @@ -0,0 +1,51 @@ | |||
| package frc.robot.subsystems.vision.rewrite; | |||
There was a problem hiding this comment.
Revision: RM Post-Merge
|
|
||
| @Override | ||
| public void periodicAfterScheduler() { | ||
| System.gc(); |
There was a problem hiding this comment.
Note: Seems to solve initial crashing errors seen in Week 2 of Build Season. No issues so far.
| import java.util.function.Supplier; | ||
| import org.littletonrobotics.junction.Logger; | ||
|
|
||
| public class FuelSim { |
There was a problem hiding this comment.
Note: Wholesale Import from FRC 5000
| * Generates a rough estimate of the time it will take for a projectile to reach a target. This helps seed the | ||
| * iterative calculation of the effective target location. | ||
| */ | ||
| public static double getCrappyTimeToShoot(Pose2d robotPose, Pose3d targetPose) { |
There was a problem hiding this comment.
Revision: Rm Post-Merge
| Pose3d robotPose, | ||
| Pose3d targetPose, | ||
| ChassisSpeeds fieldRelRobotVelocity, | ||
| ChassisAccelerations fieldRelRobotAcceleration, |
There was a problem hiding this comment.
Revision: Initial testing shows that Acceleration Compensation may not be needed and is likely the source of over-compensation.
| import edu.wpi.first.math.geometry.Translation3d; | ||
| import edu.wpi.first.math.interpolation.InterpolatingDoubleTreeMap; | ||
|
|
||
| public class ShootOnTheFlyConstants { |
There was a problem hiding this comment.
Note: FuelSim shows that based on input Velocity and the Angle, these parameters look promising.
Vision
Fuel and Shooter Simulation
SOTF Shot Calculation