Closed Seairth closed 8 years ago
I have currentActivity.update() called in the < GameState >.run()
See my other post. I'm not sure if we need the GameState classes. To a large extent, I think these are replaced by the Autonomy, ManualDrive, and Idle activities.
In general, we want to call
currentActivity.update()
in each of the periodic methods. In essence, we are simply delegating the periodic update to whatever the current activity is. The one potential issue is that the current activity might not be appropriate for a given mode. For instance, suppose we are in autonomy mode and a breach is currently being performed. FRC switches the robot to teleop. If we do nothing, the robot will continue to perform it's activity until it calls getDefaultActivity(), at which point the activity being returned is the ManualDrive activity. This is likely safe (i.e. no matter what the robot is doing in autonomy mode, it can safely finish its current activity even though it has been switched to teleop mode). However, what should happen if we switch from autonomy or teleop to disabled? In this case, we want to make sure that whatever current activity is active, it should be cancelled. To do this, we would probably callcurrentActivity.cancel()
inside initDisabled().Which also makes me realize that we could probably provide default implementation of cancel() in Activity that simply calls
robot.setActivity(robot.getDefaultActivity())
. In many cases, the default behavior will be good enough. In others (e.g. when we've spawned concurrent threads), we will want to override and add some additional cancellation behavior.Similarly, I'd go ahead and make Activity.initialize() an empty method (not abstract). That way, subclasses that don't need to initialize (like Idle, Autonomy, and ManualDrive) don't need to provide overrident implementations.