Scheduling System

The Scheduling System is a management tool for running operations with the robot which allows execution complex tasks concurrently. It is provided as part of the flashlib.core.scheduling component.

• Introduction
• Getting Started
  • System-Oriented Robot
  • Actions
• More on the Scheduler
  • Accessing the Scheduler

Introduction

Consider an operating system. Modern operating systems contain a component for scheduling process execution. This component, which did not exist in initial operating systems, is what allows the operating system to run multiple processes concurrently.

Similarly, we found that trying to manage tasks for multiple robot systems, which could actually run at the same time, is extremely difficult. This is exactly what the Scheduling System offers robot developers.

Getting Started

System-Oriented Robot

Robots who wish to use the scheduler, is required to use a systems-oriented code design, as described here.

Once the robot is divided into systems, we will create an instance for each of the systems in the robot main class and initialize those instance in the robot initialization part. For example, for two systems DriveSystem and ShooterSystem under IterativeRobot:

class Robot implements IterativeRobot {

    private final DriveSystem mDriveSystem;
    private final ShooterSystem mShooterSystem;

    public Robot(RobotControl robotControl) {
        mDriveSystem = new DriveSystem(....);
        mShooterSystem = new ShooterSystem(...);
    }
...

This will vary between types of RobotBase.

Actions

We can start implementing actions. Actions are complex tasks, which support dependencies, execution steps, and are generally more powerful then simple Runnables. Actions take the form of Action. Due to their complex nature, it's best to read about them here.

After creating all the actions we need, it is necessary to configure them to run when needed. We can attach actions to many different objects, causing them to run at different times either manually or automatically.

One example is to run an action when the robot enters a mode. For example, under IterativeRobot, we can use modeInit to start an action DriveAction:

class Robot implements IterativeRobot {
...

    @Override
    public void modeInit(RobotMode mode) {
        Action action = new DriveAction(mDriveSystem);
        action.start();
    }
...

This will cause the action to run while the robot is in same control mode, just like how we would write code under modePeriodic.

Another example is to attach an action to a button, as described in here.

More on the Scheduler

The scheduler is described by the Scheduler interface with an implementation under SingleThreadScheduler.

Execution is normally synchronous to the robot main thread, and done in a batch. Basically, this means that thread-safety is unnecessary. In addition, this means that executing heavy tasks, such as IO operations is not recommended.

Being synchronous, the execution of the scheduler is done iteratively, with a call to Scheduler.run. This call executes an iteration of actions. This is usually the responsibility of robot bases, and robot bases from FlashLib mostly provide that, although it is best to refer to the documentation of the specific robot base to make sure. RobotBase itself does not run the scheduler, as it is not iterative.

Accessing the Scheduler

The scheduler is accessible via the RobotControl and is universally accessible via RunningRobot.getControl().getScheduler().

There are several methods which can be used when accessing the scheduler directly:

• Scheduler.cancelAllActions: cancels all the running actions.
• Scheduler.cancelActionsIf: cancel actions which match a given predicate.

The rest should be accessed via Subsystem and Action or ActionBase.