Testing Checklist

Background: This checklist is mostly focused on the system-level integration and testing needs reflected from on-the-field robot performance and driver needs. Assumption is that each subsystem will verify their operations at a granular level (such as intake start/stop intake motors) which is not covered here.

• Priorities
• Dashboard
• Autonomous
• Vision + Driver Cameras
• Launching Fuel Cells
• Harvesting Fuel Cells
• Control Panel Spinner
• Climber

Priorities

These items are from the driver perspective.

• High-speed trench run and control panel alignment

  • Driver controls for auto-steering support -- Q: is there a need for ultrasonic sensor?
  • For Control Panel alignment, additionally robot slows down/stops when control panel mechanism is actuated

• Control Panel rotations and positioning feedback to drivers

  • Verify that while control panel mechanism is actuated robot acceleration/speed is reduced
  • While the robot can handle the rotations, driver team is responsible for alignment and verification that task is complete. This includes accurately aligning w/ Control Panel for color sensor operation, and acknowledging when the task is completed which is announced via the Control Panel lights.
    • Verify that the driver camera supports aligning the robot with the Control Panel
    • Verify that the driver camera supports visual feedback on the Control Panel lights
    • Verify that the driver camera supports visual feedback on Control Panel rotations+alignment
  • Q: When Control Panel tasks completed and time to lower the mechanism, should the robot backoff automatically from the Control Panel?

• Test drive fuel ball intake process

  • Validate that the driver camera aids the fuel ball detection+intake
  • Validate IF there is a need to update the intake design for more efficient harvesting
  • Validate stored fuel cells/balls do not interfere with Climber

• Test drive automatic and ?manual? launch process

  • Validate the use of Dashboard visuals to show target-in-range
  • Q: Is there a Launch Mode that indicates IF automatic launch is on/off mode? And, is that mode shown on the Dashboard? -- assumption is that there maybe times where it is strategic to control when to shoot

• Climber

  • Validate driver camera to aid in robot positioning and hooking the Climber
  • Can the climber mechanism support the robot?
    • Verify that the hook doesn't slip
    • (Not sure what this means, pls clarify) Does our reliability depend on our height from the ground?
  • Which is more reliable, the automatic or manual raise / lower?
    • How likely is it that we hook onto the wrong height?
  • How is the durability of the climb system?
    • If we run into the hanging bar, is the climber okay?
  • Does the climber run at the correct speed?

Dashboard

• Dashboard subsystem capabilities are sprinkled into the rest of the document. Q: Is it useful to restate them here?
• Q: What are the system diagnostics at a glance?

Autonomous

• Verify Dashboard displays the Autonomous paths + Alliance color and selectable
• For all autonomous paths:
  • Test auto path + shooting 5 balls
  • If exists, test picking up additional balls + shoot

Vision + Driver Cameras

• For all drive cameras, verify proper networking handshakes
  • Test front drive camera on 10.49.15.11:5805
  • Test back drive camera on 10.49.15.12:5805
  • Test up drive camera on 10.49.15.13:5805
• For driver cameras verify:
  • Manual and auto switching off the driver camera during teleOp
  • Switching between 3 drivers cameras is operational
    • Q: In what order should the 3 cameras be switched?
    • Q: Should the driver be given more direct control of the cameras (I.E: I want 'up' camera now, ect.)
  • Bitrate for each individual stream is less than 4Mbit/s (assuming lazycleanup is set to false)
• For vision camera verify.
  • Dashboard indicator showing boolean target-in-range visual.
  • Vision 'status' networktables key is responsive to target acquisition. (Vision/State/<state> (string))
  • Vision target delivery key (Vision/Target/Result/<result> (double array of ((x,y,z),t)) ) can be read by robotCode.
  • Vision light ring relay is operational. (likely simple button test)
    • Nb: The relay will be left 'on' during the match, but it is worthwhile to test its functionality.
  • Vision code can read robotState timestamp.
  • Robot -> Turret -> Camera Measurements.

Launching Fuel Cells

This includes Launcher (turret+hood) and Indexer operations. Note: Vision is required for accurate shooting. However, this section assumes life is grand 🤘.

• Verify Dashboard controls+information

  • Verify the ball count correctly reflects the number of balls the robot is holding after each launch
  • Verify target-in-range is displayed correctly
  • Q: If there is a auto launch mode -- the launch status is correctly displayed

• Verify the motors and sensors are operational

  • Turret motor and encoder operational -- hard limits are obeyed
  • Launcher hood and encoder is operational -- hard limits are obeyed
  • Indexer's launcher ball is operational and spins as expected
  • Q: if there is a reset() method, it resets as expected, including encoder values
  • Q: what should be the Launcher (turret+hood) physical position @ robotInit() --> are they autonomous position dependent?

• Test Launcher controls -- automatic tracking and launch

  • For # of balls in the system, verify that:
    • Launcher coordinates and moves itself to the launch coordinates and shoots
    • Indexer rotates the spinner accordingly and positions the next ball for launching
    • If there are 5 balls, Indexer moves the 5th ball from ball held position accordingly
  • Q: What is the expected behavior if Launcher is interrupted? I assume it'd turn off 'auto launcher mode'

• Q: is there a manual mode for launch? If so add: Test Launcher controls -- manual tracking and launch

• Q: Is there a check for stall current to determine if ball is stuck? If so it should notify driver on the Dashboard and do what to unstuck itself?

• Q: Once the system operation is verified, decide If/how any speed optimizations are required for better cycle times

Harvesting Fuel Cells

This includes Intake to Indexer operations.

