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.

Sign up for GitHub

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

[design-docs] Add modes design doc #7863

Open
wants to merge 15 commits into
base: 2027
Choose a base branch
from
+721 −0
Open

[design-docs] Add modes design doc #7863

Changes from 1 commit
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
be29384
[design-docs] Add modes design doc
PeterJohnson Mar 14, 2025
f16cdf9
Improve command autos example a bit
PeterJohnson Mar 15, 2025
6538754
Wrap loadComplexPath function call in a runOnce
PeterJohnson Mar 15, 2025
f065a6d
Add some trades
PeterJohnson Mar 15, 2025
40c555c
Add trade re: command-based modes
PeterJohnson Mar 15, 2025
5398df7
Tweak wording
PeterJohnson Mar 15, 2025
32f436d
Various text cleanups
PeterJohnson Mar 16, 2025
88f4dbc
Add start of migration guides with list of key differences
PeterJohnson Mar 16, 2025
80878e2
Change all "category" to "group" for consistency
PeterJohnson Mar 16, 2025
2d80cbd
Uppercase XML
PeterJohnson Mar 16, 2025
85d39eb
Split command-based to separate document
PeterJohnson Mar 18, 2025
b93df8e
Rename commandbased-modes to modes-commandbased
PeterJohnson Mar 19, 2025
cd3009a
Move factory functions back to CommandModes
PeterJohnson Mar 19, 2025
4c83fb8
Commandbased: Refactor mode creation into functions
PeterJohnson Mar 19, 2025
0e4b632
Improve/simplify non-command example code
PeterJohnson Mar 19, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add some trades
@PeterJohnson
PeterJohnson committed Mar 15, 2025
commit f065a6d947f07ec2b3ac712dfc826139dd462bc8
6 changes: 6 additions & 0 deletions design-docs/modes.md
View file
Original file line number Diff line number Diff line change
@@ -605,6 +605,12 @@ Use SendableChooser for more modes (teleop and test as well as autonomous); down

# Trades

- Overall naming: mode? routine? opmode?

- Naming of mode functions? start-periodic-end, vs init-periodic-exit (2015 FRC PeriodicRobot), vs init-execute-end (2015 FRC Command), vs init-start-loop-stop (2015 FTC OpMode; note init behaves like the constructor here)

- For matches, should we construct teleop at the same time as auto? If we do that, we probably need a disabledStart() or 2015 FTC opmode style init(), and don't run disabledPeriodic for both.

# Unresolved Questions

- FRC SendableChooser has a "default" option set by robot code. Do we want something similar here or should it be 100% DS driven? It's kind of nice to be able to set a default (e.g. via a `setDefaultAutonomousMode(String)` function in `Robot`), but also might be a little fragile since it's name based. If it's done via annotation, what happens if multiple annotations are marked as default?
Copy link
Member Author

Choose a reason for hiding this comment

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

The setting a default question is captured here as an unresolved one. One issue is it's not obvious how it will work with annotations. We'd also definitely have to work through all the same scenarios as dashboard sendable choosers re: when the default actually gets used... is it only when the DS is first started? What about if the DS is an app or a physical device?

Maybe it might be better to have an annotation option to make some options bold/highlighted? Or even allow setting a color code to make it more visually distinct?

We also might want different behavior for match vs non-match mode?

Copy link
Member

Choose a reason for hiding this comment

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

The main difference between sendable choosers and integrated into the DS is that the one integrated into the DS will always be there. So does the default force change the DS? When does it do this? When the DS first starts? Every time code reboots? Every time the robot disconnects? Theres a lot more edge cases here. The only time the DS won't have a selection is the first time a project connects to the DS. Otherwise, the DS will always have something, and I feel like that being changed arbitrarily seems like it'd be more of a footgun then it should be.

Agreed that bolding/highlighting is a good idea.