2018:Programming

From 1511Wookiee
Jump to navigationJump to search
General programming stuff relevant to all subsystems should be documented here.

Outstanding Tasks - Robot Code

Split up by subsystem - responsible veteran student in (), student(s) doing actual code, if different, in []. These are not in any particular order!

  • Review questions for mechanism teams and get answers (Kate, Ethan)
  • Document on Wiki (or link to gdocs) autonomous modes. Include Names/Number assignments for Dashboard/Controls to use (Kate, Josh)
  • Controls: document which specific model of gamepads we will use this year on the controls wiki (Kyle)
  • Controls: Get details on to IO map wiki page for both game pad operations  (Kyle)
  • Controls: Implement controls code on robot (Kyle)
  • Drive: Test/Evaluate new gyro (SPI-based interface instead of analoggyro - already installed on test board) (Josh)
  • Drive: Examine auto modes and decide what range(s) of auto driving actions need to work the best, then make them happen (Josh)
  • Auto/Vision: Where on robot do(es) camera(s) need to go? Document on Robot Design page on Wiki and talk to relevant design teams so they carve out that place!  (Kate)
  • 2/12 Code Review Feedback:
    • thunderbot:
      • Disabled() calls reset() on drive, but not on any other subsystem.  Should it?
      • Same for Autonomous() and OperatorControl()
      • Autonomous does not call cube's process()?
    • Intake:
      • Rename motor variables from motor1, motor2 to motorleft, motorright or similar, following assignments on wiki iomap
      • Need "broken" for intake sensor, and associated code changes to allow driver to override if sensor seems broken
      • reset() does not reset the Position - should it? If this is added, also set the solenoid to match!
      • Turn off motors in reset()
      • Set brake/coast mode for all Talons
      • Add debug for deployed sensor state
      • Probably need to add stall prevention code (watch for current spikes and turn off motors briefly - see 2016 scaler/2017 climber for how to do this)
    • Arm
      • Why a manual brake setting? Why does setArmSpeed() require manual brake control (if speed == 0 brake, else don't brake)?  You already have auto-brake control code that would do this for MANUALMODE
      • What does isCubePresent() do if cube sensor is broken?
      • What does isArmInFront() do if potentiometer is broken?
      • Set initial value for Brake solenoid to "brake"
      • Brake should be turned on in reset()
      • Set brake/coast mode for all Talons
      • Brake control should all be done under process, and only disengaged when about to actually move.  Only process() is making that decision, so brake control all belongs there. Right now the brake would fire in/out rapidly when you were commanding to go to a position and were already there.
      • All the manual control probably needs to be rethought a bit -- the interactions of setArmSpeed and setArmPosition(MANUAL) should be considered. I'd suggest removing MANUAL from the armPosition enum and then have a separate state variable that controls solely if in manual or position mode.  Then setting a (manual) arm speed can force you into manual mode; if you then get a setPosition() then you pop out of manual mode and work on the position.
      • Consider using GetVoltage() instead of GetValue() for the potentiometer readings;  this is often easier to think about when debugging electrically.
      • Polarity on limits and cube sensor is likely wrong;  should go 0 (false) when tripped, true when not tripped. 
      • canmovearm() may want to return true when speed is 0 (for sake of debugging output only; doesn't matter otherwise)
      • Remember that dashboard lists variables alphabetically, and grouping like things can help.  So consider things like "limit_upper" instead of "at upper limit".
      • process() for SLEEP is causing motor to move because atPosition is being set to true, causing goToPosition() to not command the motor with any value (should be 0 presumably!). Setting of _atPosition should probably solely be a function of the pot reading (when not broken) and we should ALWAYS be setting a motor value every every every every every loop to make it clear what happens in all situations!
      • gotoposition() should also respect limit switches! (when they aren't broken)
      • Consider adding isArmInFront()  result to debug output
      • See comment in cube system about control of hand and stopping it when cube becomes present
      • Probably need to add stall prevention code for the hand motors (watch for current spikes and turn off motors briefly - see 2016 scaler/2017 climber for how to do this)
    • Cube System
      • Why is arm variable public?
      • Need "broken" for intake sensor
      • Do not need to duplicate enums for Arm -- you can re-use them (Arm::armPosition type, Arm::SLEEP value)
      • Should the Cube System create Arm and Intake directly and then control them internally?  process(), debug(), broken settings could be cascaded/passed through with more control this way.  Also a lot less functionality for the outside user (controls, auto) to deal with directly.
      • What does SLEEP do?  Process() does not seem to be handling it
      • Why the waffling of _armPosition from desired value back to NEUTRAL in process()?
      • moveArmManually() code is watching for arm in front to control intake, but this might not be repeatedly called -- shouldn't this be in process()?
      • _armBroken handling in process() looks wrong; it will have weird interaction with other code controlling intake I think?
      • process() has code that prevents the intake & hand from running inward if a cube is present, but nothing there stops those motors if the cube later arrives (which, well, hopefully it would!).  Consider moving hand control into Arm maybe?  Keep in mind that, last I knew, the intake can safely continue to run if a cube is in the hand (as it won't be jammed on the motors).
      • Why the prevention of running the intake OUT (spinning it out) if the arm is not in front?  What if you want to repel cubes?
      • Moving of intake will rapidly fire cylinders in broken mode back and forth -- should only be setting intake one position per process() call
    • DriveMeyer
      • Remove all the commented out code! So hard to read!
      • Gyro calibration?  Need to add a means to control when it is done too, and feedback to dashboard when it has NOT been done
      • Why setDriveMode() public? Shouldn't this be internal only (private)? Same with driveState enum
      • state setting is not done consistently.   Should be set in all public methods that control different drive modes?
      • Add debug of raw encoder values
      • Encoder is wrong class; we are only using one phase of the drive base encoders (only one digital input line)
      • reset() should be resetting state as well!
      • Auto straight drive looks to not handle reverse correctly.  Math for speeds & distance checks looks to have wrong signs in a few places
      • Vision turning is setting the wrong variable for motor output
    • Controls
      • Drive controls
        • Why is kDriveYAxisFlipped only applied for !swapDrive case?
        • Better question - why is the dead zoning applied only in swap drive?  Why are the 2 different at all!?
        • Why is turbo and slow done same in 2 places?
      • Aux control
        • Arm control for manual does not match cube system interface -- specifically checking only "at position" is not sufficient
        • No home button (straight up)
        • No control for when broken
        •  
      • Broken control
        • broken cube never gets used?
      •  
  • Old robots: Bring 2015, 2016, 2017 all up to 2018 image and ported code. Test. (anyone, but this is super low priority)
 

Outstanding Tasks - Scouting App

In no particular order!

  • Jeff
    • Update tables classes to define new db schema for 2018 (thunderscout.db package, class ResultsTable)
    • Update EventStorage class to create new tables (EventDbHelper internal class)
    • Update EventStorage class to read/write new tables  (methods getAllSavedMatches() and saveMatchData())
    • Update webserver output to match new match data (Webserver class)
    • New bluetooth sync
  • Alex
    • Feedback from Carol - for scored in switch & scale do the following:
      • Rename DNA to be the verbose version: "Did not attempt"
      • To give more horizontal space and separate things better, move alliance/opponent selections to next line, consider centering them left/right
      • Disable Alliance/Opponent when they don't make sense (you do this by listening to button selections in the Java code for the fragment - see last year commented out code for an example)
      • Default to "Did not attempt"
      • Also default to "Alliance" selected
      • Missing UI for foulCount
      • Should be 2 teleop switch score counts - one for near and one for far
    • FYI - I removed foulComments from ScoutingMatchData since we are not collecting those
    • ScoutingMatchData: check order of read/write to parcel - some of them are out of order!
    • In the data class (ScoutingMatchData) enums for Score, remove "NOT_CHECKED" option;  this is not relevant anymore with defaulting "Did not attempt" to on. The constructor should default score/switch values to "did not attempt" to match the UI.
    • No UI for teleop switch scoring
    • Similar for Scoring on Exchange:
      • DNA should be "Did not attempt" and selected by default
      • Remove "not checked" from data class and default to "did not attempt"
    • For climbing:
      • Make "Not on platform" selected by default
      • Remove "not checked" from data class, default to "did not attempt"
      • Rename the "failed" checkbox to "Climb attempted, but unsuccessful"
    • Add missing files to SVN (on commit screen, click checkbox next to new files) -- ask Mr. Byers or Dan for help if needed!

Controls: Kyle & Adrian & Cameron

DriveMeyer: Josh

Arm/Intake: Kate & Ethan

Ramp: Kate & Josh

Auto: Josh & Kate

Lights: Zack E

Autonomous

Do nothing Cross auto line Sense switch and place cube in switch and cross auto line

Vision

Exchange Color Limits:

  Hue (1-180) Saturation (0-255) Value (0- 255)
Upper Limit 25 234 255
Lower Limit 20 310 25

Programming Sub-pages and Links

Programming Archives

Retrieved from "https://wiki.penfieldrobotics.com/wiki/index.php?title=2018:Programming&oldid=9551"