FTC Roadrunner 1.0 First Autonomous Coding with Actions

FTC Roadrunner 1.0 First Autonomous Coding with Actions

Introduction to Road Runner for FTC

Overview of the Robot Setup

  • The video introduces the use of Road Runner version 1.0, focusing on a test robot named Bob, which is equipped with four drive motors and three dead wheel encoders.
  • A servo has been mounted on the front of Bob, which will be controlled during autonomous operations.

Objectives of the Video

  • The goal is to program Bob for autonomous tasks that include driving and controlling the servo's movement in a timed manner.
  • The planned actions involve moving forward, spinning the servo in one direction for three seconds, reversing, and then spinning it in the opposite direction for another three seconds.

Programming Basics

Code Structure and Expectations

  • The presenter shows a concise code structure consisting of only 70 lines, indicating that prior programming knowledge is expected from viewers.
  • Viewers should be familiar with linear op modes and how to access hardware components like servos from the hardware map.

Action Execution

  • The video will cover running a series of actions using both built-in methods from Road Runner and custom actions implementing an action interface.
  • Custom actions will include setting servo positions and incorporating timers to control their operation duration.

Creating Autonomous Code

File Creation Process

  • Viewers are guided through creating a new Java class file named "First Road Runner Auton," extending linear op mode as standard practice.
  • An annotation for autonomous mode is added to ensure proper functionality within the FTC framework.

Hardware Initialization

  • Initializing hardware components such as servos occurs within this new file; viewers are reminded about previous configurations made in earlier videos.
  • The mechum drive class handles all necessary hardware mappings based on previously set parameters, simplifying setup processes.

Final Steps in Programming

Setting Up Drive Parameters

  • In this section, viewers learn how to initialize mechum drive with starting position parameters typically set at zero coordinates.
  • Additional setup includes configuring servos according to their mapped ports on the control hub.

Initialization of Motors and Road Runner Basics

Overview of Motor Initialization

  • The discussion begins with the initialization of four motors within a mechum drive class, referencing previous work done in Android Studio.
  • The speaker emphasizes starting from a sample code, specifically focusing on a manual feedback tuner that drives the robot forwards and backwards.

Code Structure and Functionality

  • The code includes various if statements for different driving modes (tank drive vs. mechum), confirming correct implementation of the mechum drive constructor.
  • A while loop is introduced to keep the operation active, utilizing actions run blocking to execute commands sequentially.

Actions Framework in Road Runner

  • The actions framework allows for breaking down tasks into manageable actions like driving to specific positions or waiting for certain durations.
  • Custom actions can be created within this framework, enhancing flexibility in programming robot movements.

Executing Robot Movements

Running the Code

  • The speaker prepares to upload code to the robot and checks recording settings before demonstrating functionality on the field.
  • Using FTC dashboard setup from previous videos, they illustrate how trajectories are displayed visually during execution.

Observing Robot Behavior

  • Upon running the initialized program, the robot successfully drives forward and backward as intended, showcasing basic autonomous movement capabilities.

Integrating Servo Actions

Adding New Functionalities

  • Discussion shifts towards incorporating servo actions into existing routines for additional functionalities like delivery mechanisms.
  • To add more actions, a new class implementing action must be created; this involves defining specific behaviors for servos within Road Runner's structure.

Class Implementation Details

  • A nested class called ServoAction is proposed to encapsulate servo behavior directly within another class for simplicity.
  • This new class must implement required methods from its parent interface, ensuring it adheres to Road Runner's action protocols.

Defining Servo Action Behavior

Constructor Setup

  • The ServoAction constructor will accept parameters such as servo instance and target position, allowing dynamic control over servo movements.
  • Inside the run method of ServoAction, logic is established to set servo positions based on previously defined parameters.

Servo Action Implementation

Setting Up Servo Actions

  • The process begins with defining an action that requires a Servo and a position. This involves preparing Road Runner to execute the action by specifying the parameters.
  • A Boolean is returned to indicate whether the action needs more time to run, but for now, it will return false immediately, indicating completion of the function.

