mechanical-advantage / robotcode2018 Goto Github PK

The 2018 robot may require more than one PCM. Investigate what is required to use >1 in code.

The spork will require controls and OI support.

DEPLOY: Release pneumatics, spring loaded deployment. Deployment to be by DRIVER (not operator) and require TWO buttons, one on EACH joystick to prevent accidental triggering.

PICKUP: Drive two Talon controlled motors, each with mag encoder. Actual rotation through a small # of degrees with heavy gearing-down. Encoders must not be allowed to drift too far apart. Control by operator or driver button (TBD), "run while held".

STOW: Post-match. Reverse out, then drive in and re-engage pneumatics to lock. Controls TBD.

For situations where quick-and-dirty is good enough, have a variant of TurnToAngle that takes precision as an argument.

Remove bot-bot-isms from camera code on Revenge

Confirm that autonomous sequences use programmed eject power and do not read the current slider value.

Investigate and perhaps implement additional data logging to aid in understanding match behaviors.

Consider the 995 "CsvLogger" class as one possible approach.
https://github.com/FRC-Team-955/Team955RobotLib/wiki/CsvLogger

Consider also the alternative of having a mechanism to send data to the driver station and log it there.

General

• Update CAN id's and names - Talons.
• Update Talon firmware
• Check/update PDP firmware.
• Check out Pixycam operation
• Check out driver cam operation
• Set CAN ID on PCM 2
• Check/update PCM firmware on both PCMs

Drivetrain tuning

• Velocity closed loop - low gear
• Velocity closed loop - high gear
• Check proper shifting pneumatics operation
• DriveDistance
• TurnToAngle
• Motion Profile Tuning - distance and angle coefficients, wheelbase, tolerances, max accel/velocity/jerk, velocity and acceleration feed-forward

Intake

• Proper operation of pneumatics
• Check all controls
• Complete Banner sensor use to detect cube
• Current limits on 775's

Elevator

• Tune Motion Magic constants - both gears?
• Check all controls
• Proper operation of limit switches and encoder
• Set encoder position values
• Proper pneumatics operation
• Investigate if delays are needed
• Set current limits
• Climb sequence operation

For 2-cube autos, add code to actually grab the cube before continuing.

Also determine whether/how to turn off the intake, depending on if Banner sensor is installed.

Work with others to identify controls needed by driver and operator (buttons, joysticks, etc.)

Add code to lower intake during autonomous sequences (and raise off floor if needed).

Set up Komodo analyzer and test its use. Consider creating a Wiki HOWTO for it.

Auto climb:

• driver parks centered on scale, touching wall
• Back up X inches
• Raise elevator (fast)
• Drive forward Y inches - touching bar
• Shift elevator to low gear

Leave ready for climbing under operator control

Modify the range of the eject power slider so that at its bottom position, there is still a minimum usable eject power (instead of 0).

Investigate whether running intake during auto helps to avoid dropping cubes.

General

• Update CAN id's and names - Talons.
• Update Talon firmware
• Check/update PDP firmware.
• Check out driver cam operation

Drivetrain tuning

• Velocity closed loop
• DriveDistance
• TurnToAngle
• Motion Profile Tuning - distance and angle coefficients, wheelbase, tolerances, max accel/velocity/jerk, velocity and acceleration feed-forward

Intake

• Check all controls
• Current limits on all 775's

Scoring Arm

• Check all controls
• Confirm proper limit switch operation

Create the real dashboard layout for competition

Update intake controls so that intake operates as hold-to-operate.

TBD desired behavior of "off" button. May be repurposed for other things!

Consider ways of experimentally supporting a low speed intake to minimize cube "kicking". (This may or may not be used, is something that was suggested to explore.)

One possibility suggested was remapping intake-on to toggle between intake-low and intake-high speeds. There may be other alternatives.

Add ability to drive >8 LEDs to driver station-Arduino protocol.

Proposed solution: use 2 bits/byte for LED group ID, remaining 6 bits for LED states per group. Provides up to 24 LEDs.

Includes auto-stop, sensors, speeds, current limiting/monitoring

For situations where it may be desirable to vary from default values, create a variant of DriveDistanceOnHeading that takes acceptable tolerance, max accel, max velocity as parameters. Set up so that if a passed parameter is 0, the default is used for that parameter.

