robototes / rapidreact2022 Goto Github PK

Some good solutions would be either passing around the subsystems class instead or converting the subsystem to static constants so commands can just import the constants class

It might be a good idea to make a competition branch where only stable/tested code goes into to increase stability during competition

git cherrypick could be used to move commits over

@obj-obj - If we move to the Google format standard, it looks like https://github.com/marketplace/actions/google-java-format could be setup as an action to check formatting & block PRs until it's fixed. Does the checked-in eclipse-formatter.xml (used by the VSCode Java formatter) match the Google format rules? If not, can you update it so it does, or recommend another VSCode plugin that school laptops can use to trivially format code?

Would make constants a bit cleaner (like @1198159 said)

• 2 sensors in feeder logic
• Oblog sensor overrides
• Slow down shooting for flywheel
• Refactoring..?

The hardware, subsystems, and control initialization currently happens at process start, which sometimes is before the physical hardware is ready to be used. They should move to robotInit so they don't race with physical hardware setup.

#25 introduced a hardcoded mapping from Joystick 0 to intake behavior. Joystick input should be triggering commands, which then call the subsystem to do stuff. The subsystem shouldn't be directly hooking joysticks, as the joystick -> command mappings should all be in a single file to make it easy to tweak them based on what works best for the drivers.
As written, this also means the joystick is active during autonomous so any hardware drift or inadvertent presses on the joystick will cause the robot to do things.

Currently the CANBus network name for the drivebase and intake is set to "DrivebaseIntake" (see DRIVETRAIN_INTAKE_CAN_BUS_NAME in Hardware.java), regardless of the RobotType defined in Robot.java. This causes CAN errors on the practice bot which does not have a CANivore with a CANBus network of that name.

This is a low priority since we won't be running the practice bot in a time-intensive setting anytime soon, but if we continue using it in the future, we should consider adding a fix for this. Marking this as wontfix until after worlds for clarity.

We should have some sort of anti-tip code that uses the gyro to detect when the robot is falling over, and uses the drivebase to compensate (by driving in the same direction as the tipping) to prevent the robot from falling over. Joseph said there was already some anti-tip code, so maybe we should improve it

The threshold of long-string is be to low, breaks line in unwanted position
for example I have a comment

/*
 * so as mentioned above this subsystem is only for hardware on top of existing hardware
 */

and forcefully change into the following

/*
 * so as mentioned above this subsystem is only for hardware on top of existing
 * hardware
 */

quite unnecessary for the sentence that's two or three words over the threshold
although I could break the sentence in the middle to make it reads smooth even in multiple lines, but a modern 16:9 screen should be able to display a line with 100 characters
Could the formatter be little relax/flexible on the long-string detection?

Add more things to shuffleboard:

• Flywheel power
• Hood angle
• Turret bias
• Distance bias

Command..? To help with this

which one do we use I dont like any of the three options

I'm not on index, but when I used ./gradlew check on my code before committing, it mentioned that some arguments may have been swapped in Subsystems.java when we're initializing indexSubsystem. Looking at the code, it seems that IndexSubsystem expects ingestTopProximity right before the ingest top color inputs, while Subsystems places ingestTopProximity right after the other proximity sensors. There's also a difference in the names of the motors- IndexSubsystem uses firstMotor and secondMotor, while Subsystems/Hardware use ingestIndexMotor and feedIndexMotor- but that shouldn't be a bug.
I just want to bring this to attention, since it may cause severe headaches. If this has already been fixed, or it is not, in fact, a problem, please let me know.

If you're curious, here's gradle's output, excluding the file path (Sorry for the long lines):

