robototes / chargedup2023 Goto Github PK

As referenced in #21

To quote bobtseattle from #17,

"How will the robot stop from driving off the charge station if another robot partially tips the ramp?
How will the robot handle the possibility of running into the charge station when the other side is down and we are facing a 71.5 degree slope (I am assuming digging our wheels into the carpet will be frowned upon again this year.)?"

Last year we had an automated test which ensured there wasn't a crash on startup, in autonomous, or when disabled. Having that again would be useful, especially at this stage when the project hasn't stabilized yet.

PR for reference: robototes/RapidReact2022#43

Release notes: https://github.com/wpilibsuite/allwpilib/releases/tag/v2023.3.2

Issue referenced in #17, currently the speed modification performed by pressing in the right trigger on the control is hard-coded. It would be better to have a constant or even better some sort of way to config it in shuffleboard.

Last year, I created our autonomous chooser system. Which was nice, and should be replicated this year. However, there are some reasons to believe that just an auto chooser where you just choose the entire auto at once might not cut it. With so many potential paths for the robot to go, there's not many easy ways to predict just how our alliance members are going to code their own paths. The worst thing would be for us to have no path possible because alliance member's paths conflict with ours.

So, we use a "section"-based path switcher this year (name suggestions welcome). Instead of choosing the entire auto all at once, you break the autos up into little sections. Each auto has, say, 3 sections, and instead of picking the auto, you pick which section fits in for the beginning, middle, and end! This way, the drive team can sort of "build" out the path as they are discussing with alliance members.

Here's what's needed for this to be effective:

• Some sort of way to blend the sections together, whether that be having the beginning/middle sections end/start in the same spot, or some other way of getting the robot to the next section
• A visualization of their built path for drive team. Last year I experimented with using this team's library https://github.com/Arctos6135/StdPlug for displaying images in shuffleboard. It might be interesting to try and build my own widget for shuffleboard this year.
• We'll still need a lot of variety in what sections are offered

At the end of the day, this will be a "nice to have" feature. We should focus on getting everything else working before starting on this.

#29 changed the sourceCompatibility and targetCompatibility in build.gradle to Java 17 instead of Java 11. However, on the school laptops, this causes compileJava to fail with "error: invalid source release: 17".

Steering PID needs to be tuned as referenced in #21

Once we have comp bot done

Several things to fix/improve:

• ArmSubsystem.java logs many numeric values as strings (search for "StringPublisher"), which makes it impossible to graph the values without custom post-processing. Instead of writing a string to elbowPositionPublisher with both the rotation & degrees values, either log two separate values ("Elbow Pos Rotations" and "Elbow Pos Degrees"), or just log whatever the code uses (rotations I think).
• robotInit() should log the command initialize / interrupt / finish updates to network tables with StringPublisher in addition to writing it to the console output. That'd make it easy to visualize the command state changes in the same view with other data (like elbow position).
• Look at all the https://github.com/robototes/ChargedUp2023/search?q=System.out.println instances and add Network tables logging for them if they look like something we'd want to view alongside other data in a chart or other view

DrivebaseSubsystem needs to be fixed so that the motors accurately move in sim. Currently, poses can be correctly set, but you cannot drive the robot in teleop nor auto in the simulator because the motors aren't being configured/used correctly in sim. Requires further investigation.

In IntakeSubsystem.java on line 16:

public static final double INTAKE_OUT_SPEED = 0.3;

Later, this value is used on line 72

public void intakeOut() {
		setSpeed(INTAKE_OUT_SPEED);
	}

and line 10 of IntakeSetOutCommand.java

super(intakeSubsystem, INTAKE_OUT_SPEED);

With this code, intaking out with just intake in but at a slower speed. INTAKE_OUT_SPEED needs to be negative

Looking at the logs, the reported 'actual velocity' values are from -223 to 216, but the 'target' values are between exactly -4.420 and 4.420. To make them easily comparable when tuning PIDF, they should report with the same scale

When check is run on the CI, it formats the code. However, this does not affect the repository code (just the local copy for the CI).
As KangarooKoala#1 verified, the check passes despite the code having (and continuing to have) a formatting error (in that case an unused import).

See comments on #52
Key things are:

• Lots of dead code or constants should be removed to reduce confusion to people reading the code
• Arm feedforward is still broken. It's likely the values it's returning are now small enough that they don't matter. So you might try just deleting it entirely & just using PID. Only the middle position (0.415) would have a non-zero feedforward value, and that's close to the top so it would be pretty small.
• isArmNearGoal() uses a very loose definition of 'near', which is great for the SetFullArmCommand (as it can start moving the wrist before the arm is actually at its goal) but bad for autonomous (as the arm is about 30 degrees short of the goal when the auto code moves on to the next thing).

See change list here: https://github.com/wpilibsuite/allwpilib/releases/tag/v2023.4.2. The most important change is an optimization that should improve loop times.

It's getting to be a lot