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)

Woolly 05-01-2014 23:30

Re: Ball eject
 
Quote:

Originally Posted by DavisC (Post 1322069)
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

Re: Ball eject
 
Quote:

Originally Posted by redneckrobot (Post 1322062)
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.

yash101 05-01-2014 23:52

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!

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

Re: Ball eject
 
Quote:

Originally Posted by yash101 (Post 1322095)
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.

Dalrik 06-01-2014 00:37

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.

Kevin Selavko 06-01-2014 00:43

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.

RRLedford 06-01-2014 01:05

Re: Ball eject
 
Quote:

Originally Posted by Dalrik (Post 1322130)
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

Re: Ball eject
 
Quote:

Originally Posted by Woolly (Post 1322068)
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?

Mr. Lim 06-01-2014 09:05

Re: Ball eject
 
Quote:

Originally Posted by atucker4072 (Post 1321724)
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.

FrankJ 06-01-2014 09:57

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.

JohnSchneider 06-01-2014 10:30

Re: Ball eject
 
Quote:

Originally Posted by Mr. Lim (Post 1322259)
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

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

DonRotolo 06-01-2014 11:40

Re: Ball eject
 
Quote:

Originally Posted by Mr. Lim (Post 1322259)
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.

Whippet 06-01-2014 11:47

Re: Ball eject
 
Quote:

Originally Posted by DonRotolo (Post 1322348)
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?


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