Re: Einstein Field issues Handled correctly?
 

233 (Curie, blue) was dead in F1.

Re: Einstein Field issues Handled correctly?
 

Missed that. Thanks for the correction.

Re: Einstein Field issues Handled correctly?
 

The first part is incorrect. A flashing light at the corresponding alliance station indicates loss of communications. It was in this way that I and other mentors on my team observed comms issues. For me, at least, it was extraordinarily clear that the entire Curie alliance suffered from comms issues at some point during finals. The only two robots to maintain comms in finals, I believe, were Bomb Squad and Raider.

A different FMS is an option, albeit a logistically impractical one. The better solution, imo, to extend on Kevin's post, would be for FIRST to at least have demonstrated throughout the season (via team updates or some manner) that they were actively working to isolate and resolve the issue. It also should have been clear that pre-match testing was absolutely imperative given the prevalence of these issues throughout the season.

FIRST's unwillingness to explain these issues was also unforgivable.

Re: Einstein Field issues Handled correctly?
 

This, I agree with.

This, I do not. If the FMS is at the root of the issue, why is it remaining in place? Would you solve the issue of termites creating lots of sawdust in the kitchen by buying a better vacuum?

If the TCP/IP protocol is to blame, it's time to move on to a more reliable technology.

Re: Einstein Field issues Handled correctly?
 

I think most if not all problems that occurred could have been prevented if the connections on Einstein were tested earlier in the day. If the problem had indeed been the field, they could've spent the rest of the time up until the finals troubleshooting. If there were no problems before but problems later, the bots should've been check then to see if it was the bot's fault. If not, they definitely should have looked into radio interference and storm interference which they had the equipment to do so (at least for the radio part anyway). I don't think it was so much as an inability to find the issue as the lack of will and patience to do so.

Re: Einstein Field issues Handled correctly?
 

TCP/IP as designed and properly implemented is a reliable protocol. If a packet is not received properly it will be resent. Is it right for FIRST? Is the implementation throughout the system correct? I don't know.

Re: Einstein Field issues Handled correctly?
 

Something to keep in mind:

118 has had communication errors a couple times this year. Yes, there were clearly problems on Einstein that effected a lot of teams. However, once they worked on the problems and replayed the matches, it was only 118 that never moved. I don't think we can blame the entire thing on FIRST, especially since we don't have all the details.

Re: Einstein Field issues Handled correctly?
 

In regards to the weather possibly playing a factor into interference with the WiFi:

I'm by no means a radio-frequency or weather expert so I just had a conversation with some guys in the meteorology department at my school and they were skeptical about the storm being a factor. Lightning strikes do produce radio waves called sferics which would make their way into the building, however they are usually in AM frequency range, and shouldn't cause interference with the devices that FIRST uses on the field.

They participate in storm chasing during the spring and use plenty of wireless networks during the process, so they have plenty of experience with wireless devices in the middle of large thunderstorms. While I'm sure there are some equipment differences, they haven't ever had interference problems in the middle of a storm, nor heard of anyone else having those issues. Of course this isn't a 100% comparable situation, but it's relatively close IMO.

Re: Einstein Field issues Handled correctly?
 

It might help to switch to the 5 gz bandwidth for wifi. Some laptops would need to have an adapter for the network. Very few devices use the bandwidth and it would cut down on interference.

Re: Einstein Field issues Handled correctly?
 

For what is worth. One thing I was told by the FTA at an off season event. The signal to start Autonomous or Teleop is only sent once at the beginning of that state. I personally have no idea how the field communicates with the robot but this statement makes sense for why some robots don't move. If you only send a signal once and in that split second while that signal is active there is a glitch in the WiFi (which happens) then the robot misses the signal and won't ever activate that particular state. However this is not how TCP/IP is meant to work. If a signal is missed there will be a message to send the signal again for a few more attempts to help create the full packet. It seems to me that this is not happening. When a robot is not communicating with the field there are separate signals being sent to flash lights above the driver station. Why can't a simple protocol be created that while this light is flashing there are multiple attempts to tell the robot what state to be whether it be Auto or Teleop. Having a one shot attempt to tell the robot to go seems like it is leading to these problems.

How much do we know about how the field works? Can this hypothesis be proved invalid?

It also seems that when the FTA is looking at packet transfer there are packets that tell the robot to be disabled till the match starts and then there are packets after the match starts that have the data from the DS but how many packets tell the robot to switch from disable to Auto and then to Teleop. When there are only a few packets missed this does not seem like a lot to the person watching the graphs and what not on the FTA table but its not about how many packets are lost its about which packets are lost. Does the FTA have a way to tell that the packet to switch from disable to Auto and Teleop has been received properly? Can the robot tell the field that it has received the packet properly so a status flag can be used to light and led on there comms station? I agree that telling a team they have no idea what is happening is not acceptable. Anytime you say you have no idea what is happening it just means you are either A) not taking enough data points or B) you are not taking the data points on the right data.

Re: Einstein Field issues Handled correctly?
 

@Ruskin: we DO use 5GHz for the robots.

I propose a move to the licensed 3GHz 802.11 band.

Re: Einstein Field issues Handled correctly?
 

Does anyone know which frequency bands the robots use? Could weather radar be messing them up?

Re: Einstein Field issues Handled correctly?
 

Is it possible that since Einstein was the back-up field that if there was an Update on the FMS for every-field, Einstein Never got that update, thus causing all these Robots to have a problem?

Proposal for IRI

All alliances come to IRI and we play the Real Einstein matches to try and find who the winner should be?

Re: Einstein Field issues Handled correctly?
 

well there's an idea nobody I saw thought of before.

Re: Einstein Field issues Handled correctly?
 

5GHz 802.11a WiFi