TOWER Malfunctions since Week 3

[Racer26]

Just wanted to make a comment about the TOWERs.

I have noticed 3 separate TOWER malfunctions since Week 3, when FIRST decided that the TOWERS and FMS would be the final say.

Week 4: Waterloo Regional

Semi-final Match 1-2: 2056's robot crashes into the TOWER base, and sends their minibot up, which strikes the top and comes flying off. TOWER TRIGGERED, but lights failed to go on. FMS received the TRIGGER. (This one, I believe to simply be a matter of the TOWER losing electrical connection with the lights due to impact. This TOWER remained broken for Finals 1 and 2.

Week 5: Greater Toronto EAST Regional

Q58: At T-15 seconds, the roadrunner sound plays and the TOWERs begin the endgame sequence (BASE flashing Yellow, Top indicators flashing all 4 lights). At T-10 seconds, when the TOWERs normally switch the BASEs to Alliance colors, and the Top indicators start the chase sequence, the TOWER BASEs switched, but the Top indicators remained flashing all 4 lights. At approximately T-6 seconds, 1075's minibot hit the top of the TOWER, same as it had been all weekend, TOWER did not TRIGGER. At T-0 seconds, the TOWER Top indicators begun the chase sequence. Referees made the call to award the points to 1075's mini.

Week 6: Michigan State Championship

Quarter-final 2-1: 27/245 (red) and 1718 (blue) DEPLOY MINIBOTs. 245 DEPLOYED early, so their TOWER was DISABLED. 27 and 1718's MINIBOTs reached the top close enough together that its difficult to tell who won. 27's MINIBOT did NOT TRIGGER the TOWER. 1718's did. Race was SCORED as 27, 1718, 245(disabled).

Any other interesting TOWER malfunctions?

[davidthefat]

What my view on this subject is "stuff happens". Simple as that. We can't go back and change the outcomes of a match. Field equipments beak down just like robots. We can go over all the malfunctions of towers, it is a fruitless as going over all the robot malfunctions that dozens of teams have experienced.

[nikeairmancurry]

What's weird with this is per update 18... If the tower does not tigger it doesn't count... 27 did not trigger the tower... Therefore shouldn't of had counted... As in other regionals where this was upheld...

[dodar]

Originally Posted by nikeairmancurry

What's weird with this is per update 18... If the tower does not tigger it doesn't count... 27 did not trigger the tower... Therefore shouldn't of had counted... As in other regionals where this was upheld...

The tower did trigger. Even though the lights didnt show it, the FMS system saw it.

[Racer26]

@dodar: Are you sure? Based on the way I read the discussion in the Michigan State Championship thread, FMS did NOT pick up 27 at all. I'm inclined to believe this based on the video, and my personal experience with the instance at WAT. (if it had, it would be a case more like what happened in Semi 1-2 at WAT - TOWER lights not illuminated, but other towers still showing correct readout [1114's mini had 4 lights, 2056's had no lights and no chase sequence after impact, 1075's had 2 lights]) 27's TOWER maintained the chase sequence, even after impact.

[dodar]

I am pretty sure I remember hearing Dave say that the FMS system did pick up the hit even though the lights did not. But if a member of 27 could tell us what actually happened, that would be better.

[Racer26]

