Robot Scheduling System

The Robot Scheduling System acts like a small operating system and allows easy control of multiple systems at the same time. It provides the comfort and organization of not having to worry about execution of tasks for the robot and the easy ability to execute and monitor several activities on the robot at the same time.

Overview

The scheduling system bases its operation on dividing the robot into different systems, each represented in a different class and provides logic for actuator control and sensor input:

Each system can have one action running on it at any given time. That action is responsible for executing programmed control algorithms for that system. The actions are executed by the scheduler:

Subsystem

A system on a robot can be the drive system which controls the drive motors, or a simple arm controlled by a single motor. In either case, each system is represented by the Subsystem class. To create a system, your class must extend Subsystem but there is no need to implement any method, the base is simply logic for control.

A Subsystem can have only one action running on it at any given time. This allows us to avoid control complications with that systems.

In addition, each system can have a default action: an action which will start running on the system if no other action is running at the moment.

Action

An action is represented by the class Action. To create an Action, simply extend the class and implement necessary methods. An action can be executed multiple times and can depend on multiple systems (the requirements). Once started, the execution process of an action is as following:

• A check is performed to insure no other action is running on any of the required systems. If there are actions, they are canceled and their execution is stopped.
• The action then starts and initialize is called.
• While still executing:
  • execute is called
  • isFinished is called. If it returns true the action stops execution, otherwise execution continues.
• When execution is done, if isFinished returned true then end is called, otherwise interrupted is called.

Actions can also have a timeout, which is specified in milliseconds. After execution has started, if a given amount of time has passed, the action is stopped. To set a timeout, call setTimeout. If the timeout is not positive, it is ignored and the action will not stop.

There are 3 instances where interrupted can be called:

• Someone called the cancel method to manually stop the action.
• The scheduler canceled the action because another started running with an overlapping system requirement.
• If a timeout was set and was reached.

Special Actions

There are a number of extensions to the Action class which provide an added functionality for actions:

• SelectableAction: holds a collection of actions and allows users to choose which action to execute among them
• ConditionalAction: holds 2 actions and a BooleanSource. Depending on the source's value, an action is used
• InstantAction: an action which executes once (execute is called once).
• ActionGroup: executes a number of actions in a specified order. Can be sequential, or parallel or both.
• RunnableAction: an action which runs a Runnable object in execute
• InstantRunnableAction: an action which runs a Runnable object in execute once (execute is called once).
• CombinedAction: a specialized action for combining multiple actions for one system. Allows users to collect data from multiple actions and combine the results into one output for one system.
• SourceAction: the base for action that are combined into CombinedAction. Uses a DoubleSource to provide output for the used system.

Action Wrapping

There are times when we wish to make 2 copies of one action, each with different parameters. But this might require us for a different implementation, or sometimes a big complicated solution to accommodate both. To solve such issues, FlashLib provides action wrapping.

The concept is that we take an action, and pass it to another class. That other class will hold it as a variable and call its methods. What's special is that the other class will have some different parameters for execution, such as a timeout, a different system requirement, or even periodic execution. This in turn allows us to easily duplicate algorithms with different parameters.

There are several action wrappers, each extends Action itself:

• SystemAction: adds system requirements for an action
• TimedAction: adds a timeout for an action
• PeriodicAction: calls execute at constant time periods

Say we have a "fire" action which fire our cannon and we use this in operator control. But say we want to fire with a timeout in autonomous. So instead of creating another action with a timeout, we simply wrap the "fire" action with a TimedAction (let's call this new one "timed fire"). So now, when we start "fire" it will act as before, and when we start "timed fire", it will execute like "fire" but will be interrupted when timed out.

Scheduler

The scheduler is responsible for execution of Actions and is represented by the class Scheduler. The scheduler can execute both Runnable objects and Action objects. It is a singleton class (Has only one instance). The scheduler is also responsible for start default actions for systems and for avoiding execution of several actions on one system.

To run the scheduler cycle, which is responsible for execution and monitoring, call the run method. It should be called periodically to allow for continuous execution.

To add a Runnable object for continuous execution, call addTask, and to remove it, call remove. For a single execution, call execute. But when working with Action objects, use the start and cancel methods in Action instead.

When creating a Subsystem it will be automatically registered into the scheduler so that it could be monitored for default action execution.