You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The robot should not exit a command where it stops at the end until it has actually stopped. We should take this opportunity to set it back into coast mode once it has stopped, to make for easier testing (only activate in a testing mode?). If you think about chaining commands, the fact that the command ends before the robot has actually stopped becomes more of a problem.
Suggested Implementation
In isFinished of a given command, once the condition to start stopping has been met, return the output from a utility function from the DriveTrain subsystem. This utility function should start the stop, and not return true until the robot has actually stopped. This design should allow the command to continue to loop until the robot has actually stopped.
The text was updated successfully, but these errors were encountered:
The check to see if we should be start stopping and the request to the DriveTrain to start stopping should be part of execute(). The check to see if we have stopped should be called from isFinished(). Also, if the call to DriveTrain is something like isStopped(), we need to make sure that we actually started moving after this command started. The logic about knowing whether we have started or not could be another call to DriveTrain. So, I'm actually thinking we have something like startedMoving be a member variable of the autonomous command, e.g. DriveEncoder. This is initialized to false. In execute(), we call into the DriveTrain to see if we started moving. We set the member variable startedMoving to the result of this call. Then, in isFinished, we would return startedMoving && driveTrain.isStopped().
@jefft138 I like where you're going with this because it is obviously more robust. The only modification I am going to make is that I am going to try to contain all of this functionality in a base class called AutoMovementCommand. I've been trying to better utilize OOP lately, among other reasons to do it this way. I will try to implement this in both DriveEncoder and TurnToDegrees. Thanks.
Proposed Functionality
The robot should not exit a command where it stops at the end until it has actually stopped. We should take this opportunity to set it back into coast mode once it has stopped, to make for easier testing (only activate in a testing mode?). If you think about chaining commands, the fact that the command ends before the robot has actually stopped becomes more of a problem.
Suggested Implementation
In isFinished of a given command, once the condition to start stopping has been met, return the output from a utility function from the DriveTrain subsystem. This utility function should start the stop, and not return true until the robot has actually stopped. This design should allow the command to continue to loop until the robot has actually stopped.
The text was updated successfully, but these errors were encountered: