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

WIP: Scheduler command rewrite #1637

Closed
wants to merge 212 commits into from

Conversation

Oblarg
Copy link
Contributor

@Oblarg Oblarg commented Mar 13, 2019

Major rewrite of the command-based libraries.

Refactors Command to be an interface, migrating all necessary scheduling state into Scheduler or into temporary CommandState objects used by the scheduler. This greatly improves both encapsulation and overall comprehensibility of the code's control flow.

Rewrites Scheduler to use modern Java features, increasing readability and removing a lot of unneeded cruft.

Replaces CommandGroup with SequentialCommandGroup and ParallelCommandGroup, resulting in both cleaner code and less confusion. The available functionality is exactly the same, as both objects implement the new Command interface and thus can be composed.

Introduces new ParallelCommandRace, which runs a set of commands in parallel and exits after the first one finishes, interrupting all the others. Uses this to implement a withTimeout method in the Command interface, which cleanly adds a timeout to any command.

Refactors Subsystem to be an interface.

Planned additions:

A BasicSubsystem class can also be included that calls the necessary defaulted methods (e.g. registerSubsystem) in the constructor to eliminate the minor amount of increased overhead to teams.

Provide simple implementations of the new Command interface to cover the features provided by the old assortment of commands (e.g. timeouts). Note that, as the new Command interface does not contain its own scheduling state, it cannot provide certain methods like timeSinceInitialized - however, it is not difficult to include implementations that do this.

@@ -335,7 +335,7 @@ private CameraServer() {
table.getEntry("mode").setDefaultString(videoModeToString(mode));
table.getEntry("modes").setStringArray(getSourceModeValues(event.sourceHandle));
} catch (VideoException ignored) {
// Do nothing. Let the other event handlers update this if there is an error.
// Do nothing. Let the other event handlers calculate this if there is an error.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you wanted to touch this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. Intellij's refactoring tool gets overeager sometimes.

Copy link
Member

@auscompgeek auscompgeek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you missed a few more. (There might be more that I haven't noted, kinda stopped halfway through.)

@@ -1044,7 +1044,7 @@ protected void getData() {

HAL.getMatchInfo(m_matchInfoCache);

// Force a control word update, to make sure the data is the newest.
// Force a control word calculate, to make sure the data is the newest.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't make sense either.

@@ -107,7 +107,7 @@ public Notifier(Runnable run) {
m_expirationTime += m_period;
updateAlarm();
} else {
// need to update the alarm to cause it to wait again
// need to calculate the alarm to cause it to wait again
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@@ -18,7 +18,7 @@
*
* <p>The values supplied as arguments for PWM outputs range from -1.0 to 1.0. They are mapped to
* the hardware dependent values, in this case 0-2000 for the FPGA. Changes are immediately sent to
* the FPGA, and the update occurs at the next FPGA cycle (5.005ms). There is no delay.
* the FPGA, and the calculate occurs at the next FPGA cycle (5.005ms). There is no delay.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@@ -35,7 +35,7 @@ public static double getMatchTime() {
/**
* Pause the thread for a specified time. Pause the execution of the thread for a specified period
* of time given in seconds. Motors will continue to run at their last assigned values, and
* sensors will continue to update. Only the task containing the wait will pause until the wait
* sensors will continue to calculate. Only the task containing the wait will pause until the wait
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

@Oblarg
Copy link
Contributor Author

Oblarg commented Apr 1, 2019

Oh dear. I'll do a thorough check today.

@PeterJohnson
Copy link
Member

This pull request is giant, making it difficult to review. Why are so many files being touched, and why are copies of non-related classes being made into experimental? If there are changes that reach across non-command classes, please put that into a separate PR, or restructure/squash the commits on this PR so that it can be reviewed on a per-commit basis.

@calcmogul
Copy link
Member

The unrelated class modifications and copies in experimental are from rebasing onto #1300.

@Oblarg Oblarg closed this May 6, 2019
pjbuterbaugh pushed a commit to pjbuterbaugh/allwpilib that referenced this pull request Jun 15, 2023
Co-authored-by: Vasista Vovveti <vasistavovveti@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants