gwarby / team13460for2023 Goto Github PK

@gwarby sorry for flagging this as an issue BOTH in PR#2 & here. But I'm suggesting we close PR#2 without additional changes, because I thought the merged history would ultimately be cleaner if I merged the branches that PR#1 & PR#2 are reviewing before piling on the Tuesday meeting changes.

Like the title says, the 3 flipper command functions at the end of BlueBackPixel.java are calculating the travel distance, and then the wait time based on the position of the grabber (instead of the flipper).

For the servo "dronelauncher", these positions were used for test firing drones at Tuesday's meeting:

• fire position: 0.15
• loaded position: 0.61

Code from Tuesday not directly committed, as it appears the gamepad controls being used for the dronelauncher potentially conflict with github code for 'ArmToGround / GrabTopPixel / ArmToHolding' that has not yet made it onto the robot.

@gwarby the code in branch "working_code_Dec09_2023":

• Is loaded on the robot
• Updated to use new 'arm limiter' servo / beam:
  • BlueBackPixel (also has untested updates for pixel loading on init)
  • BlueFrontPixel
  • RedBackPixel
  • RedFrontPixel
• Not updated to use the new 'arm limiter':
  • BlueFront (doesn't try to place 2nd pixel)
  • RedFront (doesn't try to place 2nd pixel)

@gwarby
I just experienced the Driver Station presenting a blank list of op modes. This one time it was fixed entirely with the DS by:

1. Use the Android apps tab to shutdown the FTC Driver Station app
2. Use the pull down from the top of the Android screen to turn off DS wifi
3. Turn back on DS wifi
4. Re-open the FTC Driver Station app

Maybe we can add a Debug section to the README in order to close this issue. (Or maybe the drive team can simply read it and delete it.)

@lcdnbl The arm will retract completely autonomously, unsure why. This needs to be resolved before meet 12/30/23. Greatly detrimental to driver 2 during gameplay.

Possible this is a result of build failure, but needs to be resolved.

Vision was recently updated so that as small, overlapping rectangles are scanned, in addition to keeping track of the maximum blue or red chroma, the minimum is also tracked. But the if statement in the minimum is erroneously comparing each value to the current maximum.

This should be addressed once the RedBackPixel.java code is updated with PR #8 (in both BlueBack & RedBack).

After the Saturday session (11/25/2023) when we got all 6 red & blue back auto positions working, I found the min_chroma calculation in vision was wrong again, and have fixed it (directly on the main branch).

This issue is just a reminder to confirm vision calibration is good (or adjust it). These lines in particular:

BlueBack:

RedBack:

@lcdnbl I would be most grateful if you were to upload the updated code from yesterday. Please and thank you.