• Verify Dashboard controls+information

  • Q: Is there a ball count status on the Dashboard? If so make sure the applicable autonomous modes sets up the defaults
  • Q: If there is ball stuck notification on the Dashboard, check the driver readability of the notification

• Verify the motors and sensors are operational

  • Verify the motors and encoders are spinning in the expected direction
  • Verify the distance traveled for spinning a single index
  • Verify that the ball held sensor is positioned for holding balls
  • Verify indexer's ball sense sensor is sensing ball in/empty conditions
  • Verify reset operation correctly aligns the indexer position
  • Verify robotInit() resets the physical hw to required setup --> Q: is there an algorithmic dependency on how the indexer is positioned at startup?

• Test Intake

  • Intake a single ball and verify ball is held
  • Verify that while ball is held is TRUE, Intake will NOT harvest any balls --> Q: is intake motors automatically turned off?
  • Test fuel ball stuck mode for releasing/unsticking a ball
  • Verify stall current drop when ball is stuck and that it:
    • Notifies the dashboard and alerts drivers w/ affected motor
    • Stops associated motor(s) immediately --> Q: assumption is that drivers are responsible for the next step as getting unstuck may not be simple

• Test Indexer

  • Verify indexer reliably turns by quarters
  • Verify stall current drop when ball is stuck and that it:
    • Notifies the dashboard and alerts drivers w/ affected motor
    • Stops associated motor(s) immediately --> Q: assumption is that drivers are responsible for the next step as getting unstuck may not be simple
  • Q: Is there an indexer unstuck mode? If so, reset the expected indexer position based on ball count

• Test bulk Harvest -- from 1 to 5 ball intake

  • Verify Indexer correctly harvests balls until interrupted or indexer is full
    • For each case, verify dashboard correctly displays the ball count
    • Verify 5 ball harvesting --> and intake automatically shuts off
    • Verify 4 ball harvesting
    • Verify 3 ball harvesting
    • Verify 2 ball harvesting
    • Verify 1 ball harvesting
  • If Harvested < 5 balls and got interrupted for some reason, verify system can harvest to 5 balls correctly. Validate the dashboard count updated accordingly
    • Verify 4 ball interrupt picks up the 5th ball
    • Verify 3 ball interrupt picks up 2 more balls
    • Verify 2 ball interrupt picks up 3 more balls
    • Verify 1 ball interrupt picks up 4 more balls

• Q: Once the system operation is verified, decide IF any speed optimizations are required for better cycle times --> mostly relevant for autonomous operations w/ > 5 ball shoot

Control Panel Spinner

Important notes:

• Use driver station to specify FMS colors for testing
• Q: Assumption is that panel rotator is raised and motor is stopped but touching the physical Control Panel in order to start the rotation commands.
• Note, Priorities section highlights the following driver input that is required:
  • For safety: Reduce driving speed (or stop) before raising the mechanism
  • Centrally align the robot under the control panel for sensor readings

• Verify Dashboard controls+information

  • Q: Is there a 'FMS Color' notification on the Dashboard? If so verify readability
  • Q: Is there a task status information on the Dashboard? If so verify task completion for rotations and positioning

• Verify the motors and sensors are operational

  • Verify motors and encoders are spinning in the expected direction
  • Verify the limit switch/optical flag's values aren't reversed
  • Verify color sensor is operational

• Press the lifting/raise button

  • If implemented safety, verify robot slows or stops prior to lifting during teleop

• Press the lower button

  • Q: Can the mechanism lower while under the control panel? Is there a safety to prevent it?
  • Verify the panel rotator doesn't accidentally spin the wheel when lowering --> Q: does the 'lowering' action first move the robot backwards for some set amount?

• Press the spin to color button. For all 4 colors (red, blue, green, yellow)

  • Verify dashboard displays the FMS color
  • Verify the panel color positions correctly
  • Q: IF there is a Dashboard 'success' notification on task completion, verify correctness
  • Q: Agree w/ driver on when to move away from control panel: is there room for error when we back away? --> assumption is robot would back off ONLY when the task is completed as stated by the FMS color or if there is a tactical/strategic need (ex. malfunction, or time to climb, ...)
  • Q: Test interrupts, what happens if driver presses a button requiring the control panel subsystem?

• Press the spin for number of rotations button --> expected 4 full rotations

  • Test the automatic control panel color rotation button, i.e. happy path of 4 rotations
  • Q: IF there is a Dashboard 'success' notification on task completion, verify correctness
  • Q: Test interrupts: what happens if driver presses the 'rotation' button a 2nd time?
    • (@binnur) Rotations should queue when the driver presses the 'rotation' button multiple times. --> @j-james, is that mean FMS will count more than 5 rotations, which will reset the rotation count to 0?

Climber

Important notes:

• Climber operations assume visual inspection/control by driver to 1) place the robot for climbing; 2) extend the lightsaber to right height

• Verify Dashboard controls+information

  • Q: What information is shared on the dashboard? Stall current detection?

• Check that the motors are operational

  • Verify that the lightsaber motor extends / retracts in the right direction
  • Verify the winch winch in the right direction?
  • Verify stall current detected to start winching
  • Verify that running the extend command for too long won't break the lightsaber
  • Verify that the hook properly detaches from the lightsaber

• Verify the Climb action + buttons

  • For each supported automatic button (min and max), test
    • Lightsaber moves to the desired height and hook properly detaches from the lightsaber
    • Climber automatically starts winching when stall current detected
  • Test manual extend and Climb operation
    • Driver controls the Lightsaber height and hook properly detaches from the lightsaber
    • Climber automatically starts winching when stall current detected