robototes / crescendo2024 Goto Github PK

Seems at least like a perf issue, and perhaps a crash if the drivebase subsystem isn't enabled.

See #40 (comment)

I was looking at lots trying to diagnose an issue with the launcher being unexpectedly told to quickly slow down (causing a temperature spike), but can't tell which commands are being run since several use the same generic names "RunCommand" and "ParallelRaceGroup". This should be simply fixable by appending .withName(), such as:

driveController.rightStick().onTrue(new InstantCommand(s.drivebaseSubsystem::toggleXWheels).withName("ToggleXWheels"));

or

Commands.race(new RumbleCommand(controls), new WaitCommand(1)).withName("SetAngleLaunchCompletedRumble").schedule();

The flywheel measured velocity shows the classical underdamped PID control response (example on page 20 of https://file.tavsys.net/control/controls-engineering-in-frc.pdf )

Here's an example from a log from today:

The dip just after time 357s is likely when the note was launched, as the flywheel soon transitions to coast mode.

Notably, this fixes the crash bug reported here (also posted in teams).

(We didn't encounter this bug because we avoided updating to the buggy version previously).

When the flywheel is first commanded to spin up after it's coasting down to the idle or stop speed, the motor is commanded to slow down and then speed back up, which generates heat & wastes battery. That seems to particularly impact the bottom flywheel, which spikes three degrees in this instance:

Was occupied while I worked on #39

Probably low priority, since (hopefully) we won't have to run in competition with subsystems disabled.

Sample intake disabled stacktrace:

Error at java.base/java.util.Objects.requireNonNull(Objects.java:233): Unhandled exception: java.lang.NullPointerException: Parameter requirement in method addRequirements was null when it should not have been!  Check the stacktrace to find the responsible line of code - usually, it is the first line of user-written code indicated in the stacktrace.  Make sure all objects passed to the method in question were properly initialized - note that this may not be obvious if it is being called under dynamically-changing conditions!  Please do not seek additional technical assistance without doing this first!
        at java.base/java.util.Objects.requireNonNull(Objects.java:233)
        at edu.wpi.first.util.ErrorMessages.requireNonNullParam(ErrorMessages.java:27)
        at edu.wpi.first.wpilibj2.command.Command.addRequirements(Command.java:92)
        at frc.team2412.robot.commands.intake.IntakeStopCommand.<init>(IntakeStopCommand.java:11)
        at frc.team2412.robot.util.AutoLogic.registerCommands(AutoLogic.java:54)
        at frc.team2412.robot.util.AutoLogic.<init>(AutoLogic.java:46)
        at frc.team2412.robot.Robot.robotInit(Robot.java:86)
        at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:107)
        at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:365)
        at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:433)
        at java.base/java.lang.Thread.run(Thread.java:833)

Sample launcher disabled stacktrace:

Error at java.base/java.util.Objects.requireNonNull(Objects.java:233): Unhandled exception: java.lang.NullPointerException: Parameter requirement in method addRequirements was null when it should not have been!  Check the stacktrace to find the responsible line of code - usually, it is the first line of user-written code indicated in the stacktrace.  Make sure all objects passed to the method in question were properly initialized - note that this may not be obvious if it is being called under dynamically-changing conditions!  Please do not seek additional technical assistance without doing this first!
        at java.base/java.util.Objects.requireNonNull(Objects.java:233)
        at edu.wpi.first.util.ErrorMessages.requireNonNullParam(ErrorMessages.java:27)
        at edu.wpi.first.wpilibj2.command.Command.addRequirements(Command.java:92)
        at frc.team2412.robot.commands.launcher.FullTargetCommand.<init>(FullTargetCommand.java:43)
        at frc.team2412.robot.util.AutoLogic.registerCommands(AutoLogic.java:59)
        at frc.team2412.robot.util.AutoLogic.<init>(AutoLogic.java:46)
        at frc.team2412.robot.Robot.robotInit(Robot.java:86)
        at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:107)
        at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:365)
        at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:433)
        at java.base/java.lang.Thread.run(Thread.java:833)

