Thursday, December 1, 2022

ACA Robotics Programming



Review theDocumentations:

Expansion Hub with Android Device Robot Controller - DUO Control System (revrobotics.com)

Keep this diagram handy:

Wiring Diagram - DUO Control System (revrobotics.com)

  • Programming 

The FTC Robot controller library  includes all the basic Java sample codes for the game.

Programming the basic robot components. 

Watch the video Tutorials(one at a time). Follow the steps to create your own java program. The file name convention : 

yourunique-prefix+originalfilename.Java. 

For the FTC library name convention, please review this link.

2. Understand the code ( you might do 2,3,4 together)

A. Carefully Read instructional comments.  

B. Understand the structure / components of the java program. 

C. Make sure the names of the robot parts in the sample code are the same as the names in the controller. If not change your 

code or change the configuration on the controller. ( be sure to create and save your robot configuration not to overwrite other’s configuration file)


3. Run/Debug your code

Copy and paste your java file to OnBot java on the web browser. Http://168……
Run the code 

4. Test the code via driver station 

5. Try if you can modify the code
1. Put the output on the driver station use the telemetry function 
2. add a count variable to display how many times the robot component(s) ran in the while loop. You can reference to the demo program: demorampmotospeed.Java

Autonomous programming 

The REV Expansion Hub has a built-in IMU, or Inertial Measurement Unit. This is a sensor that can measure acceleration (movement) in several axes. 

https://docs.revrobotics.com/duo-control/sensors/i2c/imu#how-to-use

Originally, Control Hubs and Expansion Hubs came with the Bosch BNO055 IMU. Control Hubs containing the alternative Bosch BHI260AP IMU started shipping in September 2022. To see which IMU your Control Hub has, go to the Manage page within the Program & Manage web interface, either from the Driver Station, the REV Hardware Client, or at http://192.168.43.1:8080 in a web browser on a laptop connected to the Control Hub's Wi-Fi network.
When you create a new configuration file, the correct IMU type will be automatically detected, and added to the configuration.
Version 8.1 of the FTC Robot Controller app adds a new universal IMU interface for Blocks and Java programming, which supports both the BNO055 IMU and the BHI260AP IMU. The BNO055 IMU can also be used from the legacy BNO055IMU interface.

The universal IMU interface

The new universal IMU interface added in version 8.1 of the FTC Robot Controller app provides robot-centric orientation and angular velocity values. You can specify the exact orientation of the Control or Expansion Hub on your robot, and the interface will convert the raw values from the IMU into robot-centric values. This simplifies how you use the IMU's values, and prevents problems when the hub is not mounted with the REV Robotics logo facing upwards.
All values from theIMU interface are in the Robot Coordinate System, in which the origin is inside your robot, the Z axis points towards the ceiling, the Y axis points straight ahead through the front of your robot (whatever you define the front to be), and the X axis points out the right side of your robot. This coordinate system is right-handed, which means that if you point a typical right thumb in the same direction as the axis, rotation in the same direction that the fingers curl is considered positive.
The IMU.getRobotYawPItchRollAngles()method on the IMU interface provides the robot's orientation in a simplified format of yaw, pitch, and roll angles. Most teams should use this method to get the robot's orientation.
  • Yaw (also known as heading) is the measure of rotation along the robot's Z axis, or the side-to-side lateral rotation of the robot.
  • Pitch is the measure of rotation along the robot's X axis, or the front-to-back rotation of the robot.
  • Roll is the measure along the robot's Y axis, or the side-to-side tilt of the robot.

Yaw, Pitch and Roll of the robot

It can be used in place of an external gyro. The IMU is not used in quite the same way as the gyro but is similar. Note: you must configure the IMU on I2C channel 0, port 0. Here is the DriveAvoid example converted to use the IMU in place of the MR gyro.




  • Use encoder:

Using RUN_TO_POSITION

To use RUN_TO_POSITION mode, you need to do the following things in this order:

  1. Set a target position (in ticks)

  2. Switch to RUN_TO_POSITION mode

  3. Set the maximum velocity

    // Set the motor's target position to 300 ticks
    motor.setTargetPosition(300);
    // Switch to RUN_TO_POSITION mode
    motor.setMode(DcMotor.RunMode.RUN_TO_POSITION);
    // Start the motor moving by setting the max velocity to 200 ticks per second
    motor.setVelocity(200)

Basics of Programming with Encoders

Basic Encoder Concepts

STOP_AND_RESET_ENCODER Mode

Place a motor in this mode when you want to set its encoder position back to 0. The motor will stop. To start it again, you need to place the motor into one of the other three modes. It is recommended to place each motor you will be using encoders with into this mode at the start of each program, so that you know what position the motor is starting out in.
RUN_WITHOUT_ENCODER Mode

