frcteam2910 / common Goto Github PK

Hi! Would you be willing to add a license to this repo, for example https://choosealicense.com/licenses/mit?

Current Gradle wrapper version is 4.8.1 but 5.0 is out.

Current GradleRIO plugin version for the robot library is 2018.06.21 but 2019.0.0-alpha-3 is out.

The GradleRIO plugin should be updated and the latest version of Gradle that GradleRIO supports should be used.

Describe the bug
Motion profiles where the velocity has to be negative aren't handled correctly.

To Reproduce
Steps to reproduce the behavior:

1. Create a motion profile where the starting position is greater than the ending position
2. Notice how MotionProfile.getDuration() returns NaN

Describe the feature in question
Add documentation to the Subsystem class in the robot library.

Does this feature have a deadline? If so, when?

Does this feature rely on any others to be implemented first? If so, which?

Additional context

The strafe and rotation axis are inverted and need to be fixed.

During trajectory generation, the motion profile can't always decelerate fast enough to reach the max velocity of the next segment. This results in a jump in velocity which can negatively affect the result of following the trajectory.

Currently in order to slow down when approaching a turn in a path the trajectory constraint arcVelocityScalar is used. While it does work it can be hard to tune. Max centripetal acceleration can be used instead, it is much more intuitive to use and it is well-defined in physics.

Centripetal acceleration can be calculated using the equation A = V^2/r. The maximum velocity for an arc can be calculated by solving the previous equation for V: V = sqrt(Ar) where A is the maximum centripetal acceleration and r is the radius of the arc.

Creating issue for tracking only, this is low impact and probably won't matter if/when we use a 3rd party math library anyway.

Generating a rotation matrix from euler angles can be done in-place, instead of separately creating an X, Y, and Z rotation matrix then multiplying them together.

Hi, I'm from Team 4450. We're trying to switch to swerve this year and wanted to use your code as a reference. Although as I built the class I got this error:

Could not determine the dependencies of task ':shadowJar'.

Could not resolve all dependencies for configuration ':runtimeClasspath'.
Could not resolve project :common:robot.
Required by:
project :
> No matching configuration of project :common:robot was found. The consumer was configured to find a runtime of a library compatible with Java 11, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally but:
- None of the consumable configurations have attributes.

Not sure if I'm missing something, but any help would be much appreciated.

We should add Azure CI to verify all pull requests that are proposed so that they can be automatically verified before it is merged.

The NavX currently returns its rate in degrees/sec instead of radians/sec. This is different from what is expected because radians/sec is used everywhere else.

Describe the feature in question
The Trajectory generation example you have in this repo is awesome! It would be really great if you guys would be willing to publish some sort of trajectory following using the trajectory generated in the current example!

Does this feature have a deadline? If so, when?
None

Does this feature rely on any others to be implemented first? If so, which?
None

Rotating with a swerve drive causes some unexpected forward kinematic results like the position changing by a significant amount (> 5 ft) while the robot stays in the same spot.

git submodule add https://github.com/FRCTeam2910/Common-Public.git common
->
git submodule add https://github.com/FRCTeam2910/Common.git common

CTRE's Pigeon IMU is a commonly used gyroscope by FRC teams. We recently bought one for testing so it would be good to be able to integrate it with the rest of our code. To do this we need to add a driver for the Pigeon that implements the Gyroscope class.

Describe the bug
Trajectory end points do not match where the path ends and the velocity is not zero.

To Reproduce

1. Create a path with multiple segments
2. Create a trajectory
3. Calculate ending segment of trajectory using trajectory.calculateSegment(trajectory.getDuration())
4. Observe that the segment.translation does not equal the end of the path and that segment.velocity is not zero.

Expected behavior
segment.translation equals the end of the path and segment.velocity is zero.

Screenshots

Currently, to generate a trajectory a constant max velocity and acceleration is specified. While this can work, it is not ideal because when following the path the feedforward term might exceed 100%. Because the trajectory is precalculated, the feedforward term should be guaranteed not to exceed 100%. This will also for the fastest trajectory possible that the robot can follow.

Ka = 1 / max acceleration
Kv = 1 / max velocity
F = Kv * V + Ka * A

F should ideally always be equal to 1 for the fastest path. However, because error correction is needed the target value of F should be configurable in the trajectory constraints.

Moving the drivetrain classes into the common lib allows them to be unit tested. However, they currently use the WPILib Subsystem class which is not accessible in the common library.

Currently the Mk2SwerveModuleBuilder supports the CANSparkMax (Spark MAX w NEO) and generic SpeedController objects as angle motors. It would be good to add an override for TalonFX (Falcon 500) in order to take advantage of the integrated encoder and higher update rate.

In the meantime, Falcons should (meaning I think it will work) be able to be used by using the WPI_TalonFX class with the MotorType.CIM motor type. However, none of the integrated features of the Falcon will be used and the control loop will run on the roboRIO.
Example:
.angleMotor(new WPI_TalonFX(0), MotorType.CIM)

Describe the feature in question
In order to use the limelight we have to communicate with it over NetworkTables. There is no provided "wrapper" over this communication so adding a wrapper class would be nice.

The wrapper class have methods like the following:

• boolean hasValidTargets()
• void setLedMode(LedMode mode)
• void setActivePipeline(int pipeline)

This is in no way a complete list.

Does this feature have a deadline? If so, when?
2019-01-12

Does this feature rely on any others to be implemented first? If so, which?

Additional context
The Limelight documentation can be found here

Describe the bug
Field centric works when the robot is in certain orientations. For example, when I reset the gyroscope value, it works as in it resets the new forward backward etc. movement. When I rotate the robot 180 degrees it also works as intended. However, when rotating while moving, it is as if the robot disable field centric mode and starts moving in robot centric mode. For example, when i start rotating and move backwards, it moves towards the robot's backward position and not the driver's backward position.

To Reproduce
Steps to reproduce the behavior:

1. Implement the example swerve code
2. Reset gyro using button
3. Rotate robot and move in any direction

Expected behavior
The robot should be moving forward always relative to the driver, not the robot.

Additional context
I have tried implementing both the example swerve code found in this Repo and also the example swerve code in SDS's github profile, but both have the same issue.

GradleRIO for 2019 was released and we need to update Gradle, GradleRIO, and vendor libraries