broncbotz3481 / yagsl-example Goto Github PK

When stationary the steering motors like to perform burnouts.

When the drive motors are inverted for a Falcon/Falcon/CANCoder setup the odometry is completely reversed as if the sensor readings are not setting inversion states. If this is the case inversion needs to be changed to a psuedo-inverrsion or sensor readings need to be corrected.

While the current version of the method has trustworthiness, it would be beneficial if a completely custom set of standard deviations could be supplied. We are calculating these values in a custom way based on having both photonvision and limelight, and it would be useful to have the ability to pass in these custom standard deviations.

Store previous commands reference points in SwerveModule and SwerveDrive do not send a new request if they are identical. Example of this is here.

https://github.com/Team254/FRC-2020-Public/blob/master/src/main/java/com/team254/lib/drivers/LazyTalonFX.java

Sometimes swerve motors fail to configure the first time around, should check and output an error and repeat X number of times.

X refers to front in module locations and Y refers to left. Should we rename this to front and left respectively to make it less confusing?

This would be a breaking change but it could be worth it.

Currently Falcon angle motors are not being set correctly. The branch talonfx is being developed to support this.

The lockPose() method does not work because it commands module states that have a speed of 0. In the setModuleStates() method, there are a few lines put into place to stop angle movement when speeds are less than 0.1.

Since the lines that stop module angular movement are useful in stopping excessive module movement in place, the lockPose() function should probably be updated, possibly using an overload with setModuleStates().

https://github.com/BroncBotz3481/YAGSL-Example/tree/51-lockpose-not-working is the linked branch for the issue.

• Rearrange code into single package.
• Separate SwerveDrive, SwerveModule, and SwerveController configuration options from Constants.
• Adopt store configuration at construction style instead of global referencing.
• Implement SwerveMotor augmentation for SwerveModule.
• Implement AbsoluteEncoder augmentation for SwerveModule.
• Separate SwerveModule constants from SwerveMotor constants.
• Add on state-space estimation.
• Move helper functions into SwerveMath.
• Document every function.
• Separate functions into correct units.
• Extrapolate calculated constants into Configuration classes for SwerveDrive, SwerveModule, and SwerveMotor.
• Add support for integrated absolute encoders.
• Add support for defining PID output ranges.
• Switch Odometry to SwervePoseEstimator.
• Make certain configs optional (maybe)
• Write documentation for JSON.

https://www.chiefdelphi.com/t/yet-another-generic-swerve-library-yagsl-beta/425148/159
https://www.chiefdelphi.com/t/yet-another-generic-swerve-library-yagsl-beta/425148/117
Appear to have issues with what is believed to be the cancoder sync.

Possible causes of issues:

• getAbsolutePosition() not being constrained to (0, 360) because of the offset
• the synchronizeEncoders() is placed in the periodic updateOdometry() which means a lack of causality with setReference(). Because of the PID loop running on the motor, with the setpoint derived from the past motor measurements and a new measurement, this could cause some unexpected temporary behavior.

It also could be easier to implement a Steer and Drive Controller to wrap the absolute encoder like democat's swervelib. This would match what they do, which is known to work.

fscalar in the JSON config is ks and following some normalized documentation should be preferred.

Deferring to @7910f6ba7ee4 since this is a major design change to a function used by them (and apparently all other falcon teams).

Add enum to select kinematics to SwerveDrive constructor and abstract kinematics to select which one to use.
Steps:

• Remove 2nd order kinematics
• Add first order kinematics
• Abstract first order kinematics
• Implement 2nd order kinematics
• Add enum to select which kinematics to use.

X mode is where the modules go into 45 degree angles making it immobile which could be useful for protecting against defense.

Looks pretty good!

Within reason sensor data is not updated as often as we query it. Therefore if sensor data is queries within a timeframe we return the cached data. Caching would occur in Abstracted classes and result in lower CANBus usage. Possible method of doing this would be creating a counter in SwerveDriveTelemetry.

just neos and falcons

There are a few issues with the v2 Json Generator as it stands with the current version of the library

In all instances of 'absoluteEncoderOffset', there is a typo that generates the json as 'absolueEncoderOffset' (missing the t in absolute)

In module properties, the json entry 'freespeedrpm' doesn't exist, can only be 'angleMotorFreeSpeedRPM' according to the build error when I try to build

In all modules, when inverting, it prepends the module name (frontleft, backright, etc) to the angle or motor line, reading backleftangle. The build error indicates the only acceptable fields to be angle and drive, so the frontleft, etc need to be removed. I didn't test to see if it worked with encoders being inverted, but it didn't say that they were an option when I was viewing the stacktrace.

And thats all I noticed with my program. Don't have a robot to test on now, but when I made these three changes to my json files, it built and ran a simulation!

• Update builder
• Create SwerveAbsoluteEncoder wrapper.

