Allow passing DS Instance to Robot and OpModes#8626
Allow passing DS Instance to Robot and OpModes#8626ThadHouse wants to merge 12 commits intowpilibsuite:2027from
Conversation
Some discussion with the tech team showed that there were some real advantages to being able to pass a 2nd type. It allows separating the DS and Robot. Additionally, we can make the DriverStationBase class actually usable instead of the existing DriverStation class which is impossible to handle in intellisense because it has too much.
github-actions
bot
added
component: wpilibj
|
It think it would make more sense to name that something other than DriverStation(Base/Instance). I'm not sure what to name it, but the Driver Station isn't a (user configurable) collection of gamepads/high level user controller abstraction. |
|
Well a driver station is actually a user configurable collection of gamepads. Thats like the one user configurable thing. |
|
You mentioned there was an advantage to adding this additional layer of indirection, but it's not obvious what it is. |
|
It becomes more obvious what things are part of the DS, and what things are a part of the robot. It also gives a good place to put driver station specific code, like alliance flipping if a team wants to handle that. It also gives a uniform place to store all gamepad and joystick instances, which with opmodes becomes more important because we want to limit to a single instance, and we can imagine teams putting joysticks inside each opmode. Which we want to avoid. |
| /** | ||
| * An interface representing user controls such as gamepads or joysticks. | ||
| * If your main robot class has a UserControlsInstance attribute with a | ||
| * class implementing this interface, the constructor is able to receive | ||
| * an instance of that class. Additionally, any OpModes can also receive | ||
| * that same instance. | ||
| */ | ||
| public interface UserControls { |
There was a problem hiding this comment.
We should document (either here or in @UserControlsInterface, or both) that the class must have a default constructor.
| System.out.println("Constructor parameter types: " + java.util.Arrays.toString(paramTypes)); | ||
| if (dsInstance != null | ||
| && paramTypes.length == 1 | ||
| && UserControls.class.isAssignableFrom(paramTypes[0])) { |
There was a problem hiding this comment.
| && UserControls.class.isAssignableFrom(paramTypes[0])) { | |
| && paramTypes[0].isAssignableFrom(UserControls.class)) { |
| private static boolean m_suppressExitWarning; | ||
|
|
||
| private static <T extends RobotBase> T constructRobot(Class<T> robotClass) throws Throwable { | ||
| UserControlsInstance dsAttribute = robotClass.getDeclaredAnnotation(UserControlsInstance.class); |
There was a problem hiding this comment.
Don't forget to update the variable names from using ds to userControls.
| for (Constructor<?> constructor : constructors) { | ||
| Class<?>[] paramTypes = constructor.getParameterTypes(); | ||
| if (paramTypes.length == 0) { | ||
| System.out.println("Constructor parameter types: " + java.util.Arrays.toString(paramTypes)); |
There was a problem hiding this comment.
Is this print staying long-term? If so, we we get an import of Arrays?
4 participants
Some discussion with the tech team showed that there were some real advantages to being able to pass a 2nd type. It allows separating the DS and Robot. Additionally, we can make the DriverStationBase class actually usable instead of the existing DriverStation class which is impossible to handle in intellisense because it has too much.
This won't fully be doable in C++, but we will need to implement something similar in python.