View Single Post
  #13   Spotlight this post!  
Unread 10-03-2013, 19:59
Siri's Avatar
Siri Siri is offline
Dare greatly
AKA: 1640 coach 2010-2014
FRC #2641 (PCCR; Refs & RIs)
Team Role: Coach
 
Join Date: Jan 2008
Rookie Year: 2007
Location: PA
Posts: 1,632
Siri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond reputeSiri has a reputation beyond repute
Send a message via ICQ to Siri
Re: What did we learn from week 2 of the 2013 season?

Quote:
Originally Posted by Nuttyman54 View Post
This statement concerns me. One of the outcomes of the Einstein investigation was to impose bandwidth limits on every team to prevent the system from overloading and cutting off comms to other teams. My understanding is that if a team was using too much bandwidth (from camera or otherwise), they are the only team affected. It sounds like entire alliances were having issues from one team using a camera and possibly using more than their allotted bandwidth. Was this the case? If so, it indicates to me that the bandwidth limits were not working as designed.
I don't know what happened with the cameras at NYC, but we had similar issues at Horsham last week. The FTA advised several teams (including us) to play without our dashboard, explaining that it was our choice but we were likely to experience continued lag (lost packets) if we did not. We turned it off for the match and later down-res'd, lowered FPS and fixed our code--afterwards we and our alliance partners experienced no problems, even with us running vision processing and an second camera and others running 1-2 of their own.

However, this does, to my untrained brain, contradict another FTA statement from Horsham: that when we and another team turned off our dashboard for the match in question, everyone's trip times got better. At least, I that's what I thought he said. It seems counter though, so unless someone else has knowledge of a similar situation, I'll assume I misinterpreted him.* Nonetheless, they did not start the match until after this discussion, and it took quite some time to determine it. (They also found another router that needed to be turned off before this dashboard investigation began. Both elements took some time, not that I fault anyone at all for it.)

*EDIT: I guess so then. Is it possible that the bandwidth limits only identify the team that is exceeding them, rather than stopping them all together? Then again, I don't know why we would have had the choice to leave ours on if it was affecting others (and we certainly wouldn't have had we known, not that we didn't anyway). And apparently NYC didn't know who was causing it. Ok, so scratch that idea.

What I learned from Week (1-)2: apparently there's still more education needed to sort out FMS bandwidth issues.


In other news - I learned to make sure I remind drive teams to look for discs fallen and stuck on your robot (count towards your 4), and also that G30 only applies when you contact your loading zone carpet--not when you break the plane. I also learned that pyramids come apart up to 1/4" in normal match play, and that you absolutely, positively have to wait for the green lights before entering the field. Oh, and that if no one warns them, the lighting crews may want to do some really crazy (cool) light tricks on the vision targets, in autonomous, in the finals.
__________________

Last edited by Siri : 10-03-2013 at 20:04.
Reply With Quote