![]() |
Ball eject
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. |
Re: Ball eject
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.
|
Re: Ball eject
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!
|
Re: Ball eject
Quote:
There are some thoughts on that (especially for Team Copioli's posts) on the Build Blitz blog here:http://www.buildblitz.com/blog/ |
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
|
Re: Ball eject
use a dead man switch on your shooter :deadhorse:
|
Re: Ball eject
Quote:
|
Re: Ball eject
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.
|
Re: Ball eject
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.
|
Re: Ball eject
Quote:
|
Re: Ball eject
use a "test for"
|
Re: Ball eject
Quote:
|
Re: Ball eject
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.Otherwise, the strongly robust robots might hold more weight in alliance selection... |
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
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. |
Re: Ball eject
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! |
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.
|
Re: Ball eject
Quote:
|
Re: Ball eject
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. |
Re: Ball eject
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. |
Re: Ball eject
Quote:
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 |
Re: Ball eject
Quote:
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? |
Re: Ball eject
Quote:
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. |
Re: Ball eject
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. |
Re: Ball eject
Quote:
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. |
Re: Ball eject
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 |
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
|
Re: Ball eject
A release is probably a good idea.
|
Re: Ball eject
Quote:
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. |
Re: Ball eject
Quote:
|
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 |
Re: Ball eject
Sometimes. It really depends on if it's deemed a field fault or a robot fault.
|
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.
|
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.
|
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. |
Re: Ball eject
Quote:
|
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. |
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.
|
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
Teams that employ that strategy will likely join my extremely exclusive 'do no pick list'. |
Re: Ball eject
Quote:
|
Re: Ball eject
my team has come up with a pneumatic fail safe using a second cellanode
|
Re: Ball eject
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.
|
Re: Ball eject
Quote:
|
Re: Ball eject
Quote:
|
Re: Ball eject
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. |
Re: Ball eject
Quote:
|
Re: Ball eject
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. |
Re: Ball eject
Quote:
|
| 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