TEST Einstein BEFORE the BIG-show... here's a proposed approach...

As I understand, the Einstein field and equipment are new and unused… therefore, untested under competition conditions before the BIG-show is run…

NO MATTER what bullet-proof technical remedy FIRST comes up with to solve connection issues, I believe there’s TOO MUCH at stake for teams that earn a spot on Einstein to go through what happened last week ever again…

SO, I have an idea for the CD community to throw-balls-at…

What if during the Division Eliminations, the 3 highest-seeded rookie teams (not picked for division elims) from each division are invited to compete on the Einstein field (“Rookie-stein”) for the experience and bragging-rights… maybe a small award/trophy to the winning alliance.

A couple of large-screen monitors could be provided in the queue so that the participating rookies can catch their division elims while running through matches…

This would provide a THOROUGH vetting and shake-out of the Einstein field/equipment shortly before the BIG-show takes place… and I’m sure the field would still look pristine after 4-6 total matches…

PLUS, the added bonus of giving 12 potentially future high-performing rookie teams a taste of “CMP-elims” and “Einstein”…

WHAT do you think? THANKS!

As others have stated the field would have some wear and tear on it. So as a result they’d have to replace the pieces if they did this.

Also, the communications problems likely extend through out the entire competition this year and possibly before and pre-existing topics for it exist on ChiefDelphi.com.

Testing the field might make the field nearly as functional as the others, but even the Curie fields had problems. We also had communications problems at MAR Mount Olive in NJ prior to this.

I don’t see where you can get so much wear and tear after playing a few matches…

The bridges would be the biggest place I would think.
They seem to get pretty worn looking pretty fast.

90% of the crowd wouldn’t even be able to see if there were scars on the bridge and I bet an even higher percentage would gladly live with the scars than see what happened this year.

Because we don’t know what exactly caused the communication failures - and one hypothesis is “Sensor Overload” - I don’t feel like this is a valid approach because - in all honesty - Rookies don’t typically use sensor-high machines, and so we wouldn’t really be testing anything.

Though your idea of a rookie playoff seems kinda neat!

Love this idea… Rookies/somophore all-star game on Einstein… Can be run while people are moving from the divisional stands to the big stage.

Testing is not 100% foolproof, but will give us a much higher chance of a smooth Einstein competitions.

How can we bring this forward to the organizers?

I like it. I like it a lot.
And it’s really not that difficult to make a field look new again, just put new plexiglass on the bridges. I believe they’re even fastened down with velcro. Perfect.

Your proposal would have worked with this year’s game. Next year’s game, who knows.

Given the number of “water game” jokes in the FRC Live! presentation, I’m pretty sure that members of the GDC read Chief Delphi sporadically.

Guys,
I have to say something here so that everyone can get on the same page. Every discussion about Einstein field issues have used the term “communication failures”. While it is easy to jump to that conclusion depending on your viewpoint, it is not the sole problem with a robot losing control on the field. To prevent the casual readers from drawing conclusions can we agree to use a different term to describe the inability of robots to move.

I do like the suggestions that teams be given a chance to play on Einstein prior to the finals. (Many of us remember Epcot where this occurred.) I also feel strongly that FLL be given a chance to play in the dome and that adds some complexity to the layout of the fields. As I was fully engaged in FRC this past weekend, it was impossible for me to observe FLL. Did those teams perform well in the big space, were the younger students overwhelmed? Would the participants be more comfortable in a smaller venue? With that I would like to say that having all FRC fields in the dome made life in the pits a lot easier. Please do not put an FRC field in the pits in the future.

I would like to make a Huge point about the Einstein problems that people are assuming never happened. Here is is… Everyone listening!?!

**THE FIELD WAS TESTED BEFORE EVERY ROBOT GOT ON THE FIELD! **

I was told by a person who I know is extremely reliable about the Field issues, however I will not release their name to anyone.

/END ALL EINSTEIN ISSUE DISCUSSIONS!

OK so we do as you suggest and find major problems. How do we fix them now that it’s the 11th hour??? That’s the same situation we were in this year – found a problem and had no clue how to fix it in the relatively small time remaining.