Try measuring your wheel diameter, it may be smaller than you think :)

hi, I'm having an issue where when I start Telyop using the example with all falcons one motor just drives at max speed and when I do autonomous autonomous program goes through and then at the end of it, one motor drives at max speed I've tried unplugging the motor that was driving at max speed and then it just switch to the next drive motor, I've also tried choosing different field configurations like closed field oriented in such get nothing. Any help would be greatly appreciated because I really really like this project.

• Fix Telemtry to write to their own tabs for each module.
• Use NT4.
• Remove redundancies in doumentation

I think this is already known, but the modules will over optimize the angle, flipping back and forth.

Modules should be able to override the following settings.

• Encoder pulse per revolution.
• Free speed RPM.

SwerveController currently publishes to SmartDashboard no matter the config option.

Track the desired position of the robot and control the heading exclusively by that.

Inspired from
https://github.com/CrossTheRoadElec/SwerveDriveExample/blob/618d5f69798abc947936e8782861c3c3cbdfee85/src/main/java/frc/robot/CTRSwerve/CTRSwerveDrivetrain.java#LL79C1-L80C1

This says it'll break if it's updated too often. How often is too often?

Credit to @7910f6ba7ee4 for already proving it works!

Rotation2d needs to store the original unoptimized angle it was instantiated with to determine the given angle from the absolute encoders

(note: This will NEVER work with thrifty encoders or those which cant exceed 360deg)

Presently, swervelib has several modules that call Robot.getInstance().addPeriodic() to set up periodic operations:

• SwerveModule.java
• encoders/PWMAnalogEncoder.java
• encoders/PWMDutyCycleEncoder.java

The use of addPeriodic() implicitly creates a dependency on Robot being a subclass of edu.wpi.first.wpilibj.TimedRobot. However, this is not the case when using the AdvantageKit library from FRC 6328 for logging and log playback. AdvantageKit requires the use of a LoggedRobot base class, which does not supply the addPeriodic functionality.

Minimally, the dependency on TimedRobot should be documented.

For cases where LoggedRobot is being used as the robot base class, it is suggested that a Timer (edu.wpi.first.wpilibj.Timer) or similar class be used in a swerve subsystem to provide periodic callbacks to swerve components.

Create a class implementing the basic functionality for Talons with SwerveMotor

With the voltage scaling fix for talon motors, everything seems to work as expected, suggesting that a scalar for the feedforward is not needed. Should we remove this option now that the theoretical feedforward works as expected?

Retrieve front left + front right + back left + back right modules algorithmically.

Optimize CAN frames in the SwerveMotor class.

Link to 364 issue dirtbikerxz/BaseTalonFXSwerve#8

https://github.com/Mechanical-Advantage/AdvantageScope/blob/main/docs/tabs/SWERVE.md

frc-web-components/frc-web-components#133

          i fixed the positions and used the pre tried config options but now im haveing an issue were the robot will not turn correcctly as both sticks seem to drive until both are operated at the same time were they then seem to steer

Originally posted by @aidenm05 in #37 (comment)

SwerveDrive.zeroModules will force all modules to go to an un-optimized angle of 0.

Encoder pulse per rotation is not for "non-integrated encoders" only, it is the total pulses for the motor controller encoders, which is 2048 for falcons

If the robot spins out of control in autonomous or teleop absolute drive the gyro is inverted.

The ArbitraryFeedforward in the set() method for TalonFX motors takes in an input of percentage output from (-1, 1). The current assumption was that it takes in voltage. This should be fixed by just dividing the input of the setReference() method by the nominal voltage (and storing a local nominal voltage to do so).

The current second order kinematics only uses omega squared, the angular speed of the robot in the calculations. This means that physically, the kinematics only produce the intended result when the robot is already spinning, then moves translationally. When the robot starts spinning and moving at the same time, it does not go straight.

The acceleration vector line should be updated to include a rough approximation of:

• angular acceleration
• translational acceleration in x
• translational acceleration in y

This can probably be approximated just simply using a timer to find the change over timestep per iteration, storing the past chassis speeds inside of the kinematics class.

https://github.com/BroncBotz3481/YAGSL-Example/tree/52-add-2nd-order-kinematics-taking-into-account-chassis-acceleration is the linked branch.

Use https://github.wpilib.org/allwpilib/docs/development/java/edu/wpi/first/math/kinematics/ChassisSpeeds.html#fromDiscreteSpeeds(edu.wpi.first.math.kinematics.ChassisSpeeds,double) to correct given values in SwerveDrive.drive

HI, love the library, only having one issue, when I try and tele-op drive on a 45, so a combination of X and Y with no rotation, the robot moves at about half the absolute speed compared to when only moving in the X and Y.

Any ideas?

@thenetworkgrinch

Add support for the PG71 motor as a steering motor by implementing basic functionality.