-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Estimation of hub position after vision is lost #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
e3l
commented
Feb 18, 2022
Co-authored-by: dx44383 <[email protected]>
KEVIN: Closing thoughts. A lot of things made sense when I realized what RamseteCommand and associated WPILib path following things actually did -- given a trajectory, the path following generates a list of left and right velocities for the drivetrain to follow the trajectory. My confusion from the PID oscillation stemmed from the assumption that the PID loop in the command was for position, so an oscillation would surely cause the robot to move back and forth; it never did because the PID loop was for velocity instead (this is why kI and kD were set to 0 in the example; accelerating to a target velocity is a use case for just a P controller). Oscillations due to a high kP were between 1.9m/s and 2.1m/s and not 1.9m and 2.1m so there was no back and forth driving. Furthermore, the confusion on why the robot stopped before the end position when constants were misconfigured can also be explained by realizing that the list of velocities probably ended, with the constants being incorrect leading to the robot not following the velocities properly and ending in an incorrect spot. A lot of these confusions could probably have been resolved sooner had I read the docs for RamseteController a little more carefully. * Initial testing * Add wheel circumference to hopefully calculate distance * Add position getting/setting, fix constants * Slow drive speed, zero sensors * Start odometry threading * Odometry package and class This commit will be overridden by using WPI's builtin odometry classes, but I am pushing it to keep it in history. * Use WPI odometry class * Small changes * navX AHRS * Merge left and right sensor methods to use odometry class * Change `new Pose2d()` to `getRobotPosition()` * Measure the constant! This can be tested and tuned over time * Bind A button to zero position * Change constant to inches, remeasure * Add better documentation * Remove joysticks from encoder branch * Readd odometry thread Wasn't able to test this that much because the drivetrain became possessed by ghosts, but can test next week on the actual drivetrain. * Talon -> Spark Max * Implement preliminary path following command See comment in FollowPathCommand * Remove states from `tankSubsystem` * Inches -> meters * Add secondary constructor to FollowPathCommand * Fix turning direction; remove CAN ID 0 * Edit to functional drivetrain state * Measure some constants Prepared to do https://docs.wpilib.org/en/stable/docs/software/wpilib-tools/robot-characterization/characterization-routine.html#running-the-characterization-routine and measure the rest on Sunday, then perhaps test finally! * Measure more constants! These will probably have to be remeasured with the Robot Characterization tool. When testing pathfinding with these, the robot immediately swerves sharply to the left (which it shouldn't be doing). It might have something to do with the right encoder readings being inverted during characterization (left reports 4 meters, right reports -4), but I've tried setting various options in the config to try and fix that to no avail. Will definitely look into it further at some point. * Revert constants, invert gyro, invert left motors * Fix inverted gyro error in resetPosition * New constants! Recharacterized using process described in https://www.chiefdelphi.com/t/the-future-of-pathweaver/393014/82. `Kp` might need to be tuned, as does `ENCODER_TICKS_TO_METERS` most likely. * Update WPILib and vendor packages to 2022 Also push experimental changes to PID constants and auton testing, which still doesn't quite work * Add preliminary shuffleboard code * Move odometry to `tankSubsystem` With the new REV version, CANSparkMaxes with the same can ID cannot be created (it throws errors which kill the robot program) * Measure new constants with sysid Hopefully these ones work better! * `Field2d`, new constants * Cleanup, remove elevator subsystem * Change angle entry to use a gyro complex widget Co-authored-by: pinkbluesky <[email protected]>
Brownout!
At this point we are using shooter like develop, so even though I haven't reviewed all this code I'm going to merge it. Let's actually use develop hooray. * Recreate shooter branch from refactored Ethan code * Skeleton `shoot()` method, some cleanup * Add hood SparkMax * Remember to add a constant 😳 * PID testing * editing jetson socket so it's using constants instead of bigdata * add networktables * Add Jetson NT testing code * Update NetworkTables data to match vision code * Clean up * editing jetson socket so it's using constants instead of bigdata * Update NetworkTables data to match vision code * Clean up * Add httpcamera for testing camera stream * Update Jetson stuff * Jetson refactoring * Add velocity closed loop testing code * Jetson restructuring, `periodic()` skeleton code * Rename shooter to turret Shooting has been delegated to internals! * Jetson camera wrapper * added elevator and tank implementation * Tank drive code, untested * add elevator config * reviewed added code, default commands added * elevator commands and controller setup * Working tank and elevator subsystems * overhaul subsystem structure + overhaul config file * fix end method in dtcommand * improved handling of elevatorUpIsPositive const * change elevator command structure * put in config txt thing again * Use `WPI_TalonSRX`, `DifferentialDrive` * Use builtin `squareInput` * Add third set of Talons * Remove `DifferentialDrive` * Revert "Add third set of Talons" This reverts commit 1b5ea6d. * add joystick code * Add joystick capability * Add controller switching * code for testing gyro, ecoder, limit switch, and color+distance sensor. Supposed to print values from sensors. Need to import rev library. * sensor testing code * skeleton code for internal subsystem. Includes 2 color sensors, a talon (will replace w/ cim), a method that determines when to activate/deactivate motor based on color. * Merge commit part 2 * Internals refactoring * Initiate InternalSubsystem in RobotContainer * shooter request updates * added a skeleton method for launching ball into shooter * Add `turntableAligned()` for internals * Change initialization to constructor arguments * Skeleton climb code, cleanup * Intake skeleton * Use intake enum, add intake commands * Reformat to 4 spaces Finally, my master plan is complete 😈 In all seriousness, all the new files being created in each branch were all using 4 space indents and the constant refactorings to preserve an unliked indent size inherited from 2 (3?) years ago was getting annoying. 4 space is the future! * Initialize new subsystems in RobotContainer * Fix tank spacing, better comments * added motorport2 constant * added a ballDetected method, updated fields to include another motor, undefined ball count method * Restructure intake position, PID constant splitting * Implement new climb design * updateBallCount * Intake / internals integration * merge * Ball count tracking code * Jetson constants organization, better reject logic * Set up shuffleboard for PID testing * Fix internals motor flow * Use enum for turret mode * got rid of TODOs * Roughly implement the climb plan It's pretty complex. * 775 instead of NEO for turret hood * Update internals with IR sensors * Use command groups for climb * Implement module states for turret This is so that a) drivers know what the status of the shooter is and b) internals can reject quicker (on orange) instead of waiting for a perfectly lined up shot. * Final-ish button bindings * Final rebase commit * `GRTSubsystem` changes, subsystem implementation * Implement driver intake running * Non-conflicting motor ports * New constants, third tank NEO * Turntable blind spot logic, soft limits * Degree conversion constant stubs * Remove mjpg prefix in jetson * Working vision :D * Temporary intake + DT testing code The drivetrain and intake rollers work as expected, but the intake deploy was not moving the motor upwards (despite the percent output being set correctly). I'd advise whoever's testing this tomorrow to see if running the current code and pressing the A button causes the talon to begin blinking green (positive percent output); if it does, then it's a motor issue, otherwise its a code issue (which is weird, because `deploy.get()` seems to say that the deploy controller is indeed being set to the proper percent output). * Replace exit with staging sensor This should work because staging initially stops the ball the moment it detects it (when the top of the ball is at the sensor). While staging still detects the ball (for the entire diameter of the ball as it moves up) we keep spinning the top, and as long as the bottom of the ball is still seen by staging when the top of the ball reaches the turret this code should work. We can repurpose the `shotRequested = false` code which runs when the ball leaves internals to also handle ball count decrementation. * Testing of subsystems, lowered periodic loop times, moved localization to thread * Enforce style * Better `ModuleState` names * Jetson reformatting * Fix internals current drawn method * More subsystem testing and some refactoring * Enforce style again. * Attempt turret `r` and `theta` state system * Bare bones intake testing * Internals color sensor thread * Measure color constants, reduce IO waste * More testing setup * Upgrade to WPILib 2022.3.1 * Update encoder value; comment out internals * Button binding fix, use integrated encoders for DT Also, experimental style changes! Unsure how I like the comma separated declaration, but it is certainly less wordy than repeating `private final JoystickButton` 8 times. * Intake, internals, turret testing - Commented out PowerController (it was causing power drops and stuttering, will test causes and try fixes later) - Bind turntable and hood to mech controller joysticks - Bind left trigger to internals, right to intake - Preliminary internals restructuring to replace I2C onboard color sensor * Boolean state for storage rejection checking * More internals testing * Internals testing part 2 -- dummy shoot method It works half of the time! See slack for details about inconsistencies * Shooter testing - Bind mech y to turn on flywheel, mech b to turn off - Manual override of internals motors on mech triggers Co-authored-by: pinkbluesky <[email protected]> Co-authored-by: unknown <[email protected]> Co-authored-by: eggaskin <[email protected]> Co-authored-by: Ayeeti <[email protected]> Co-authored-by: Ippyb <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.