1. Add the feeder code to the CPM subsystem
2. Update the feeder commands so that they now reference the correct subsystem and path

QUESTIONS

• How well does the color sensor work?
• How will the robot approach the control panel and where will the CPM be mounted

ASSUMPTIONS

• 1 Falcon500 used for CPM wheels
• 1 CTRE Mag Ecoder for joint position
• 1 Limit Switch for contact sensor
• 1 Rev Color Sensor
• NavX for robot orientation information

TODO

CPM class methods:

• isEngaged
• getMotorPosition
• setMotorVelocity
• setMotorPosition
• getJointPosition
• getRobotFacing
• getColor
• getFMSColorTarget
• calculatePositionControlPath or helper methods

CPM Commands:

• Stop
• Spin (direction)
• Deploy
• Retract
• RotationControl
• PositionControl

** First look - As Built - Inspection **

• Visual inspection
• Battery Check
• Turn on
• Check for shorts/smoke
• Check the RSL
• Check CAN lights
• Check RIO Lights
• Check Radio
• Connection to robot - (FRC Driver Station)
• Check CAN IDs + Firmware
• Deploy Code to Robot (Drive Branch)
• Spin wheels and check encoder data
• Check NavX Data
• Check Limelight - updates
• Visually inspect robot and verify "As Built"parts list against software robot configuration (# motors, motor types, encoder ) Record any differences with software manifest

** Robot First "drive/move" readiness**

• Robot on blocks, wheels above the ground (No contact with blocks or floor)
• Operator ready to disengage robot (finger on the enter button)
• Enable robot
• check RSL
• Check compressors for leaks
• test drive
• Disable robot
• Merge drive to master and prep intake branch

** Robot Intake Test **

• Deploy intake branch to robot
• Robot on blocks, wheels above the ground (No contact with blocks or floor)
• Enable robot
• check RSL
• Check compressors for leaks
• test intake command
• test deploy and retract commands
• test run/eject/stop
• test safety features
• Disable robot
• Merge intake branch with master

** FASH **

• Catchup the FASH branch w/master
• Deploy the FASH branch to the robot
• Check arm sensor data
• Comment out the hopper, shooter, subsystem
• Note/record arm positions for full up, full down and mid (these will be turned into soft limits later
• Test with basic control (check for current spikes at up and down motions)
• Tune for motion magic

** Hopper + Shooter **

• Deploy hopper shooter branch to robot
• Robot on blocks, wheels above the ground (No contact with blocks or floor)
• Test Flywheel sensor data
• Test Hopper + feeder sensor data
• Enable robot
• Check RSL
• Test basic control of flywheel, feeder, hopper
• Tune flywheel for velocity PID
• Test with power cells (balls)
• Merge to master

TODO

• Climber Subsystem Analysis
• Create a climber subsystem
• Add climber motor encoder positions to dashboard data
• Haiku

ACTUATORS

• Two Falcon500s

SENSORS

COMMANDS

• Extend Climber
• Retract Climber
• Stop Climber

Climber: add tilt controls for dual arm climber

All the operator lower one side or the other of the climber to position the hooks in the proper position.

Moving left - lowers left
Moving right - lowers right
Moving up - raises both
Moving down - lowers both

The following subsystems needs to be added to the code and an issue should be created for each outlining necessary components, class methods and commands,

• Drive
• CPM
• Climber/Balancer
• Intake
• Indexer
• Shooter
• Arm
• Lights
• Vision

TODO

• Shooter Subsystem Analysis
• Create shooter subsystem
• Shooter/Intake/Hopper/Arm subsystem coordination
• Haiku

ACTUATORS

• 2 Falcon500 motors for main shooter wheel
• 1 775 Pro for feeder belts

SENSORS

• Falcon500 interal encoder to be used for shooter
• No encoder for feeder belts?
• ShotCountSensor
  ** beam break or IR sensor to count balls leaving the shooter

Shooter Arm:
The arm will be controlled by a separate arm subsystem. The shooter will need to know what the current arm position is.

COMMANDS

• ShooterPrep
• Shoot
• ShooterStop

METHODS

At the start of every cycle

the full sequence of events...

• Get the encode value and pass this in to encodeTicksToArmDegrees
• Do the math mod function ((encoderValue + 15 ) mod 120) - 15
• take the results of that calculation
• pass that into arm degrees to motor ticks
• then set the talon sensor position to the value that we've calculated it to be.

Note:

• For functions like "armTicksToArmDegrees" value should be adding the offset then multiplying the the result by 120/1024

Constants

• 120 degrees (360 degrees in a full circle, but we have a 3:1 ration from the encoder to the actual arm shaft.
• 1024 is ticksPerArmPositionEncoder rotation
• 15 gives us some level of shift and allowances on either side

Create a button box class and map buttons to commands.

If we approach the control panel from the side we may not be in a save position and our ability to identify our current detected color and the color under the sensor may be more complicated.

• if the driver is controlling our ability to find a color, this may be the easier position for that strategy

If we approach from the trench me may be more protected and have more landmarks that will enable us to identify how to translate the current color we see to the current color that is under the sensor. (off by 2?)

A subsystem should be created to manage communication with our lights system, likely an Arduino connected via USB to the RoboRio. This subsystem should use data available to the robot to determine a desired light pattern and then send a message to the Arduino to change the lights to that pattern.

Some suggested robot states and their light patterns:
Disabled - rotating multicolor (extra credit...no green!)
Shooter on target - fast multicolor chaser
Hanging, unbalanced - flashing alliance color
Hanging, balanced - solid alliance color

• Test Roborio to Arduino communications via USB.
• List robot states where a light pattern is desired and determine sensor data needed
• Determine desired light patterns for states where all necessary data is available
• Develop new light patterns on Arduino as needed

Button 1 Shooter

• Shoots while held and system is ready to shoot

• Lights
  ** Light on when robot ready to shoot
  ** Light off when robot is not ready to shoot
• Actions
  ** User can hold button down when light is off and robot will shoot when ready
  ** Button must be held to shoot
  ** when button is released, shooter will not shoot

Button 2 Arm Up

• Lights
  ** Light is on when Arm can be moved up to one of its shooting positions
  ** Light turns off when arm is in motion and when arm cannot be moved

• Actions
  ** On-press (single tap) of button, robot moves arm up and starts bringing the flywheel up to speed for shooting.

Button 3 Arm Down

• Lights
  ** Light is on when Arm is in one of its shooting positions and when then Arm can be moved down.
  ** Light is off when Arm is moving downward, has reached it parked/home position or cannot be moved down for other reasons (shooting)
• Actions
  ** On-press (single tap) of button, robot moves arm down and slows/stops flywheel.

Button 4 Intake

• Lights
  ** Light is on when we are not full and when we are able to take in more power cells
  ** Light is off when we are full or when we cannot take in more power cells.
• Actions
  ** When pressed and held - Deploys the intake and runs the motors to start intaking power cells
  ** When released - stops the intake motors and retracts the intake into its stowed position.

Button 5 CPM - Rotate Color Wheel

Button 6 CPP - Move Wheel to Target Color

Climber - Arcade Joystick

• Uses arcade joystick control with % output to move the climber arms up and then tilt left or right

Climber - Ratchet Switch

• Toggle switch to engage ratchet

TODO

• Drive Subsystem Analysis
• Accept outstanding pull request to pull in some of last year's code
• 2x2 Falcon 500 Tank
• Dashboard data
• Closed loop tuning
• Autonomous motion: Targeting
• Autonomous motion: Path following
• Haiku

ACTUATORS

• 2xFalcon500 w TalonFX per side
• 1 double solenoid per side for shifting

COMMANDS

• ArcadeDrive
• TankDrive
• AutoDrive
• Aim

Climber: Stop motion if climber arm is pushing against object during extend command

If by chance we are extending the arm and pushing against the obstacle, then we want to 1) stop pushing 2) alert the operator

We discussed having the driver controller rumble when the command is complete so that they know that they can driver away or start the next operation.

We discussed causing the driver controller to rumble when we've completed command to move to the right color. This will allow them to leave the trench and move on to something else as soon as possible.

Shooter Arm:

• It was discussed that there would be two positions for the shooter arm to handle different types of shots

Components

• 1 Falcon FX motor
  ** Each Falcon has its own encoder
• absoluteArmAngleEncoder
  ** encoder mounted below the bottom of the shooter elbow to measure the angle of the shooter.

TODO

• haiku

Methods

• encoderTicksToArmDegrees
• armDegreesToEncoderTicks
• encoderVelocityToArmVelocity
• armVelocityToEncoderVelocity
• getArmPosition (angle)
• setArmPosition (this uses motion magic)
• moveArmPosition (this uses basic % output)

COMMANDS

• moveToShootingPositionOne - for shot profile 1
• moveToShootingPositionTwo - for shot profile 2
• moveToHomePosition - fully stowed, pregame position
• moveToPosition - using motion magic
• arcadeMoveToPostion - using the joystick, use basic control to move to a position - discussed for testing and calibration
• emergencyResetArm - see safety noticed below

SAFETY

If we find that we are over our buffer limit (+/- 15 degrees) then we
will stop the ARM, have the operator initiate an overide and move toward the limit switch to reset the arm (position)

TODO

• Intake Subsystem Analysis
  Design of an over the bumper intake system that was discussed at the build meeting on 1/21/2020
• Haiku

QUESTIONS

• Will there be another roller with motor to see that the balls are kept safe in the holding area (a.k.a The Shepard) = NO

ASSUMPTIONS

Actuators:

• 1 roller motor: 775pro motor, with TalonSRX controller
• one double solenoid

Sensors:

COMMANDS

• Intake
• Eject
• Deploy
• Retract
• Stop

METHODS

• setRoller - takes value -1 to 1 and sets the roller speed based on that value.
• deploy - moves the intake mechanism from its pregame starting position into the position where it can start retrieving balls.
• retract - moves the intake mechanism from its deployed position to its stowed position

TODO

• Storage Subsystem Analysis
• Haiku

ACTUATORS

• 2 775 Pro motors running left and right side belts which move the balls in a holding area. The forward direction is towards the shooter and the reverse direction is towards the intake.

SENSORS

• Versa mag encoders on each 775.
• Camera looking at hopper to count how many are loaded

COMMANDS

• Intake - runs agitators in optimal intake pattern
• Shoot - runs agitators in optimal shooting pattern
• Stop - stops the agitator

METHODS

• setAgitators (speed1, speed2)
• Power cell count - uses camera to count power cells in the hopper.

Some examples could be
Reset CPM
Deploy CPM
Retract CPM
Get current color under robot's sensor
Get current color under CPM field sensor
Rotate wheel clockwise ( some number of units)
Rotate wheel counter-clockwise (some number of units)
Stop wheel rotation

Climber: Stop motion if climber arm is pushing against object during extend command

If by chance we are extending the arm and pushing against the obstacle, then we want to 1) stop pushing 2) alert the operator

Implement driver preferences to support changing rotation count on driver station. See Paul T. for details.