I know thats what happened in Waterloo. The FMS picked up the score (evidenced by 1075's mini only scoring 3rd), but the lights were toasted. Thats not what happened in Michigan though, at least, the failure mode isn't the same. 1718's TOWER showed 4 lights.

[Joe Ross]

I've also seen several cases where a tower TRIGGERedd prior to the minibot hitting it.

[IKE]

We had a match where our alignment device triggered the tower sensor before the minibot deployed. Unfortunately, this was the "4th" minibot which disabled the field and thus our team did not get a chance to deploy that match. It was an interesting ruling in that the "tower" triggered, but since a minibot did not deploy, the team could not be given the points.

Gotta love automated scoring systems. When they work, they work, when they don't... well... were not gonna talk about that, and instead focus on how they almost always sorta kinda most of the time work pretty much as planned (once they have been fixed a couple of times).

[pathew100]

Originally Posted by IKE

We had a match where our alignment device triggered the tower sensor before the minibot deployed. Unfortunately, this was the "4th" minibot which disabled the field and thus our team did not get a chance to deploy that match. It was an interesting ruling in that the "tower" triggered, but since a minibot did not deploy, the team could not be given the points.

That happened a few times at MSC in quals and elims. And it brings up an interesting quandary. Because of the false trigger, the game ends about 5-6 seconds early.

At that point the referees have to huddle and determine whether or not an alliance could have done enough in the 5-6 seconds that should have happened to effect the outcome of the match. (Because this is technically a field fault)

In most cases hanging 1 or 2 tubes that late in the match will not change the outcome (Most matches at MSC had 3-4 logos on the top and middle rows already so your possible points for hanging 1-2 more tubes is low).

If the score was close and the refs thought someone could have scored tubes to change the outcome then we would have replayed the match. Luckily this was not necessary.

[FRC4ME]

I saw a few sensors fail to trigger that probably should have at VCU.

That the sensors don't work all the time is not an issue. While I would have liked to see less failures, we can't expect the field to work 100% of the time. Where I see a problem is FIRST explicitly disallowing referees from overriding the automated scoring system in instances when it clearly did not work correctly. To pretend that the sensors work perfectly ("you must not have hit with enough force," "you must have hit a bolt," "it works when we whack it with a broom so it must be your minibot's fault..." etc) when they obviously do not is, IMO, a bit arrogant.

[ChristopherBuck]

There were at least three innstances where minibots did not trigger a particular tower at the VA (VCU) regional. I don't have the match numbers on hand, but I will look through the archive of the even later to find which ones they were. It happened to three different teams (at least), 612, 11, and 339 as stated above. In the cases I saw, it was pretty clear that the minibots hit with enough force, did not hit the bolt, and as far as the human eye could tell, looked like they hit the plate for more than 5ms.

[Jared Russell]

At Philly, both 365 and 1403 deployed minibots that failed to trigger the tower (despite a very loud THUD at the top).

[Bill Moore]

Originally Posted by Jared341

At Philly, both 365 and 1403 deployed minibots that failed to trigger the tower (despite a very loud THUD at the top).

Watching the webcast on Friday (Thanks to Team 1517, the Lumberjacks), in their second match, the MOE minibot went up the pole twice and struck the plate both times. I assumed this was a deliberate change to the program to ensure no repeat of a field issue as in match #1. I found out later it was not planned, but when the minibot went back to the bottom of the tower the impact reset it. So it climbed and scored a second time.

Not a bad strategy though if you have field issues and a very fast minibot.

[ToddF]

Having been through the Palmetto and the Virginia Regionals, I've now seen quite a few instances of "tower failures". These tend to fall into two catagories:
A) False positives that happen when a robot hits the base hard or a deployment mechanism hits the pole hard. Robots with deployment issues often repeatedly ram the tower trying to get their minibots to deploy, sometimes practically knocking the towers over in the process.
B) False negatives that happen when a minibot climbs the tower, hits the plate, but the sensors don't light. Minibots fall into two categories: direct drive bots that are very fast and light; and geared bots that use the stock Tetrix gearboxes and often stock Tetrix wheels and tend to be slower and heavier. After watching two regionals worth of matches, it is my impression (not backed up by supportable data) that all or nearly all false negatives happen to direct drive minibots. I'm sure there may be exceptions, but I'm also pretty sure there is a statistically supportable correlation.

As an engineer, I can understand that designing a sensor assembly that is sensitive enough to eliminate false negatives while also eliminating false positives may not be as easy as it first appears. But, with something as fundamentally important as an automated scoring system for a national competition, the sensors as currently designed don't seem to be fulfilling their design objectives. I'm sure they could have been designed to be more consistent, possibly by using sensor technology other than mechanically actuated limit switches. I'm also sure that they aren't going to be redesigned at this point.

We, as mentors and engineers, are now provided with a "teachable moment" for our students. Nothing in the real world is exact. Material properties, such as the yield strength of Aluminum, are generated statistically from experimental data. If you want to be absolutely positive to prevent a failure, you use allowable stresses which are well below the statistically generated averages.

We have enough observable data of the behavior of the tower sensors to conclude that their triggering threshold is somewhat inconsistent, but which could be statistically characterized if someone took the time to do so. Teams must choose to either use a heavier, slower minibot which triggers the sensor 98% (rough estimate) of the time or to use a lighter, faster minibot which triggers the sensor 70% (rough estimate) of the time. Engineers make these types of decisions everyday when designing things like cars, aircraft, and spacecraft.

We can complain all we want about the behavior of the sensors, just as we can complain all we want about how engineering materials don't break or buckle under the exact same loads every single time. Or we can teach our students how to deal with uncertainty in their design choices, and accept the consequences of those choices. As a mentor, I see my job as showing the kids how to think about the world less like a high school student (Those stupid sensors don't work right! We just got robbed! This isn't fair! Waaaah!) and more like an engineer (Now that we have observed how the sensors behave, let's make an educated choice of how best to use that behavior to make our team most likely to win.)

Todd F.
mentor, Team 2363