Use this mode when you don’t want the Control Hub to attempt to use the encoders to maintain a constant speed. You can still access the encoder values, but your actual motor speed will vary more based on external factors such as battery life and friction. In this mode, you provide a power level in the -1 to 1 range, where -1 is full speed backwards, 0 is stopped, and 1 is full speed forwards. Reducing the power reduces both torque and speed.
This mode is a good choice for drivetrain motors driven by joysticks on the gamepad.
RUN_USING_ENCODER Mode

In this mode, the Control Hub will use the encoder to take an active role in managing the motor’s speed. Rather than directly applying a percentage of the available power, RUN_USING_ENCODER mode targets a specific velocity (speed). This allows the motor to account for friction, battery voltage, and other factors.

This mode is a good choice for operations, like a flywheel, that require a specific speed and can use buttons on a gamepad for control.
RUN_TO_POSITION Mode

In this mode, the Control Hub will target a specific position, rather than a specific velocity. You still set a velocity, but it is only used as the maximum velocity. The motor will continue to hold its position even after it has reached its target.

DriveTrain Motors

Drivetrain Motors on Drivetrain Movement (two wheel driving) 


———————

Camera


------


https://youtu.be/NqRiXfuj-Dw camera images testing








at No comments:

Tuesday, November 8, 2022

FTC programming Tutorial

Java Tutorial https://youtube.com/playlist?list=PLEuGrYl8iBm7wW9gyxpLDhBJAOWDZid1P

1 wk training https://youtube.com/playlist?list=PL98QeHnZpTxEYOd-WWiLPw463JHSS5TjP

at No comments:

coding - naming convention

  To summarize: A range of different samples classes will reside in Project/FTCRobotController/src/main/java/external/samples.

The class names will follow a naming convention which indicates the purpose of each class.

The prefix of the name will be one of the following:

Basic:     This is a minimally functional OpMode used to illustrate the skeleton/structure

            of a particular style of OpMode.  These are bare bones examples.

Sensor:        This is a Sample OpMode that shows how to use a specific sensor.

            It is not intended to drive a functioning robot, it is simply showing the minimal code

            required to read and display the sensor values.

Robot:     This is a Sample OpMode that assumes a simple two-motor (differential) drive base.

            It may be used to provide a common baseline driving OpMode, or

            to demonstrate how a particular sensor or concept can be used to navigate.

Concept:   This is a sample OpMode that illustrates performing a specific function or concept.

            These may be complex, but their operation should be explained clearly in the comments,

            or the comments should reference an external doc, guide or tutorial.

            Each OpMode should try to only demonstrate a single concept so they are easy to

            locate based on their name.  These OpModes may not produce a drivable robot.

After the prefix, other conventions will apply:

* Sensor class names should constructed as:       Sensor - Company - Type

* Robot class names should be constructed as:     Robot - Mode - Action - OpModetype

* Concept class names should be constructed as:   Concept - Topic - OpModetype

### Sample OpMode Content/Style

Code is formatted as per the Google Style Guide:

https://google.github.io/styleguide/javaguide.html

With “Sensor” and “Hardware” samples, the code should demonstrate the essential function,

and not be embellished with too much additional “clever” code.  If a sensor has special

addressing needs, or has a variety of modes or outputs, these should be demonstrated as

simply as possible.


Special programming methods, or robot control techniques should be reserved for “Concept” Samples,

and where possible, Samples should strive to only demonstrate a single concept,

eg: State machine coding, or a User Menu system, and not combine them into a single “all inclusive”

sample.  This will prevent an “all inclusive” Sample being deleted just because one part of it

becomes obsolete.


### Device Configuration Names


The following device names are used in the external samples

 

** Motors:

left_drive

right_drive

left_arm


** Servos:

left_hand

right_hand

arm

claw


** Sensors:

sensor_color

sensor_ir

sensor_light

sensor_ods

sensor_range

sensor_touch

sensor_color_distance

sensor_digital

digin

digout


** Localization:

compass

gyro

imu 

navx


### Device Object Names


Device Object names should use the same words as the device’s configuration name, but they

should be re-structured to be a suitable Java variable name.  This should keep the same word order,

but adopt the style of beginning with a lower case letter, and then each subsequent word

starting with an upper case letter.


Eg: from the examples above:  tool, leftMotor, rightClawServo, rearLightSensor.


Note:  Sometimes it’s helpful to put the device type first, followed by the variant.

eg:  motorLeft and motorRight, but this should only be done if the same word order

is used on the device configuration name.


### OpMode code Comments


Sample comments should read like normal code comments, that is, as an explanation of what the

sample code is doing.  They should NOT be directives to the user,

like: “insert your joystick code here” as these comments typically aren’t

detailed enough to be useful.  They also often get left in the code and become garbage.


Instead, an example of the joystick code should be shown with a comment describing what it is doing.

at No comments:
Subscribe to: Posts (Atom)

We are the Winner at the regional tournament !

  https://youtu.be/mseGfEwSrX4