I agree. If we assume the field is at fault and we assume the poster after the quoted post is correct. Then the problem would then be in the robots. A whole different and still frustrating can of worms given these were supposed to be the best of the best.

I’m just not sure, given what we have for information, that we can actually have a simple handy term for that someone won’t have issue with. Some people feel that the robots being the best of the best should make them untouchable to the issue. I’ve stated elsewhere I can see how that could very probably be false.

On the other hand, I find it strange that some fields at some events seem much more likely to have problems. I’d like to say with certainty that all the issues are on the robot…in my gut…but we have just too much anecdotal information.

I can say I tried downloading the FMS lite software and frankly, Al, that things a mess. I suppose it addresses the issues it was created for well enough that it was sort of ignored it’s polished like a mud pie.

I don’t think this necessarily follows. This doesn’t rule out either environmental dependencies or data dependencies.

Take the assertion that the field was tested as a given, but tested when and how? If at o’dark30, then the sea of wifi enabled phones in the audience weren’t there. The testing environment is not nominally equivalent to that seen during finals, and I have no idea how it could possibly be made so.

The data requirements were probably not as seen in finals, but this, I’ll grant, is “in the robots” – but it’s possibly not their fault.

This is a hard problem, no doubt about it. Intermittent and barely reproducible – a troubleshooter’s worst nightmare!

I was involved in this exact conversation last night with a few mentors from another team ( A HoF team and the mentors were by no means rookies). The conclusion we came up with mimics Mikes.

But, instead of rookies playing on Einstein, what about if Friday afternoon and Saturday morning, after FLL is done obviously, teams from each division are cycled through Einstein as part of their normal qualification matches?

This possibly gets teams another play without extending the time too much and gets some real time check out of the field. And the field gets some “sensor heavy” useage.

Bill Miller—you listening? I suspect you are.

To some extent the spread spectrum nature of the radios and the fact that many phones are not 5GHz should have eliminated a lot of that.

This is not to say that there can’t be an impact from 2.4GHz traffic, it’s not entirely clear to me that my definition of disabled equals what FIRST considers disabled when they discuss the 2.4GHz portion of the D-Link AP radio.

Then again, I appreciate that perhaps the robot traffic simply was too much, under the cirumstances I can see that happening.

I had a similar thought while the field was having issues:

I think the field should include 6 (maybe less for cost reasons I guess) CRIO’s hooked up to 6 radios, configured as imaginary team numbers 9996-9999. Program each CRIO in a different language and fit it with some basic code (or maybe exhaustive code using alot of functions as a ‘test’) and these boxes become the gold standard for proper field functionality.

If a field has issues, hookup the boxBots, if they don’t work then you know it’s the field; if they do work then that gives the field personel a little more certainty that the field is not at fault.

It’s a bit of an expensive solution to start, but these can be used multiple years with fairly minimal maintenance, and it removes a variable from the equation, because it’s easy to blame the robot/team that had problems.

(edit for sounding less like a jerk :slight_smile: having a rookie bracket of sorts is a cool idea; but I don’t know that it would be able to solve field problems in advance, I suspect having a rookie team fail on the field is more than likely going to be attributed to that team than the field).

There’s a bunch of issues with testing radio issues at these frequencies.

The orientation of the robots matters.
The 3D locations of the robots matters.
The sort of traffic you are trying to push through matters.
The internal designs of the robots and radio placements matter.
What the radios can and cannot do, like disable 2.4GHz fully matters.
Even the projectiles on the field, and the people near it matter.

The trick would be to basically create good approximations of the robots.
The difficulty is knowing what those approximations should look like.

Otherwise the mock robots pigeon hole you into making your design more like theirs or you are back to the bad design example. Worse it’s expensive.

At this point you may as well drive the robots you have with the teams that brought them. They gain experience and you can see if there’s a little gotcha coming that a straight simple field test didn’t show.

I was told by a person who I know is extremely reliable and whose name I will not release that you made that up :rolleyes:

Tested how? With 6 robots running around sending and receiving data? I doubt it…