Integrating Actions into Code

  • After calling lineToX, the next step is to call stopAndAdd, which takes an action as input. This allows for adding new actions for Road Runner to execute.
  • A new Servo action is created by passing in the Servo and its target position (e.g., zero for continuous Servos), which dictates its movement direction.

Understanding Builder Pattern

  • The code utilizes a builder pattern in Java, allowing multiple method calls on a single line without semicolons. Each method returns the same builder instance for chaining.
  • The absence of semicolons indicates that methods are being chained together seamlessly, culminating in an action that encapsulates all interactions.

Testing Robot Behavior

  • Once plugged in, testing begins with expectations of how the robot will behave when executing commands: moving forward and then returning while controlling servo actions.
  • Observations confirm that the robot moves as expected; however, it raises questions about how servo actions integrate with movement commands.

Managing Timing and Actions

  • To ensure proper delivery of game elements during movement, a simple solution involves using waitSeconds to pause execution while the servo operates.
  • Implementing waitSeconds allows observation of how long servos spin before subsequent movements occur; this can be crucial for timing operations effectively.

Enhancing Control Over Actions

  • Following initial tests, adjustments are made to include stopping servo actions after waiting periods. This ensures better control over robotic movements and functions.

Understanding Patient Servo Actions

Introduction to Basic Servo Action

  • The initial implementation of the Servo action returns false, indicating that once the run method is called, no further actions will be executed until completion.
  • A new type of action, termed "patient Servo action," is introduced to allow for a fixed wait time before declaring the action complete.

Implementing Timer Functionality

  • The patient Servo action will track its running duration using a timer class, which helps manage how long the servo operates before completing its task.
  • In the run method, it checks if the timer is null; if so, it initializes and starts tracking time upon first execution.

Conditional Return Values

  • The return value of the run method becomes conditional based on whether three seconds have elapsed since starting.
  • If less than three seconds have passed, it returns true (indicating ongoing operation); otherwise, it returns false when completed.

Code Optimization Techniques

  • A more concise way to write return statements is suggested by simplifying conditions directly in return statements.
  • It’s noted that while repeatedly calling set positions for servos isn't harmful, initializing code within an if statement can optimize performance for other components like motors.

Best Practices in Action Implementation

  • Using a boolean flag to check initialization status allows for setup code to execute only once during the first call of run.
  • This approach can be adapted for different types of motors or actions beyond servos by checking target positions or modes as needed.

Finalizing Patient Servo Action Integration

  • The patient Servo action replaces previous implementations without needing explicit wait commands in driving sequences.

Robot Programming and Autonomous Actions

Overview of Robot Code Execution

  • The robot's code is designed to manage its actions autonomously, allowing it to run without constant input from the programmer.
  • After unplugging the robot, a demonstration of the "road runner" autonomous mode is conducted, showcasing how the robot drives forward and operates its servo for specific durations.
  • The new "Ro Runner auton" class includes an autonomous tag for visibility in operation modes, utilizing a mechanim drive file that integrates drive motors and servos from a hardware map.

Action Management in Code

  • The code execution waits for a start button before initiating actions in a blocking order, ensuring sequential completion of tasks.
  • Some actions are non-blocking (e.g., immediate return), while others like patient Servo actions utilize timers to manage duration effectively.

Advanced Driving Techniques

  • The discussion introduces various driving methods available in Road Runner documentation, including line-to-X and line-to-Y commands that allow precise movement towards coordinates while maintaining orientation.
  • Additional methods such as spline movements enable curved paths; users can explore these options through video demonstrations within the documentation.

Customization and Organization of Code

  • Users are encouraged to implement additional functions like strafe or turn commands to enhance maneuverability based on their needs.
  • To maintain organized code structure, it's suggested to separate action files into distinct classes (e.g., claw class), which can streamline functionality and improve readability.

Conclusion and Next Steps