Sample drivebase disabled stacktrace:

Error at frc.team2412.robot.commands.launcher.FullTargetCommand.<init>(FullTargetCommand.java:41): Unhandled exception: java.lang.NullPointerException: Cannot invoke "frc.team2412.robot.subsystems.DrivebaseSubsystem.rotateToAngle(java.util.function.Supplier, boolean)" because "drivebaseSubsystem" is null
        at frc.team2412.robot.commands.launcher.FullTargetCommand.<init>(FullTargetCommand.java:41)
        at frc.team2412.robot.util.AutoLogic.registerCommands(AutoLogic.java:59)
        at frc.team2412.robot.util.AutoLogic.<init>(AutoLogic.java:46)
        at frc.team2412.robot.Robot.robotInit(Robot.java:86)
        at edu.wpi.first.wpilibj.TimedRobot.startCompetition(TimedRobot.java:107)
        at edu.wpi.first.wpilibj.RobotBase.runRobot(RobotBase.java:365)
        at edu.wpi.first.wpilibj.RobotBase.lambda$startRobot$0(RobotBase.java:433)
        at java.base/java.lang.Thread.run(Thread.java:833)

During drive practice this week, they noticed that when the robot was commanded to only rotate, it'd also start moving laterally a bit rather than turning in place.
Looking at a log from today at about 632.1s I noticed that the measured states were 30-50% larger than the desired speed - and were about 10% different from each other

When LauncherSubsystem is enabled and run in simulation a null error results

Error at frc.team2412.robot.subsystems.LauncherSubsystem.getAngle(LauncherSubsystem.java:119): Unhandled exception: java.lang.NullPointerException: Cannot invoke "com.revrobotics.SparkAbsoluteEncoder.getPosition()" because "this.launcherAngleEncoder" is null

The issue is in line 50 of LauncherSubsystem .add("Launcher angle", getAngle())
The encoder is not yet initialized when getAngle() is called

During drive practice this week, sometimes notes held in the launcher will spontaneously launch out of the robot. It seems to happen more frequently with non-orange notes, but also happens with orange notes. Mech is looking for a 2nd feeder sensor to wire to another DIO port, but it'd be good to also look into code changes to make feeder/launcher tolerate the sensor losing note detection for a "brief" time once a note is being held.

• Update drive station laptops to use 2024 WPILib tools, not just the beta (to avoid the "Would you like to import this project into 2024?" popups) if we haven't done that already
• Update Crescendo2024 to use the latest version of WPILib

Include yet more network tables performance improvements with Shuffleboard (among many other things)

Should use setFF and getFF here to enable easy tweaking of the feedforward gain constant:
https://github.com/robototes/Crescendo2024/blame/e5d2fd6a6d25049a37705ddc76b2a92b5178fcd9/src/main/java/frc/team2412/robot/util/SparkPIDWidget.java#L24

See LauncherSubsystem - the parameters are listed as Ks, Kv, and Ka, but are actually Ks, Kg, and Kv in the docs.

We've seen ChoreoLib breaking builds on school laptops because it is hosted on github.io, which the school district blocks. Since we're not using it anywhere it's best to delete it.

Docs: https://codedocs.revrobotics.com/java/com/revrobotics/cansparkbase#getMotorTemperature()

Currently the launcher motors are inside the flywheels, which may make them overheat (and the intake motors have already been overheating). It would be good to log the temperature so we have an easy way to check that.

@jbko6 - looking at the wpilog logs from E9 match at Glacier Peak, I noticed the "NT\Shuffleboard\Match\Selected auto\Robot" values keep cycling even after the match started. Can you see how to stop those once the robot is enabled, to save some CPU time and memory on the Rio?

This is used to log all data sent over Networktables for future analysis. During competition, we'll routinely copy the log files from the robot and upload them to Teams. Here's a link to the logs from Worlds last year (the log files this issue is referring to end in WPILOG, and can be opened with AdvantageScope).

Example from last year
WPILib docs