search

Frc2481 / frc-2018

3 stars 0 forks source link

Possible Performance Improvements. #62

Open Kython89 opened 6 years ago

Kython89 commented 6 years ago

~Time TeleopPeriodic execution time.~ Time each subsystems Periodic execution time.

Refactor ObserverPIDSource* to have setters so that obj->GetLastRobotPose() is not called repeatedly. These are used in the PIDController periodic thread and results in 3 * PIDController frequency copies (20) of a RigidTransform2D.

From: V InterpolatingMap::getInterpolated To: V& InterpolatingMap::getInterpolated

From RigidTransform2D Observer::GetLastRobotPose() To RigidTransform2D& Observer::GetLastRobotPose()

Unless we actually use the LimeLight disable it from calculating the CubePose in periodic.

~All arguments passed to Kinematics::SwerveForwardKinematics should be by reference.~

~All arguments passed to Observer::UpdateRobotPoseObservation should be by reference.~

Refactor Observer to use a single RigidTransform2D instead of an interpolating map. Remove GetRobotPos. Any callers should be refactored to use GetLastRobotPose

Kython89 commented 6 years ago

Response from CTRE regarding Talon calls taking a long time.

CAN operations Our API performance expectations are....

  • ~0.3ms per call for any get* routines.
  • ~0.3ms per call for any set or enable routines where the input has changed since previous call.
  • ~0.0ms per call for any set or enable routines where the inputs have not changed since previous call
  • ~ 4ms for any successful ConfigXXXX routines if non zero timeoutMs is passed. These should be done on robot boot.
  • ~ Xms for any timed out ConfigXXXX routines if X timeoutMs is passed. These should be done on robot boot.
  • ~ 0.3ms for any ConfigXXXX if zero timeoutMs is passed. These should be done in the robot loop, if at all (generally not necessary). Success is not determined since there is no wait-for-response checking.
  • ~ 4ms for any successful ConfigGetXXXX. These are generally not necessary.
  • The ~0.3 ms time is a limitation of the roboRIO. In fact many of the functions in WPILIB have this limitation. For example, your joystick/gamepad calls are also ~0.3ms per call. Pretty much anything that has to get/set to the FRCNetComm library (which is used underneath WPILIB).

Our goal was 100 loops.
This seems reasonable, that's 10ms per loop. Count the total number of calls per loop and calculate how much time that is based on the numbers above.

Did the time it takes to set and get increase with Phoenix or has it always been this slow?
It's actually been slightly improved, so I suspect something odd is going on in the robot code. Is your application threaded? If you have reentrent calls then one API may block waiting on another on a different thread depending on circumstances. We generally recommend doing all CAN calls on one thread for simplicity, and performance measurements.

I will add that we decreased the FeedBack frame period to 10ms on all 8 of the drive train Talons.
Nope, doesn't change anything. When you poll a status signal, the execution time is the same regardless of if there was a new frame since last call