Go to Post They are "Human Dream and Inspiration Enablement Devices" but since that takes too long to say and explain I use the word "robot". - Foster [more]
Home
Go Back   Chief Delphi > FIRST > General Forum
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
View Poll Results: What do you think?
They handled it correctaly 51 12.81%
They did not handle it correctly 114 28.64%
It was horrible 220 55.28%
Other post below 13 3.27%
Voters: 398. You may not vote on this poll

 
 
Thread Tools Rating: Thread Rating: 12 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #11   Spotlight this post!  
Unread 30-04-2012, 10:22
nuttle nuttle is offline
Registered User
AKA: Allen Nuttle
FRC #4080
Team Role: Mentor
 
Join Date: Mar 2010
Rookie Year: 2009
Location: United States
Posts: 104
nuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud ofnuttle has much to be proud of
Re: Einstein Field issues Handled correctly?

My guess is that the issue is triggered by more bandwidth being needed than there is available. So, robots that upload lots of telemetry, all have video feeds, etc. combined with anything that causes less availible bandwidth is the magic combination. Fixing whaever is limiting the bandwidth makes the problem go away, but really doesn't solve the deeper issue. When bandwidth is tight, packets drop, TPC requests retransmissions, and this only results in more bandwidth being needed. Traffic on some critical connections gets held up for long enough that robots die and do not recover. If this is right, the old radios in 2010 turned up the same underlying issue but the problem went away when everyone was told to use the new radios.

Depending on how things are implemented, a single robot could have more than one video stream coming from a single camera -- one for the dashboard and another one for off-board target tracking. One way to simulate this would be to open extra web sessions with the camera. The 'netem' tool I mentioned before can simulate a network with various issues in the network and is a more controlled way to try to cause this type of problem.

This wouldn't be an issue when using a tether, and a single robot running over wireless would have six times the bandwidth as when a match is being played and so would not likely see this either. The exact traffic when running under the FMS might be different as well. Using tcpdump / wireshark would allow digging into the problem.

Just thought I'd throw this out since this angle hasn't come up in this thread and it is one theory that should be considered, I think. THe solution would involve taking steps to make sure the critical data always gets through by limiting the bandwidth that is allowed for less critical data when bandwidth is tight. Giving each team an equal amount of bandwidth is only fair, and things like the video feed will do OK with limited bandwidth, usually by dropping frames. It would be good to have a way for teams to test with limited bandwidth as well. It would be possible to have a gauge on the driver station showing bandwidth used or something along these lines to help teams catch issues they can contol that cause them to use more bandwidth than they need and generally be more aware of this.
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 14:57.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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