Supercycling implementation #170
Conversation
|
The ground intake moves out of the way, but if a coral is held, the coral gets stuck on the carriage when it goes from L3 algae intake to ground algae intake. The ground spinny does not stop when a coral is loaded into it, and is tearing up the wheels. I tried counteracting that by changing the default command to only run the wheels if not stalled, but that does not work (either my skill issue, or the stall current threshold is incorrect). The ground arm also moves really slow, but I ran out of charged batteries to keep testing. |
|
Ground intake sometimes does not deploy when hitting driver controller b while in coral mode. Ground intake spinny still tears up wheels no matter what mode it is in. |
|
This should have fixed the ground intake issues experienced last drive practice, and will be the one tested at the start. If not, the climb pivot branch will be run. |
| Commands.deferredProxy( | ||
| () -> | ||
| switch (sensors.intakeSensor.inIntakeSwitchable()) { | ||
| case 1 -> Commands.sequence( |
There was a problem hiding this comment.
Is there an enum for this? Try to avoid numerics in a switch to ease future maintenance.
| getAlgaeIntakeCommand()) | ||
| // If we are supercycling (have a coral), hand it off and switch | ||
| // to coral mode | ||
| Commands.deferredProxy( |
There was a problem hiding this comment.
This is the same code as above. Instead of duplicating code move it to it's own routine, then call that routine.
|
|
||
| public int inIntakeSwitchable() { | ||
| double distance = getSensorDistance().in(Meters); | ||
| return (distance > INTAKE_LOWER_LIMIT && distance < INTAKE_UPPER_LIMIT) ? 1 : 0; |
There was a problem hiding this comment.
Instead of 1 or 0, use enums or true/false returns.
| motorLeft.set(CLIMB_OUT_SPEED); | ||
| setSpeed = CLIMB_OUT_SPEED; | ||
| pError = minTargetPos - getClimbPosition(); | ||
| if (pError > 0) { |
There was a problem hiding this comment.
Is a pError of 0 realistic or is there some minimum variance, e.g. (pError > 0.001)
There was a problem hiding this comment.
We haven't had any issues with variance or inaccuracies of this sort during drive practice yet. Not saying it isn't possible, but in the ~7 hours of practice that we've been running this, its been precise enough for our use case. Regardless, ill look into any possible causes of variance in the code. (For context, I wrote the Climb pivot subsystem, and while Tristan wrote the PID stuff, I understand it entirely)
FYI, these funnel PID changes were merged earlier in a separate PR, and are only present here because we wanted to test it all on one PR before it was merged. Feel free to make an Issue about any code logic errors or faults you see though! We watch the issue list frequently. (Im just going to put this on all of the climb comments here)
- Connor, Drivebase and Climb software leads
| setSpeed = CLIMB_OUT_SPEED; | ||
| pError = minTargetPos - getClimbPosition(); | ||
| if (pError > 0) { | ||
| speedToSet = CLIMB_OUT_SPEED * pError * climbOutKp; |
There was a problem hiding this comment.
Is your intent for speed to slow as it gets closer to the target? Why is that necessary as opposed to consistent speed on this.
There was a problem hiding this comment.
Yes, so that it gets to the target accurately and efficiently without overshooting. We had consistent speed before, but it frequently overshot and wasnt precise, so we added a PID loop (actually just P in the climb, but normally contains PID as well) as you can see in the code.
FYI, these funnel PID changes were merged earlier in a separate PR, and are only present here because we wanted to test it all on one PR before it was merged. Feel free to make an Issue about any code logic errors or faults you see though! We watch the issue list frequently. (Im just going to put this on all of the climb comments here)
- Connor, Drivebase and Climb software leads
| } else { | ||
| motorLeft.set(CLIMB_IN_SPEED); | ||
| setSpeed = CLIMB_IN_SPEED; | ||
| speedToSet = CLIMB_IN_SPEED * -pError * climbInKp; |
There was a problem hiding this comment.
Why is this code needed? Are you trying to set the speed to 0? pError here is 0, so speedToSet will be 0.
There was a problem hiding this comment.
pError is modified elsewhere in the code, which this depends on. FYI, these funnel PID changes were merged earlier in a separate PR, and are only present here because we wanted to test it all on one PR before it was merged. Feel free to make an Issue about any code logic errors or faults you see though! We watch the issue list frequently
- Connor, Drivebase and Climb software leads
| groundSpinny.setGroundIntakePower(), | ||
| // After it's deployed, apply a constant voltage to press it into the bumper | ||
| // and continue. | ||
| groundArm.setVoltage(GroundArm.GROUND_HOLD_VOLTAGE)) |
There was a problem hiding this comment.
What is the impact on battery for this? Is there risk of pulling too much from the battery limiting other actions? Does this reduce battery life?
Just wondering if superCycling will have a negative impact on battery life that needs to be considered or are we doing OK with battery life in competition such that it's a non-issue.
things for #165