Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Autonomous Stopping #21

Open
dltompki opened this issue Jan 31, 2021 · 3 comments
Open

Better Autonomous Stopping #21

dltompki opened this issue Jan 31, 2021 · 3 comments
Assignees
Labels
feature New functionality requirement We need this feature to complete the challenge at the most basic level

Comments

@dltompki
Copy link
Contributor

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.

@dltompki dltompki added feature New functionality requirement We need this feature to complete the challenge at the most basic level labels Jan 31, 2021
@dltompki dltompki self-assigned this Jan 31, 2021
@jefft138
Copy link
Contributor

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().

@dltompki
Copy link
Contributor Author

dltompki commented Feb 2, 2021

@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.

@dltompki
Copy link
Contributor Author

Pretty sure this is working at commit d4f4733. I'll wait to close until PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality requirement We need this feature to complete the challenge at the most basic level
Projects
None yet
Development

No branches or pull requests

2 participants