Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Ball eject (http://www.chiefdelphi.com/forums/showthread.php?t=124112)

vhcook 06-01-2014 11:49

Re: Ball eject
 
Quote:

Originally Posted by Whippet (Post 1322352)
What about the robots in 2012 with the after-the-buzzer pneumatic bridge balancers?

You had to trigger the solenoid before the buzzer. Any after-buzzer activity was just the air pressure equalizing on a decision that had already been made.

!Alp! 06-01-2014 12:27

Re: Ball eject
 
A release is probably a good idea.

Racer26 06-01-2014 13:51

Re: Ball eject
 
Quote:

Originally Posted by vhcook (Post 1322356)
You had to trigger the solenoid before the buzzer. Any after-buzzer activity was just the air pressure equalizing on a decision that had already been made.

Not strictly true. You can have a single acting solenoid valve which spends the entire match energized, keeping your ball ejector retracted. As soon as the robot transitions to the disabled state (either commanded by the field at the end of a match, or because the robot lost communication) that solenoid will cease to be energized, and extend your ball ejector.

The trick is in figuring out a way to either A) make it so that during the pre-match disabled phase you can keep your ejector retracted (perhaps you use a dump valve connected to a servo to trap air strategically in the system that can later be released) OR B) pick the ball up at the start of auto instead of pre-loading it into your robot.

Dalrik 06-01-2014 14:16

Re: Ball eject
 
Quote:

Originally Posted by Racer26 (Post 1322444)
B) pick the ball up at the start of auto instead of pre-loading it into your robot.

This is probably what most teams are going to have to do. The corner case of a robot that crashes as soon as auton starts and thus never has time to arm an eject mechanism is one that I don't see a clear solution for. Then again, you have to waste part of your 5 second window for the hot goal picking up the ball...

redneckrobot 06-01-2014 14:19

Re: Ball eject
 
don't you get a redo if there is connection problems

so have a mechanical dead man switch incase there is lost of power

Whippet 06-01-2014 15:00

Re: Ball eject
 
Sometimes. It really depends on if it's deemed a field fault or a robot fault.

JohnSchneider 06-01-2014 15:09

Re: Ball eject
 
It's irrelevant which it is. 2 robots on an alliance should never be put in a position where they cant score because some team is adamant in taking in the ball and then not being able to eject it.

Tungrus 06-01-2014 15:36

Re: Ball eject
 
Our team is planning to join our alliance partner and beat the "ball' out of the third alliance with stuck ball! Pretty sure this is not against GS, which is directed towards opponent alliance and may get red card.

cbale2000 06-01-2014 15:41

Re: Ball eject
 
My only question would be, how do you design a mechanism that allows you to eject the ball when the robot dies, but NOT when the robot is disabled at the start of the match. I don't really see a simple way to do it.

On top of that, I have to believe that this is the kind of issue that will get addressed by the GDC in a game update or Q&A. I can't imagine they would make a game where one alliance could not score at all if one of their robots died... for that matter, what happens if both alliances have a robot die with a ball? No one scores at all that match? You could effectively have a game that is decided within the first 10 seconds, which doesn't make for a very interesting game.

AndrewPospeshil 06-01-2014 15:52

Re: Ball eject
 
Quote:

Originally Posted by cbale2000 (Post 1322536)
On top of that, I have to believe that this is the kind of issue that will get addressed by the GDC in a game update or Q&A. I can't imagine they would make a game where one alliance could not score at all if one of their robots died... for that matter, what happens if both alliances have a robot die with a ball? No one scores at all that match? You could effectively have a game that is decided within the first 10 seconds, which doesn't make for a very interesting game.

I agree. Although we should never plan for new rules being added, I do think that this one has a good chance of happening. There's a few possibilities like a new ball being introduced if the robot controlling is inoperable and would otherwise stop the flow of the match, but there's a chance (and a sizable one in my opinion) that robots will be required to have removable balls so their alliance can still play if the team cannot. Which also presents the opportunity for the opposing team to be able to eject the ball somehow. Another element of strategy for teams to consider.

JesseK 06-01-2014 16:22

Re: Ball eject
 
Heh, this thread has uncovered a few issues, most of which have been addressed.

- Teams are usually not 100% honest about their capabilities because they're almost always trying to make themselves look good or haven't performed appropriate testing. A vast majority will say 'that cannot happen' or 'yea, but we fixed it' and thus it's really up to fate. I think the best approach it to be watchful after the first time it happens, weary that they couldn't fix it after the 2nd time, and politely assertive after the third. Scouting will be key.

- There will be scenarios, like many years, where a team will feel it may mathematically advantageous for them to keep a ball away from their own alliance in order to lose a match to fall in ranking and thus be available for a 2nd-round pick. It's been publicly discussed before and this year will be god-awful for the alliances which have a team member who exploits it. Hopefully this doesn't happen.

Single-solenoid valves are probably the simplest way of auto-ejection, but such a setup could potentially complicate setup and execution of autonomous. If the ball can't nestle nicely in the carriage ready for launch in steady state, then there's another variable for a consistent and reliable autonomous score.

tStano 06-01-2014 16:30

Re: Ball eject
 
Single action solenoids are great but if you don't have pneumatics on your robot (and many teams don't), it shouldn't be necessary to add an entire pneumatic system for that.

atucker4072 06-01-2014 16:39

Re: Ball eject
 
Quote:

Originally Posted by tStano (Post 1322571)
Single action solenoids are great but if you don't have pneumatics on your robot (and many teams don't), it shouldn't be necessary to add an entire pneumatic system for that.

You have a good point but having a pneumatics system is better than loosing matches.

XaulZan11 06-01-2014 16:39

Re: Ball eject
 
Quote:

Originally Posted by JesseK (Post 1322564)
- There will be scenarios, like many years, where a team will feel it may mathematically advantageous for them to keep a ball away from their own alliance in order to lose a match to fall in ranking and thus be available for a 2nd-round pick. It's been publicly discussed before and this year will be god-awful for the alliances which have a team member who exploits it. Hopefully this doesn't happen.

Or, even worse, a team holds onto a ball an entire match, so their superior partner cannot seed first, effectively breaking up any super alliances.

Teams that employ that strategy will likely join my extremely exclusive 'do no pick list'.

GaryVoshol 06-01-2014 19:49

Re: Ball eject
 
Quote:

Originally Posted by RSaunders (Post 1322308)
Why wouldn't the referees consider a ball in an EStopped robot "out of play"? It's a good idea to raise this question in the Q&A, but software solutions aren't what you want when a simple human decision can solve your problem. That's what referees are for.

/Randy

A referee's job is to enforce the rules, not make up new ones. As much as we'd sometimes like to help out teams, we can't do so if the rules don't allow it. If the rules are amended to define a ball in an E-Stopped robot as field debris, we will so decide. If the rules remain as is, we can't do it.


All times are GMT -5. The time now is 08:51.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi