Quote:
Originally Posted by techhelpbb
1. I've referenced the Einstein report several times during this topic.
2. Without a doubt lots of people are not even going to read this and try it anyway.
3. I've had this discussion over...and over...for years.
The bottom line is if someone asked how to test it that is one thing.
Simply throwing the details at them seems to tune them out (and really that's a common human trait).
|
I am of the mindset if you are posting as an authority or advocate for a solution, technology, or other reason, provide only the facts and let the user decide what they will with the information. As a mentor, I try to be as factually correct in my posts as humanly possible. You don't know who is reading, or how something can be interpreted if you leave room for interpretation. If you are providing advice or opinion, then state as such, so as to not confuse anyone what is fact vs. opinion. Your statements confused me and were open to some interpretation, which is why I offered what I though would be clarification. I am not trying to offend anyone, and if I did I apologize. The goal is to help answer the OP's question, and also be factual about what we have at hand, so that anyone using this post as reference can make the right decision, now, or in the future.
Quote:
Originally Posted by techhelpbb
If you read again I did not say the real time video over WiFi can flood the cRIO queue.
I said sending real time video over the WiFi can cause network issues that prevent your cRIO from getting FMS packets in time to prevent a timed disable.
|
What other network issues can arise on the cRIO which will stop it from reading DS packets if it is not a filled buffer? As far as I am aware, the thread priority is set such that the DS protocol has the highest priority and the user thread is lower on the cRIO. This means that even if the robot code is in an infinite loop, it should still be able to read and execute on a DS packet. The only way I know how to STOP the cRIO from reading the DS packets is to flood the network buffer with USER packets only, in which case all DS packets are thrown away by the NIC because there is no room for it. The robot can not execute on a DS packet, because it's not getting it.
You state you were not saying that sending data over WiFI causes the buffer to fill, but sending data over WiFi can prevent the cRIO from reading a DS packet. Please elaborate for us what is going on here.
Quote:
Originally Posted by techhelpbb
You reduced your video bandwidth so you could send it in the bandwidth FIRST actually has on the competition field.
So what do you think would happen if you used up 7Mb of bandwidth?
|
This is the kind of information I want to convey. The message I get from your message is that sending video over WiFi is bad, and you correctly identify a problem, but don't really give it the caveat it deserves. Whether you explicitly state it or not, it is very much implied. Which I believe is a very wrong message. In stead of using objective terms like "lots of data" or "real-time" video. I provided concrete values that work. If you were trying to state "try to avoid sending real-time data which approaches anything over 5Mbits/s" for example, then the message would be much different, and it just didn't read that way for me. I believe that is a good recommendation to a person asking about the link limitations.
Quote:
Originally Posted by techhelpbb
I do not see why I should provide evidence of something I never wrote.
However the ARP function the D-Link products implement is questionable.
I provided links earlier if you would like to see what D-Link has to say about their own bridge function.
|
It was implied by your statement that sending data over WiFi can hinder the cRIOs ability to receive DS packets. Which I do not see how that's possible, unless you were flooding your network with broadcast packets . In a properly switched network, as is on the Robot, provided by the D-link, they data traffic should be mutually exclusive. Your statement suggests, that sending packets over WiFi, somehow make its way to the queue of the cRIO NIC and help fill it up, because that is the confirmed way to stop cRIO comms. Unless you have evidence of another network anomaly going on which causes the cRIO to loose DS packets by transmitting data over WiFi
Quote:
Originally Posted by techhelpbb
I am very curious what data your video coprocessor is sending that is so large that it needs high throughput? What are you sending to the cRIO/RoboRio if the coprocessor is doing the vision part?
|
We sent from the beagleBone to the cRIO, hot target status, left or right target, state of the beagle-bone, state of the camera, and some other values. This showed the driveTeam the health of the vision system as it was running. It was about 15 bytes of data, 20 times a second.
We sent from the cRIO to the beagleBone, when the match started (to signal when to grab the hot target frame), and when the match reached 5s (signaling a left to right hot goal switch). We could also send other cal values which allowed us to tune our filter params from the driver station if we needed too. These were all async transmissions.
Quote:
Originally Posted by techhelpbb
Is there really some reason you can not have digital pins or even simple binary data for things like: Move up more, Move down more, On target, Not on target?
|
This is a valid solution. The only downside I see is How many IO pins do you need to use in order to do that. IO is not scalable, but if it works for you, or for others, then by all means go ahead and use it. My advice would be to try ethernet first, because I do not see a problem using it, and when done correctly, you can have a fully scalable vision system that is robust, that you can use for future years no matter the challenge.
Quote:
Originally Posted by techhelpbb
I am still utterly perplexed by this. If I prove to you there can be an impact on the field network when you send data on 2 switch ports locally what exactly do you think you are going to do about that?
|
I personally would like to see evidence of this and I am sure other teams would too, because I think a lot of teams are under the impression that this is not true, and they can use the full potential of the LAN onboard the robot. Your evidence would correct teams usage of the local network. The OP also asked this question in their original post.
We had a lot of network issues in 2012. We got over most of them in 2013, and had virtually no issues in 2014. If you have evidence of issues that can arise on the system we all use, then it should be posted for the greater community to understand. I believe for a lot of teams most of the details around FMS are based on what we "think" vs. what we "know". However, I can't change what I "think" without supporting data as I am sure you can appreciate.
I believe the OP has received their answer, and our conversation is just side tracking now. If you have any evidence to help the community at large I think it would be beneficial to post, if not, we can take this conversation offline if you wish to continue. Please feel free to PM me if you wish.
Thanks.
Regards,
Kevin