warning: [ArgumentSelectionDefectChecker] The following arguments may have been swapped: 'hardware.ingestTopProximity' for formal parameter 'ingestBlueColor', 'hardware.ingestBlueColor' for formal parameter 'ingestRedColor', 'hardware.ingestRedColor' for formal parameter 'feederBlueColor', 'hardware.feederBlueColor' for formal parameter 'feederRedColor', 'hardware.feederRedColor' for formal parameter 'ingestTopProximity'. Either add clarifying `/* paramName= */` comments, or swap the arguments if that is what was intended 
            indexSubsystem = new IndexSubsystem(hardware.ingestIndexMotor, hardware.feederIndexMotor,
                             ^
    (see https://errorprone.info/bugpattern/ArgumentSelectionDefectChecker)
  Did you mean 'hardware.ingestProximity, hardware.feederProximity, /* ingestBlueColor= */hardware.ingestTopProximity,' or 'hardware.ingestProximity, hardware.feederProximity, hardware.ingestBlueColor,'?

• Limelight data filtering
• Manual overrides in oblog
• Collect data points every 10 inches

This would involve fixing the soft limits on the turret, and a lot of testing/improving code to get shooter to the point that it can aim and shoot while the robot is moving. Also an automatic shooting mode should be added, if possible

Another thing that might be useful is slowly rotating the turret when limelight doesn't see anything, in order to lock on to the hub (this would all be disableable by drive team, of course)

Stuff that needs to be tested:

• Shooter/hood/turret hardware works (can turn)
  • Flywheel can reach target speeds and stop
    • Use ShooterFlywheelSetVelocityCommand with various speeds and estimate if hardware speeds are correct
  • Hood can reach target angles
    • Use ShooterHoodSetConstantAngleCommand with various angles and measure hardware angle (of bottom of hood)
  • (Optional) Hood soft limits work
    • Use ShooterHoodSetConstantAngleCommand with invalid angles and make sure hood stops
    • If hood trying to go past limits is too risky, temporarily change soft limits
  • Turret can reach target angles
    • Use ShooterTurretSetAngleCommand with various angles and measure hardware angle
  • Turret software limits work
    • Use ShooterTurretSetAngleCommand with unreachable angles (if present) and make sure turret stops
    • Use ShooterTurretSetAngleCommand with angles which can be reached by turning the other direction and make sure turret does it
• All of the offsets work correctly (do anything and in the correct direction/magnitude)
  • Change turret angle bias, use ShooterTargetCommand, and make sure turret reaches the appropriate angle relative to the hub
  • Change distance bias, use ShooterTargetCommand, and estimate if hood and flywheel have appropriate interpolated values
  • Alternative: Shoot and see if distance changes
• If there's time, tune the offsets to work correct if they don't already work.
• Collect data points for hood angle and flywheel power

• Characterize RR
• Auto on RR
• Anti-tip & update acceleration limiter

Drivebase Teleop (15min) -> TBD
Square Auto (15min) -> TBD
Sensorless Intake (30min) -> TBD
Shooter (60min) -> #81
Climb (45min) -> TBD
Index (30min) -> TBD
Tune Shooter Auto (1 day) -> TBD
Tune Drivebase Auto (1 day) -> TBD
Test Sensor Integration (1 day) -> TBD
Full Auto Basic (1 day) -> TBD

Robot hardware and firmware needs to be updated along the GradleRIO version we're using.

in a few subsystems i see constants that have a ton of variables. For example, in ShooterSubsystem, we could make the P I D constants a PIDCoeffecients object
There should also be a range object that stores a min and max we should use, and if there isnt one ill make one in the utils class.

I did an oopsie and made the file path the image widget uses be absolute. This means it will only load if the file path to the repo is exactly the same as it is on the main driver station laptop. This can be fixed by making it relative (somehow).

Can use the Multiplexed I2C device without the error

Indentation width can be changed per-ide, so people can change the indentation width to whatever they want in their IDE without changing the file itself.

A good explanation is at https://tabsarebetterthanspaces.com/

Since it's just whitespace perhaps discussion for next year?

pregenerating paths might mprove this a little but other causes should be investigated

• Read from two sensors instead of one (to account for misreading or one coming unplugged)
• Have mid-match manual overrides for all sensors so the robot keeps functioning when they fail (e.g. if the sensors are stuck in the 'ball detected' state, have a way to override so the index & intake motors are stuck in the stopped state).
• Filter Limelight data to throw out obvious outliers
• Have mid-match manual override / configuration in case the limelight starts mis-tracking. It's possible to score with the hood, turret & shooter at fixed values. It's nearly impossible to score when they all randomly jump around.
• Cross-check data from multiple sources (e.g. ignore limelight changes if it says we moved an order of magnitude further than the drivebase encoders say we moved)
• Read pneumatic pressure and if it's consistently at or near 0, turn off the compressor to save power since we likely disconnected a tube somewhere

• More auto
• Sensors
• Logging

current drive constants are just copy of 2910s