Need commands (or CommandGroups) for OI buttons

[cal-miller]

The current ArmCatapult and Fire commands do not match what they should do, according to our latest plans for the OI buttons. The ArmCatapult command should drop the intake, shift to neutral and reverse the winch for 0.3 s. The Fire command should release the latch, wait about 0.5 s and winch back the catapult. This also facilitates autonomous scripting.

[roryee]

What is what they "should" do. As the operator I think I can decide what they should do.

[cal-miller]

@roryee : This is based on the OI buttons that we discussed and agreed on.

[roryee]

You told me what you wanted. I said I would consider it.

[roryee]

Things like reversing the motor at the end of fire, I will add. But I would rather have separate button for firing and winching. If that doesn't work well, I can move stuff around. There is a reason we have a practice robot.

[cal-miller]

In what cases do you want the winch up, other than firing? The plan was to
have the 4 high-level buttons for use in competition and lower level
buttons available for testing.

On Sun, Feb 16, 2014 at 8:45 AM, roryee notifications@github.com wrote:

Things like backdriving the motor at the end of fire, I will add. But I
would rather have separate button for firing and winching. If that doesn't
work well, I can move stuff around. There is a reason we have a practice
robot.

Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-35199762
.

Thanks,
Cal

[forbesk]

I don't condone that firing sequence. The current sequence is quite safe and speedy, and the actions performed in ArmCatapult and Fire make sense according to their names. In particular, it shifts to neutral in the firing sequence for safety, and the winching is only done in the arming command. Feel free to wrap those commands in a command group for more control, but they are fine they way they are.

[roryee]

I agree with Kevin.

[roryee]

Can I close this issue?

[cal-miller]

Don't close it yet. Let's discuss today.

On Sun, Feb 16, 2014 at 10:52 AM, roryee notifications@github.com wrote:

Can I close this issue?

Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-35204816
.

Thanks,
Cal

[cal-miller]

One concern with the current implementation (I'm looking at the files in
RobotTest):

The latch firing the catapult doesn't release for .3 s after the fire
button is pressed. This can mess up the operator's timing when firing
while moving like we were trying to do at Duel in the Desert. Is there any
way to have the robot actually fire when the fire button is pressed? Once
we find a good solution for that, I'm willing to close the issue.

On Sun, Feb 16, 2014 at 10:53 AM, Cal Miller calder.miller@gmail.comwrote:

Don't close it yet. Let's discuss today.

On Sun, Feb 16, 2014 at 10:52 AM, roryee notifications@github.com wrote:

Can I close this issue?

Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-35204816
.

Thanks,
Cal

Thanks,
Cal

[forbesk]

That 300 ms delay has not been optimized - we may find we only need 100 ms, which is negligible. As it stands, 300 ms appears to work fine, since we won't be doing moving shots in real matches (you want to be dead certain that the ball will be scored when you fire).

At any rate, safety is a major concern with this system, and we do not, above all else, want the catapult to hurt someone if it's accidentally released. This requires the shifting happen when we know we want to fire, which in turn requires us to rotate the shaft for some predetermined length of time.

[cal-miller]

The system I've proposed addresses both the safety and the time concerns.

First, let's consider safety: If two buttons must be simultaneously
pressed to fire the catapult (the arming and firing buttons) accidental
firing will be virtually impossible. In addition, the winch is only put in
neutral a couple of seconds before the shot, when the arming button is
pressed. If the arming button is released without firing, the winch is
shifted back into gear. Therefore, the winch is in gear except when the
catapult is about to be fired or is firing.

The time concern with the current system is also eliminated. Since the
winch is put into neutral and backdriven before the catapult is fired, the
actual firing occurs instantly when the firing button is pressed.

On Sun, Feb 16, 2014 at 11:26 AM, Kevin Forbes notifications@github.comwrote:

That 300 ms delay has not been optimized - we may find we only need 100
ms, which is negligible. As it stands, 300 ms appears to work fine, since
we won't be doing moving shots in real matches (you want to be dead certain
that the ball will be scored when you fire).

At any rate, safety is a major concern with this system, and we do not,
above all else, want the catapult to hurt someone if it's accidentally
released. This requires the shifting happen when we know we want to fire,
which in turn requires us to rotate the shaft for some predetermined length
of time.

Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-35205902
.

Thanks,
Cal