Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Team Update #18 (http://www.chiefdelphi.com/forums/showthread.php?t=93650)

Joe Ross 20-03-2011 23:32

Re: Team Update #18
 
Quote:

Originally Posted by squirrel (Post 1042924)
Chris told me it came from Duluth

:confused:

I fixed my post. I knew we were playing with the San Diego field, but not until LA.

TheOtherGuy 22-03-2011 23:30

Re: Team Update #18
 
So, according to team update 19, the electrical side of the towers *shouldn't* be an issue, since there is a dedicated module and any press longer than 1ms should trigger. I saw a post a while back mentioning 20ms sampling times, but a few samples at <=5ms should be a short enough time for faster minibots.

Are there any other possible explanations? Everything I've heard and seen about the towers says they should work flawlessly..

Ether 23-03-2011 00:53

Re: Team Update #18
 
Quote:

Originally Posted by TheOtherGuy (Post 1044098)
So, according to team update 19, the electrical side of the towers *shouldn't* be an issue, since there is a dedicated module and any press longer than 1ms should trigger.

The wording is ambiguous and leaves room for doubt. Maybe it means what you said, and maybe not. It doesn't say a signal longer than 1ms will TRIGGER the tower. It says "any input signal longer than the noise buffer is immediately time-stamped and reported back to the central field controller". OK, then what? The central field controller then "processes the received data". What does "processes" mean in this context? Does it require N consecutive positive readings before it TRIGGERS? If so, how many consecutive positive readings?



TheOtherGuy 23-03-2011 01:30

Re: Team Update #18
 
Quote:

Originally Posted by Ether (Post 1044137)
The wording is ambiguous and leaves room for doubt. Maybe it means what you said, and maybe not. It doesn't say a signal longer than 1ms will TRIGGER the tower. It says "any input signal longer than the noise buffer is immediately time-stamped and reported back to the central field controller". OK, then what? The central field controller then "processes the received data". What does "processes" mean in this context? Does it require N consecutive positive readings before it TRIGGERS? If so, how many consecutive positive readings?

That's what I was getting at with the 5ms sampling period, although you're correct, the FMS could require more than 10 or so consecutive positive samples, which may be enough to prevent a fast minibot from activating the tower. A post in Q&A might be the fastest way for clarification on the number of required samples.

It seems like the easiest way to fix the issue though is to slow down your minibot. People are getting all riled up that FIRST didn't explain exactly how the towers work when their minibots are so fast that they look the same to the FMS as a robot bumping the base of the tower :) Some teams are too efficient...

PayneTrain 08-04-2011 21:57

Re: Team Update #18
 
I wonder if FIRST had an oversight with this rule being so strictly enforced. While they are confident the hardware for the minibot towers are solid, the software's registration of the towers are under the swiss-cheese umbrella of the FMS.

I don't mean to take anything away from 75, 2988, or 3143, but in match 46 of the Virginia Regional, the apparent software issue decided the match. Not the hardware on the towers, or the minibots' interactions with the towers, but the towers didn't register anything.

Now, you may be saying, "How do you know that you didn't hit the bolts?" I think it's odd that two minibots didn't trigger in the match, and the head referee did as well, which is why the field was reset after our match. She explained this update that I know all too well, but that doesn't shake the fact that the only failure in the chain was the inconsistent FMS, which has kept me at the Virginia Regional until 8:30 on Saturday before.

TLDR: I understand the rule, but I feel there were some variables unaccounted for. It cost my team a match it shouldn't have lost.

R1ffSurf3r 08-04-2011 23:45

Re: Team Update #18
 
first match of DC regional our minibot didn't register. they "proved" it wasn't the towers themselves by reseting them and shoving up the crew's hook to trigger it manually, with i'm sure plenty more than 5 newtons.

it didn't effect the match but reasserted my worries of more competitive matches at champs being decided by field errror

PayneTrain 09-04-2011 07:12

Re: Team Update #18
 
See, I like to think that by being in 19th after 6 matches (even though with that win we would be 9th or 10th) we would make it into elims.

In 2009 our run ended when an opposing robot ran into the opposing alliances tower with so much force that it knocked out power and communication to the Driver Stations with 20 seconds left. If we had won that match, we would have gone onto finals and, by beating the 1 seed, have a good chance of winning.

The problem I had was that not only was the disconnection of the DS's self-inflicted, but there was no statistical way the other team could have caught up to us. Lunacy had a finite number of points to be scored, which meant that unless our alliance could rack up 40 points in penalties, we would have won.

I get being on the short end of "luck of the draw", and I have to put my faith in our tech every regional, but I get nervous when I have to put faith in the field holding up its end of the bargain.

FRC4ME 09-04-2011 16:38

Re: Team Update #18
 
Just watched an alliance lose the semifinals due to a sensor failure at Virginia.

The frequency with which conditions other than team performance decide winners every year is understandably discouraging. There isn't a year without issues and I really wish FIRST could make the field more reliable. If that's not possible, they could at least give referees the power to override obvious failures, rather than insisting that there is no problem when there obviously is. The field failures are not unfair - they do not discriminate among teams - but they are discouraging to teams.

On a positive note, some parts of FMS seem to be improving. We did not have to replay a single match this year.


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

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