Determine and solve risk of plunger collision

[KyleRAnderson]

As @GabbyGenereux brought up, there is a possible risk of hitting the "eject hatch" plunger while lowering the intake arms.

Currently we need to know a couple more things before we can begin resolving this issue.

1. How long does the plunger take to retract? Is the time consistent?
2. How long do the arms take to raise? Is the time consistent?
3. In what conditions is a collision possible?

Once we receive a practice bot or feedback from someone who has worked with the robot, we can begin working on it. For now, there is a basic check and call to the retract method but since there is so much unknown it might not do enough.

[GabbyGenereux]

I can hopefully answer some questions:

The risk of collision is if the hatch scorer is pushed out, and the arms go to move up or down. If the arms are already fully extended (aka horizontal) or fully vertical (retracted into the starting configuration) there is no issue. The issue comes with moving the arms when the hatch scorer is already out. Moving the hatch scorer when the arms are already out is okay (as this is how we score the ball anyways).

I can't comment on consistency or timing as you guys will have to find out when you do software testing. :) I imagine everything will be fairly consistent, as both horizontal movements are on pneumatic pistons. The inconsistency will come from lack of air pressure.

On Tue, Feb 19, 2019, 9:42 PM Kyle Anderson, notifications@github.com wrote:

As @GabbyGenereux https://github.com/GabbyGenereux brought up, there is a possible risk of hitting the "eject hatch" plunger while lowering the intake arms.

Currently we need to know a couple more things before we can begin resolving this issue.

1. How long does the plunger take to retract? Is the time consistent?
2. How long do the arms take to raise? Is the time consistent?
3. In what conditions is a collision possible?

Once we receive a practice bot or feedback from someone who has worked with the robot, we can begin working on it. For now, there is a basic check and call to the retract method but since there is so much unknown it might not do enough.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FRC2706/2019-2706-Robot-Code/issues/87, or mute the thread https://github.com/notifications/unsubscribe-auth/AC_lkHx-nSGEWQeH8gme859j0PoGBwR8ks5vPLYbgaJpZM4bESMG .

[kevlam2706]

The timing will depend on the working pressure (which is a dial that we can set), the ACTUAL available pressure (when the air tanks are low, the available pressure will be less than the desired working pressure) and the settings of the flow restrictors that are attached to the cylinder (another dial that we can set). So, yes, we can come up with an average time for the hatch scorer to move in and out, but this will change as soon as someone changes the dials - which could happen in the pit by the pit crew or the drive team looking to speed up the hatch scoring, or diagnose some problem with the Velcro, or dropping hatches, etc.

I suggest you set a configurable delay parameter, start with something nice and healthy like 1 second. From the moment you issue the command to retract the hatch scorer, start the timer, and do not allow the intake arm to be moved during this time. We can then experiment to see how small we can safely make the delay. It would be nice if this delay parameter could be set easily from the driver station, and saved for future matches (not sure if your FluidConstants supports this).

The delay might well be 0 because it will also take the intake arms a finite amount of time to reach the halfway point of its swing which is where the collision would occur. And the same flow restrictor valves exist on those arms as well, meaning we have the ability to slow it down. So it MIGHT well be that you could trigger both solenoids at the same time and the hatch cylinder will always be retracted already by the time the intake arm reaches the collision point. We'll just have to try it...

The timer/delay solution is easy to implement in software but does not guarantee protection unless we make the delay large. This may hinder fast cycling. We'll have to try to strike a balance.

There could also be a mechanical/electrical solution if we could ask for a limit switch or cylinder position sensor to confirm that the hatch scorer is "closed". The issue with this is, in addition to the effort of making the parts to mount another sensor on both robots, we would need to run another set of wires all the way up and down the lift.

I suggest we start with the software only solution, figure out what we're dealing with, and if we feel we must have a sensor for safety or performance reasons, then we can make the request but back it up with data.

[KyleRAnderson]

Yep, I'm definitely going to wait until a robot to neatly configure the timings. I was planning on doing the delay like you said @greyingjay, but I'm also going to look into retracting the hatch right after scoring the hatch so as to reduce the delays and hopefully make things faster.

[kevlam2706]

Sounds good. I believe that there is also still conversation about whether we want to have the plunger retract right away (in one in-and-out motion) or if we want to be able to eject, hold it out in that position while the driver moves the robot and/or confirms that we have safely deployed the hatch, then press a button to retract. These are definitely going to be inter-related.

[GabbyGenereux]

Another note on all of this that I'm pretty sure was mentioned in Erik's document to you guys is that the scoring of the hatch panel involves a few different steps: push the scorer out, lower the elevator a little, then retract. At some point we should look at whether we want that to be an automatic series of events that happens when you push the button on the game pad, or if there are other ways we want to do it. That could also help eliminate this problem.

On Thu, Feb 21, 2019, 11:16 AM Kyle Anderson, notifications@github.com wrote:

Yep, I'm definitely going to wait until a robot to neatly configure the timings. I was planning on doing the delay like you said @greyingjay https://github.com/greyingjay, but I'm also going to look into retracting the hatch right after scoring the hatch so as to reduce the delays and hopefully make things faster.

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

[KyleRAnderson]

Plunger collision should be avoided now, the only time it may happen currently is if the arms are taking a while to go up and the operator attempts to launch a hatch. We can add stuff that fixes this in the future.