search

FRC2706 / 2019-2706-Robot-Code

The main robot code for the FIRST 2019 challenge: Deep Space
MIT License
2 stars 0 forks source link

Deal with possibility of ejecting hatch while elevator is at its lowest position #109

Closed KyleRAnderson closed 5 years ago

KyleRAnderson commented 5 years ago

One of the thing requested in the priority email was to automatically lift the elevator when it hits the limit switch. I would like clarification on two things for this: A. Why is this useful? B. How much does the lift need to be raised?

Otherwise this should be pretty easy to implement. It would most likely be done in the HoldLift command, which would just check if the limit switch is being pressed and if so raise the hold position a little and then you're done. The operator will always be able to lower the lift however.

kevlam2706 commented 5 years ago

You’ll have to talk to the Drive team to confirm, but I have a few speculations as to why they want this.

One speculation is that the bottom of the lift travel (where the lift hits the limit switch) is not a useful setpoint as far as the game is concerned. The lowest level we want the lift to be at, when playing the game, is at the feeder station level. So maybe it is useful to say “yes, ok, we have found the bottom of the lift and zeroed the encoder, now we should head back up to the first useful setpoint”.

My counter argument to this is that if we are using PID hold for the entire match, we need to make sure that we’re not heating up the motor too much. Nice thing about the bottom of travel is that you can leave the lift there without powering or stalling the motor. The other thing is that hitting that limit switch recalibrates the cable every time, and holding at a position above it raises the question of when would we ever hit the limit switch...

Another speculation is that this would be required for the hatch ejection cycle since it is supposed to go OUT->DOWN, then IN->UP. There needs to be always enough travel to be able to go down, or else we don’t let go of the hatch cover.

On Mar 3, 2019, at 10:55 PM, Kyle Anderson notifications@github.com wrote:

One of the thing requested in the priority email was to automatically lift the elevator when it hits the limit switch. I would like clarification on two things for this: A. Why is this useful? B. How much does the lift need to be raised?

Otherwise this should be pretty easy to implement. It would most likely be done in the HoldLift command, which would just check if the limit switch is being pressed and if so raise the hold position a little and then you're done. The operator will always be able to lower the lift however.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

KyleRAnderson commented 5 years ago

All good ideas.

My largest concern however is that if we were to implement this, the operator would NEVER be allowed to put the lift at the bottom and keep it there. The bottom setpoint is already intended to go to the feeder station, the operator can use that to go there. Overriding the operator like this usually ends in confusion and/or frustration.

On Sun, Mar 3, 2019, 23:13 Kevin Lam notifications@github.com wrote:

You’ll have to talk to the Drive team to confirm, but I have a few speculations as to why they want this.

One speculation is that the bottom of the lift travel (where the lift hits the limit switch) is not a useful setpoint as far as the game is concerned. The lowest level we want the lift to be at, when playing the game, is at the feeder station level. So maybe it is useful to say “yes, ok, we have found the bottom of the lift and zeroed the encoder, now we should head back up to the first useful setpoint”.

My counter argument to this is that if we are using PID hold for the entire match, we need to make sure that we’re not heating up the motor too much. Nice thing about the bottom of travel is that you can leave the lift there without powering or stalling the motor. The other thing is that hitting that limit switch recalibrates the cable every time, and holding at a position above it raises the question of when would we ever hit the limit switch...

Another speculation is that this would be required for the hatch ejection cycle since it is supposed to go OUT->DOWN, then IN->UP. There needs to be always enough travel to be able to go down, or else we don’t let go of the hatch cover.

On Mar 3, 2019, at 10:55 PM, Kyle Anderson notifications@github.com wrote:

One of the thing requested in the priority email was to automatically lift the elevator when it hits the limit switch. I would like clarification on two things for this: A. Why is this useful? B. How much does the lift need to be raised?

Otherwise this should be pretty easy to implement. It would most likely be done in the HoldLift command, which would just check if the limit switch is being pressed and if so raise the hold position a little and then you're done. The operator will always be able to lower the lift however.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FRC2706/2019-2706-Robot-Code/issues/109#issuecomment-469112488, or mute the thread https://github.com/notifications/unsubscribe-auth/AVjzECM3rHZOk5p04kysqyF6imSQHYqAks5vTJ12gaJpZM4bbgGK .

kevlam2706 commented 5 years ago

Yep. I agree.

So the practical issue to overcome is what would happen if you try to eject the hatch when you are at the bottom of the elevator travel. You can’t go down any more to let go of the hatch. This means you risk breaking the fingers and you can’t let go.

Options:

I agree that whatever we choose has to be simple, especially with potentially multiple operators.

On Mar 3, 2019, at 11:22 PM, Kyle Anderson notifications@github.com wrote:

All good ideas.

My largest concern however is that if we were to implement this, the operator would NEVER be allowed to put the lift at the bottom and keep it there. The bottom setpoint is already intended to go to the feeder station, the operator can use that to go there. Overriding the operator like this usually ends in confusion and/or frustration.

On Sun, Mar 3, 2019, 23:13 Kevin Lam notifications@github.com wrote:

You’ll have to talk to the Drive team to confirm, but I have a few speculations as to why they want this.

One speculation is that the bottom of the lift travel (where the lift hits the limit switch) is not a useful setpoint as far as the game is concerned. The lowest level we want the lift to be at, when playing the game, is at the feeder station level. So maybe it is useful to say “yes, ok, we have found the bottom of the lift and zeroed the encoder, now we should head back up to the first useful setpoint”.

My counter argument to this is that if we are using PID hold for the entire match, we need to make sure that we’re not heating up the motor too much. Nice thing about the bottom of travel is that you can leave the lift there without powering or stalling the motor. The other thing is that hitting that limit switch recalibrates the cable every time, and holding at a position above it raises the question of when would we ever hit the limit switch...

Another speculation is that this would be required for the hatch ejection cycle since it is supposed to go OUT->DOWN, then IN->UP. There needs to be always enough travel to be able to go down, or else we don’t let go of the hatch cover.

On Mar 3, 2019, at 10:55 PM, Kyle Anderson notifications@github.com wrote:

One of the thing requested in the priority email was to automatically lift the elevator when it hits the limit switch. I would like clarification on two things for this: A. Why is this useful? B. How much does the lift need to be raised?

Otherwise this should be pretty easy to implement. It would most likely be done in the HoldLift command, which would just check if the limit switch is being pressed and if so raise the hold position a little and then you're done. The operator will always be able to lower the lift however.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/FRC2706/2019-2706-Robot-Code/issues/109#issuecomment-469112488, or mute the thread https://github.com/notifications/unsubscribe-auth/AVjzECM3rHZOk5p04kysqyF6imSQHYqAks5vTJ12gaJpZM4bbgGK .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

KyleRAnderson commented 5 years ago

I decided to implement the second case, where the lift goes up if it detects that it is not high enough. This way, when the operator presses the button and expects something to be happening, something will happen and the hatch will be ejected properly.

Implemented in e64164e.