All the offseason changes put together. #183
Conversation
…o SoloController
…what is the closest algae
… into cyclesuper
| } | ||
|
|
||
| // if the solo controller is connected, use it for driving | ||
| boolean soloCC = soloController.isConnected(); |
There was a problem hiding this comment.
I think this will result in soloCC only being set when the robot code starts running, so changing to or from soloCC will require a restart of the robot code. Consider instead making this a boolean class member variable and then updating it ever second or so based on whether the solo controller is connected (via adding a new update method in this class that Robot.robotPeriodic() calls, and have the update method do the soloCC update every second or so).
There was a problem hiding this comment.
it worked fine at drive practice we can check again at the meeting on monday
-Aarya (I forgot what account im on)
There was a problem hiding this comment.
do you think it actually matter is we just call soloController.isConnected() instead of soloCC for the drive request (changing it back to what is was before)?
There was a problem hiding this comment.
Looking at what isConnected does, it's similar to what driverController.getLeftX() does by looking at DriverStation.getStickAxis() vs DriverStation.isJoystickConnected
I wouldn't go back to the original change which did .withVelocityX(soloController.isConnected() ? getSoloDriveX() : getDriveX()), since it ends up reading from the HID four times (three times to check if the controller is connected & once to get that axis value), but instead have a class variable that's updated every loop to cache the result of soloController.isConnected() and then switch off of that: .withVelocityX(soloCC ? getSoloDriveX() : getDriveX()). To ensure the commands are run with the most up-to-date value, I'd sequence the new Command class periodic update in Robot.robotPeriodic to happen before the call to CommandScheduler.getInstance().run();
4 participants
No description provided.