Remap controls so that

1. intake on/off do NOT lower the intake
2. intake raise becomes a toggle for raise/lower

Switch auto delivery in straight line if on correct side otherwise just cross line.

Ensure that Eject button is run-until-released while Eject in (all) autos is time-terminated

See what may be useful in the CTRE Phoenix libraries (as new functionality is released)

There is discussion of having code available to help teams cross-the-line in auto, to aid in acquiring the RP. For example:
https://www.chiefdelphi.com/forums/showthread.php?threadid=161926

Review this (and related resources such as this: https://github.com/Open-RIO/2018-Minimum-Viable-Autonomous) so as to be in a position to offer alliance members help.

Determine what TalonSRX run time values may be useful in understanding the behavior of the 4 Talons/drive motors, and add these to the driver station dashboard.

Provide a scale-only autonomous option (possibly with an additional variant of "only if same side")

Add LED state outputs to network tables where needed in code

Investigate and understand the Field Management System API for accessing game data.

Provide interface function(s) enabling easy access to necessary data (switch/scale ownership) based on that data.

Make sure that robot autonomous does not get stuck if it hits an immovable object and the wheels won't turn. May require simulating this condition on Everybot since behavior of Revenge's shifting gearbox varies depending on low/high gear setting.

Install necessary software and files on a team laptop so that it can serve as a backup driver station in the event of continued issues with the Surface.

Update auto sequences to include positioning of robot afterward.

• Same Side Scale: back away, lower elevator, position for next cube.
• Opposite Side Scale: back away, lower elevator, position for next cube.
• Center Auto: back away, lower elevator, turn towards outside ready to drive
• Same Side Switch: back away, lower elevator, turn facing downfield

Evaluate others.
Consider whether actual grab of next cube is worth attempting.

Test, tune and debug DriveDistanceOnHeading and TurnToAngle routines.

Beware that WPILib2018 has broken setToleranceBuffer and this may need to be worked around. SetToleranceBuffer is also deprecated so may need to be refactored out eventually anyway.

Restructure the auto selector so that it is not one long list of items (or, at minimum, rename items for clarity).

Now that the code is structured to support 3 robots, fill in all the places necessary for the 2018 competition robot drive to function. Assume tank drive, 2 motors per side, 2-speed gearboxes.

Running into the scale is a tech foul so we should investigate ways of preventing that. Possible ideas include:

• Pinpoint sensor pointed up to detect plate
• Ultrasonic sensor
• Field position tracking
• Detecting white tape on the carpet

Add support for additional, upward-facing camera to be used for scale positioning.

Consider automatically switching to this camera when the elevator is sufficiently high.

Create a version of DriveDistanceOnHeading that takes arguments for max speed and max accel (as % values).

This is probably best done as a variant with a different signature.

As discussed, the logical approach is for the % values to be of robot maximums, e.g. a "normal" DriveDistanceOnHeading was using 90% & 3% respectively. This allows maximum flexibility (can go up as well as down) and avoids "% of a %" confusion.

Investigate any and all possible software issues, data, workarounds, logs that can contribute to understanding and resolving elevator performance (and brownout) issues.

This includes developing (and running/debugging on a test robot) code for testing torque contribution of each motor as suggested by CTRE.

Set up a motion-profile tuning interface in Shuffleboard

The FMS does not report ownership instantly, and the code needs to work around that.

Consult with mechanical team to understand the mechanical design and incorporated sensors, and map these to logical software subsystems to be built.

Try Nvidia vision-learning software to see how effectively it can be trained to track game cubes. This will require feeding it a substantial number of different cube pictures.

Create "for dummies" document with electronics layout:

• Talon functions (which controls which motor)
• PDP channel (==CAN IDs)
• PCM channel mappings - PCM ID, channel ID, physical solenoid, function

Map out auto sequences and selections for 2018 game.

Verify correct operation of "flipped" profile logic for autonomous sequences

Create improved PID tuning interface, possible using Shuffleboard. See if (deprecated) SFX dashboard approach can be retired.

Explore use of PixyCam (training, effectiveness in tracking cubes, HW/SW interface use on RoboRIO)