View Full Version : Ball eject
atucker4072
05-01-2014, 17:36
The issue has been raised that what happens if you have a ball in your robot but then have to e-stop or loose power.
What are teams thinking of doing incase this happens so you don't choke your alliance?
I was thinking have a system that any robot can hit your robot in a way so that it forces the ball to leave the system. So maybe a rod that is able to contact the ball regardless of where it is in or on the robot.
brandon.cottrell
05-01-2014, 17:38
While I do like Aerial Assist, this is something that kind of worries me about this game. Along with the autonomas shots missed, it's now easier to pinpoint exactly whose fault it was that a match was lost and why.
I really think that this is something not clearly written in the manual. Either the ball will be freed, a new ball will be entered or the alliance will only be able to defend the rest of the match!
I really think that this is something not clearly written in the manual. Either the ball will be freed, a new ball will be entered or the alliance will only be able to defend the rest of the match!
Or, teams will just have to make sure that being able to eject the ball is a priority. If you can't get rid of the ball, then you're going to seriously mess up the match.
There are some thoughts on that (especially for Team Copioli's posts) on the Build Blitz blog here:http://www.buildblitz.com/blog/
atucker4072
05-01-2014, 17:43
While I do like Aerial Assist, this is something that kind of worries me about this game. Along with the autonomas shots missed, it's now easier to pinpoint exactly whose fault it was that a match was lost and why.
Thia will be a great test of gracious Professionalism! Although if teams meet before a match like they should lots of problems can be avoided. If I had to as a driver I wouldn't like a team to load a ball into their robot if they haven't tested it or been successful with it.
atucker4072
05-01-2014, 17:44
Or, teams will just have to make sure that being able to eject the ball is a priority. If you can't get rid of the ball, then you're going to seriously mess up the match.
There are some thoughts on that (especially for Team Copioli's posts) on the Build Blitz blog here:http://www.buildblitz.com/blog/
Thanks for the link!
Jhultink
05-01-2014, 17:49
it's now easier to pinpoint exactly whose fault it was that a match was lost and why.
Then during alliance selection the best teams will be picked because it becomes more obvious who is good and who is not. I feel that rankings this year will not be as influential as they have been.
redneckrobot
05-01-2014, 22:37
use a dead man switch on your shooter :deadhorse:
pntbll1313
05-01-2014, 22:54
use a dead man switch on your shooter :deadhorse:
I'm not sure this really solves the issue. If you load your robot, start autonomous, and your robot never establishes connection for some reason, how does this deadman's switch work to release the ball so that your alliance can score?
cadandcookies
05-01-2014, 23:00
Whatever your strategy is when you lose power or e-stop, ultimately your best bet is just to not lose power or get e-stopped. New batteries every match, make sure your robot and code are working well. The best medicine is preventative.
And then the power cable slips out of your router even though you taped and zip tied it, or there is interference from cell phones or whatever the kids are using these days, or the field malfunctions as it is known to do. I think the whole robot malfunctioning thing is (at least in part) out of your control. I'm probably just awful at making communications work though.
redneckrobot
05-01-2014, 23:15
I'm not sure this really solves the issue. If you load your robot, start autonomous, and your robot never establishes connection for some reason, how does this deadman's switch work to release the ball so that your alliance can score?
that is the programmers job
redneckrobot
05-01-2014, 23:17
use a "test for"
that is the programmers job
I for one think that robots moving without connection to the driver station constitutes a safety issue, as does FIRST. This is why the base robot project shipped with your choice of programming language tends to make the robot refuse to do anything without connection to the driver station, and a signal that it is in teleop or autonomous mode.
This would be good for the Q&A, maybe they could declare it field debris? Although how would a ref know to declare it as field debris if it is a result of power failure...?
Could they add a button to the alliance station to declare their current ball(s) field debris? That would add an interesting dynamic to the game (if they left the rule open ended).
If open ended, maybe an alliance could even do that to balls left from Autonomous.
If close ended though, let the rule be only for if the ball is trapped somehow.
Otherwise, the strongly robust robots might hold more weight in alliance selection...
Otherwise, the strongly robust robots might hold more weight in alliance selection...
Well, hypothetically, if you have 2 robots that can throw, none of the robots left available to pick can catch, and one of your robots has a multi-ball autonomous, the safest pick is a box (or ramp if you want to get fancy with loading) with a good drive-train under it.
Bryan Herbst
05-01-2014, 23:46
that is the programmers job
This isn't possible.
The Driver's Station (and FMS) are responsible for telling the robot if it is in teleop, in autonomous, or if it has been disabled. If there is no communication with the DS/FMS, the robot cannot move. Allowing the robot to move at all (electronically) in this situation would be a huge safety issue.
I think the point of the question also goes beyond communication issues. What if the robot loses power (due to a loose wire, a battery that fell out, or something else)? What if a hit from another robot resets your cRIO?
There are a number of problems that could cause your robot to become inoperable with a ball in its grasp.
This is what it should be like:
If the driver thinks the robot is jammed, either the robot is disabled by FMS, or that ball is invalidated if it ever exits the robot. That way, even if the robot is stuck, it can perform something else, like defense or if they add an endgame!
AllyMeeg
05-01-2014, 23:58
So you could try to build your robot so that it has the ability to retrieve balls from disabled robots with an arm of some kind.
atucker4072
06-01-2014, 00:25
This is what it should be like:
If the driver thinks the robot is jammed, either the robot is disabled by FMS, or that ball is invalidated if it ever exits the robot. That way, even if the robot is stuck, it can perform something else, like defense or if they add an endgame!
There is no secret endgame. End of discussion.
The solution is, unfortunately, completely mechanical. The electrical and software rules and libraries expressly prohibit a disabled robot from taking any action.
What teams will have to do, one way or another, is design their collection systems such that when disabled they either release the ball or weaken their grip such that a hit from an alliance partner will dislodge it. Congratulations, you've found the difficult design challenge in this year's game. No, don't design your launchers to immediately fire if they lose power, as that's a clear violation of safety.
Kevin Selavko
06-01-2014, 00:43
On our vex robot our pistons default to retracted so we start in a legal configuration, but can you have a solenoid that defaults to push a piston into where you store your ball when it has no signal, and possibly have it on its own pneumatic circuit in case the first one fails? This way if you have a ball and you become disabled/battery dies/act-of-god, the ball will be ejected, or is this not allowed?
EDIT: I does not need to be very forceful, just enough to make your ball holder a shape that the ball will roll out of.
RRLedford
06-01-2014, 01:05
The solution is, unfortunately, completely mechanical. The electrical and software rules and libraries expressly prohibit a disabled robot from taking any action.
What teams will have to do, one way or another, is design their collection systems such that when disabled they either release the ball or weaken their grip such that a hit from an alliance partner will dislodge it. Congratulations, you've found the difficult design challenge in this year's game. No, don't design your launchers to immediately fire if they lose power, as that's a clear violation of safety.
Are you saying that it is illegal to have a robot with a pneumatic cylinder that, when working properly with bot powered on, gets air via a normally closed solenoid valve and extends, stretching some surgical tubing to move an element which keeps the ball from falling out of the robot.
Then when emergency stopped, the normally closed air valve closes, and a 2nd normally open valve opens to bleed air from the cylinder, allowing the the piston to retract by the surgical tubing tension, releasing the hold ball element and dropping the ball.
If this kind of ball eject scheme would be illegal by the current rules, then there should be an exception rule written to allow such a scheme, or to just have another fresh ball cycle be started from the pedestal, when robots carrying calls are disabled
-Dick Ledford
wireties
06-01-2014, 08:37
I for one think that robots moving without connection to the driver station constitutes a safety issue, as does FIRST. This is why the base robot project shipped with your choice of programming language tends to make the robot refuse to do anything without connection to the driver station, and a signal that it is in teleop or autonomous mode.
In theory nothing (much) can move if the communications are down. The FIRST libraries on the robot fire a watchdog that disables all control outputs.
If a robot on my alliance went brain dead I would want them to hit the big red button - maybe the refs would put the ball back into play?
Thia will be a great test of gracious Professionalism! Although if teams meet before a match like they should lots of problems can be avoided. If I had to as a driver I wouldn't like a team to load a ball into their robot if they haven't tested it or been successful with it.
A very BIG test of gracious professionalism
I'm not sure where to go with this aspect of the game.
I'm asking myself very seriously, if a robot can't automatically eject a ball when disabled, should it be allowed to intake it?
Autonomous is also very tricky - if your robot requires the ball to be inside your robot at the start of the match, and can't be easily freed by another robot, your alliance partners might ask you not to run it.
How would you feel if your alliance partners ask you never to pick up a ball? Or to not run your autonomous?
Would you ask your alliance partners not to do those things?
Because right now, this seems like the prudent thing to do.
The issue is the state "Estop" is really the same as disabled. So you load the ball in the disabled state (Robot is disabled until the match starts) Nothing will happen until the robot is enabled. The coders that can make the robot magically eject the ball on system failure aren't going to be the ones with these kinds of issues.
Scouting is going to be important this year (as if it was never unimportant) because a non functioning robot in the seeding matches can really skew the scores.
This might be the year that a good defense is a good offense.
JohnSchneider
06-01-2014, 10:30
A very BIG test of gracious professionalism
I'm not sure where to go with this aspect of the game.
I'm asking myself very seriously, if a robot can't automatically eject a ball when disabled, should it be allowed to intake it?
Autonomous is also very tricky - if your robot requires the ball to be inside your robot at the start of the match, and can't be easily freed by another robot, your alliance partners might ask you not to run it.
How would you feel if your alliance partners ask you never to pick up a ball? Or to not run your autonomous?
Would you ask your alliance partners not to do those things?
Because right now, this seems like the prudent thing to do.
It's a terrible enough feeling at a regional telling a team "Hey we need you to put this giant net on and sit there and not do what your robot was designed to do because of the nature of the game." I cannot imagine telling someone they cannot play the game in its proper form because "We don't trust your robot's design".
Heck, there are times when a team will just refuse and try it anyways and when the ball gets stuck then what do you do? The rules pertaining to this are not fair for any member of an alliance.
An E-Stopped robot with a ball most definitely should not have its ball counted. That way there's at least a way to keep playing the game for the other 2.
RSaunders
06-01-2014, 10:49
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
DonRotolo
06-01-2014, 11:40
I'm asking myself very seriously, if a robot can't automatically eject a ball when disabled, should it be allowed to intake it?I would think a robot capable of taking action while disabled would be a safety hazard, violating R8.
I would think a robot capable of taking action while disabled would be a safety hazard, violating R8.
What about the robots in 2012 with the after-the-buzzer pneumatic bridge balancers?
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.
A release is probably a good idea.
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.
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
don't you get a redo if there is connection problems
so have a mechanical dead man switch incase there is lost of power
Sometimes. It really depends on if it's deemed a field fault or a robot fault.
JohnSchneider
06-01-2014, 15:09
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.
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
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
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.
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.
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
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
- 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
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.
redneckrobot
06-01-2014, 22:06
my team has come up with a pneumatic fail safe using a second cellanode
PAR_WIG1350
06-01-2014, 23:43
If you have a single solenoid connected to the ejector that ejects when not energized and a double solenoid that controls a locking mechanism, then you can lock the ejector before Autonomous and have it retract as soon as the ejector solenoid is energized. It is a fairly complex system, but it gets the job done.
pntbll1313
07-01-2014, 09:20
If you have a single solenoid connected to the ejector that ejects when not energized and a double solenoid that controls a locking mechanism, then you can lock the ejector before Autonomous and have it retract as soon as the ejector solenoid is energized. It is a fairly complex system, but it gets the job done.
Does this help if the robot for some reason doesn't connect to during autonomous? Since the double solenoid never gets energized doesn't it stay locked?
sdcantrell56
07-01-2014, 09:52
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'.
Unfortunately, I see this happening more often than many would like to admit this year due to the way this rule seems to be worded. Hopefully a rule clarification will change this.
Chris is me
07-01-2014, 11:54
The "one ball per match" rule is extremely flawed. It isn't justifiable for scoring to be impossible if one robot can't eject a ball. It might be okay if we had a flawless control system, but this control system is notorious for mysterious robot deaths. It's been getting better but so many robots stop moving each regional and Championship (even on Einstein this year) that I fear the game at some points may become a "control system coin flip".
One simple rule change can fix it - E-stopping a robot allows another ball to enter the field. It's a huge penalty, no triple assist, so it's not likely to be abused, but it would let play continue.
JohnSchneider
07-01-2014, 11:59
The "one ball per match" rule is extremely flawed. It isn't justifiable for scoring to be impossible if one robot can't eject a ball. It might be okay if we had a flawless control system, but this control system is notorious for mysterious robot deaths. It's been getting better but so many robots stop moving each regional and Championship (even on Einstein this year) that I fear the game at some points may become a "control system coin flip".
One simple rule change can fix it - E-stopping a robot allows another ball to enter the field. It's a huge penalty, no triple assist, so it's not likely to be abused, but it would let play continue.
Whole heatedly agree. I also would suggest a red card be issued for teams who intently try to prevent their own alliance from score.
On the other side of the coin. With the likely robust defense, robots without a firm grasp of ball will not be able to maintain control.
Robust electrical system will be important this year so you don't disconnect wires from all the impacts.
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.I have no background with them, but R29 also allows for some sorts of electrical solenoids. These can be spring return, so maybe a clever system could use the electrical rather than the pneumatic variety. Anyone have more experience with these?
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.