This Pull Request will add simulated encoders, a gyro, odometry, a Field2d and a DifferentialDrivetrainSim model to DriveSubsystem.java. When the robot recognizes that it is in a simulation, the model will apply a voltage to the drivetrain based on what voltages the motors are running in. Also, the simulated sensors will update their readings. The readings will be used to update the robot's odometry so that its pose can be represented graphically in a Field2d object.
In Robot.java, the simulation will crash when selecting certain robot states. The crashes are caused by null-pointer exceptions that are thrown mostly by the Arduino code. This was fixed by adding a RobotBase.isReal() check to the existing Init() methods.
New constants for the simulation have been added to Constants.java. Some of these values will change later on when the robot starts running more in-person tests.
New methods have been added to GyroscopeSerial.java. getHeadingRadians() will make it more convenient to construct Rotation2d objects and getRawYaw() will help to address some of the problems that were discovered in #3.
March 17
A CANSparkMaxSim class has been created to better mimic the robot's driving behavior. Also, initializing the odometry/pose has been changed in DriveSubsystem. The robot pose will always default to the origin with a heading of zero radians. The simulation model has been setup to accommodate for robot characterization constants that will be added in a future Pull Request. In RobotContainer, a RamseteCommand has been added and scheduled. Currently, there is a trajectory that will make the robot move forward for two meters in a straight line. In the future, code will be added to read and generate trajectories using json files from Pathweaver.
Some known issues:
The DifferentialDrive in DriveSubsystem needs a separate instance to allow the RamseteCommand to run properly.
In DriveSubsystem, the right side motors (or the rightDriveGroup) seems to be inverted. Calling arcadeDrive() normally seems to cause issues with how the motor speeds are set on both sides. Currently, adjustments have been made on the simulation side to correct for this issue, but getting to the bottom of this would probably be helpful.
Closes #16.
This Pull Request will add simulated encoders, a gyro, odometry, a
Field2dand aDifferentialDrivetrainSimmodel toDriveSubsystem.java. When the robot recognizes that it is in a simulation, the model will apply a voltage to the drivetrain based on what voltages the motors are running in. Also, the simulated sensors will update their readings. The readings will be used to update the robot's odometry so that its pose can be represented graphically in aField2dobject.In
Robot.java, the simulation will crash when selecting certain robot states. The crashes are caused by null-pointer exceptions that are thrown mostly by the Arduino code. This was fixed by adding aRobotBase.isReal()check to the existingInit()methods.New constants for the simulation have been added to
Constants.java. Some of these values will change later on when the robot starts running more in-person tests.New methods have been added to
GyroscopeSerial.java.getHeadingRadians()will make it more convenient to constructRotation2dobjects andgetRawYaw()will help to address some of the problems that were discovered in #3.March 17 A
CANSparkMaxSimclass has been created to better mimic the robot's driving behavior. Also, initializing the odometry/pose has been changed inDriveSubsystem. The robot pose will always default to the origin with a heading of zero radians. The simulation model has been setup to accommodate for robot characterization constants that will be added in a future Pull Request. InRobotContainer, aRamseteCommandhas been added and scheduled. Currently, there is a trajectory that will make the robot move forward for two meters in a straight line. In the future, code will be added to read and generate trajectories usingjsonfiles from Pathweaver.Some known issues:
DifferentialDriveinDriveSubsystemneeds a separate instance to allow theRamseteCommandto run properly.DriveSubsystem, the right side motors (or therightDriveGroup) seems to be inverted. CallingarcadeDrive()normally seems to cause issues with how the motor speeds are set on both sides. Currently, adjustments have been made on the simulation side to correct for this issue, but getting to the bottom of this would probably be helpful.