End of Match Command?

[TogetherSword8]

Our design for launching the ball involves a spring that we pull back, and then upon a piston release, accelerates the ball out.
Due to safety concerns of having a cocked spring with a lot of potential energy, we would prefer to let it release automatically at the end of a match. I remember reading something about running a single piston at the end of autonomous, is there a way we could do the same thing at the end of the teleop period, and if so, how would that be coded? We are a Labview team, but asking this in the general programming section for ideas on how to solve this.

[eddie12390]

Originally Posted by TogetherSword8

Our design for launching the ball involves a spring that we pull back, and then upon a piston release, accelerates the ball out.
Due to safety concerns of having a cocked spring with a lot of potential energy, we would prefer to let it release automatically at the end of a match. I remember reading something about running a single piston at the end of autonomous, is there a way we could do the same thing at the end of the teleop period, and if so, how would that be coded? We are a Labview team, but asking this in the general programming section for ideas on how to solve this.

Use a single-acting solenoid that defaults to being retracted. That way, the moment that the solenoid is no longer powered the energy will automatically be released. (Please note, I'm not saying that this is a good idea or that you should do this. The implications of being in the pit and having it suddenly discharge because you disconnected are pretty bad)

[otherguy]

I haven't worked in Labview in a while, but the following should get you moving in the right direction:

Start a timer when your match state changes to teleoperated.

Determine how long before the end of the match you want your action performed.

When <teleop duration> - <current match time> is less than or equal to the time you want your action performed, then perform your action.

The comparison described above should result in a boolean value that you could use to run a commanded action in the same way you would use a boolean off of a joystick button. It could feed a CASE box. and your action to move the solenoid would be placed in the "True" area of the box.

[DaveCT]

In LabVIEW you can get the "TeleOp Elapsed Seconds" from the Match Info control input to the Teleop vi. Compare this with the expected match length - however long your mechanism needs.

As was mentioned I'd be very careful about how you implement this though, the consequence for an unexpected firing while troubleshooting in the pits could be severe. Last year it took over 2 minutes to fully charge our pneumatic system from empty. It was routine for the "auto hang" feature to trip while testing or charging. Something like a missile switch to enable/disable this functionality might help mitigate it, but wouldn't be fool proof.

[Pratik Kunapuli]

Originally Posted by eddie12390

Use a single-acting solenoid that defaults to being retracted. That way, the moment that the solenoid is no longer powered the energy will automatically be released. (Please note, I'm not saying that this is a good idea or that you should do this. The implications of being in the pit and having it suddenly discharge because you disconnected are pretty bad)

We've been doing this for a couple of years, and as long as everyone is a safe distance away from the robot and aware that the _______ actuates, then it should be fine. Last year we had our pneumatic 10 point hanger default to the down position so we could theoretically have a 0 second hang.

[notmattlythgoe]

You could have a single actuating cylinder that actuates with no power that would just act as a latch on the catapult. That way nothing dangerous is firing when it loses power and its just locking the shooter in place if it is currently down.

[Andy Brockway]

I am away from the programming computer but I beleive there is an IsTeleop and IsAutonomous that can be used in C++ for dropping out of loops. Possibly this could be used with single solenoid.

[Joe Ross]

Anyone trying to do something similar with C++ or Java using DrvierStation.getMatchTime() should be aware of this bug: http://www.chiefdelphi.com/forums/sh...d.php?t=125495

[NotInControl]

If I were to implement a function like this, and safety in the pits was a concern, I would also use the isFMSAttached() boolean in my logic, which is a part of the driverstation class.

This should return true when connected to the fields network, but false when in the pits.

This way the auto actuation of the piston, only happens on the field.

They may be no way to test the code until your on the field, but I'd rather it not work on the field because of incorrect code, then accidently knock one of my kids out in the pits.

I know this method is available in C++/Java, I would assume something similar is availble in Labview if you unbundle the proper data structure.

Regards,
Kevin

[DaveCT]

Interesting, as far as I know there is no direct isFMSAttached equivalent provided in LabVIEW (and I've looked). Feel free to prove me wrong if I missed it somewhere.

However, looking at how it's implemented in Java it looks like we should be able to get it using something like the following:



I obviously haven't tested the above, so use at your own risk...

[jvriezen]

For situations like this, it would be good to have some type of 'horn' (like a dump truck backing up) that would sound prior to the action to warn at least those familiar with the bot that something might be about to happen.

I'm thinking such a device would be good to put in the KoP with instructions to program it to squawk prior to potentially dangerous actions (at least when not connected to FMS-- i.e in pit, shop, demo, etc.)

Even better would be something that could also vocalize a fixed/programmed/recorded phrase : "Caution, stand back !"

Granted, programming errors may risk that you don't always get a warning, so you do run a risk of a false sense of security, but I think, on balance, such a system would be helpful, especially for games where there is high force actuators or harmful projectiles like frisbees.

[Greg McKaskle]

You are correct. LV doesn't have a wrapper VI for the IsFMSAttached. No good reason, probably oversight. But there hasn't been much call for it.

I believe the code you showed needs to index with a 3 instead of a 7.

Greg McKaskle

[DaveCT]

Originally Posted by Greg McKaskle

I believe the code you showed needs to index with a 3 instead of a 7.

You are of course correct, I missread the java define as 0x80 rather than 0x08. Thanks for the correction.