Quote:
Originally Posted by NotInControl
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.
|
I have to say that when I read this I think back to the advertised bandwidth on the network and immediately recognize that multiple people from multiple regions have determined that the best way to get video to a driver's station from a robot reliably is to use quite a bit less than the advertised bandwidth in official sources.
So if this is about factually correct and supported by evidence we all have a problem. It clearly is not exclusive to what I wrote. The question is why should I do any more than I have so that I can then (as I have for years) go cleanup after it anyway both as a mentor and a volunteer?
It is increasingly supported by evidence that such an effort is literally a waste of my time regardless of what nonsense is used to push me to expend the effort.
Let me take that a step further...for all of this...can anyone please provide a detailed and complete analysis of a field 'christmas tree' and the correct procedure to eliminate it?
Cause I see cycling the power of fielded robots at different moments in my future.
Furthermore, the whole 'who do you think you are to speak for FIRST bit' is old and without merit.
I specifically and directly said it was my opinion in several places.
I even took both FIRST and Team 11/193 off the hook.
Every year someone tries these tactics with me it gets predictable and old.
Kind of like trying to get video to driver's stations.
Quote:
Originally Posted by NotInControl
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.
|
I refuse to let you devalue the core points by making this overcomplicated.
I ask you instead to set your Axis camera to 640x480, at the highest color depth you can find, minimal compression and 30 frames per second then send that to your driver's station and drive your robot on a competition field. Then come to me when you start having strange issues with your robot and tell me there's nothing that can happen over the WiFi sending video to a driver's station that can have an impact and end up with a disabled robot here and there.
Oh wait *SMACKS FOREHEAD* never mind I do that test every year at a competition.
All I have to do to test it this year is show up.
Quote:
Originally Posted by NotInControl
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.
|
I have some really bad news for you.
If the published values are wrong.
If the channel bonding on the fields and settings change during the competition to 'adapt' and they do.
I have more than noticed that and reported it.
In a heartbeat that specific recommendation can instantly fail.
So I can either confront FIRST about that and face it that's worthless....or....
If you don't want to have video problems sending video to your driver's station:
Try not to send video to your driver's station (pretty logical for someone as silly as me).
If you must send video to your driver's station then just do the best you can, and realistically that is all that you have done by halving the bandwidth you use.
If you don't believe me I await the first time your recommendation fails for you because I have seen what will happen.
All that it would take to make this fail as well is a subtle change in the field load balancer.
Quote:
Originally Posted by NotInControl
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.
|
This does not sound like the kind of data that would be all that hard to move even over raw digital I/O.
You obviously have a fine grasp of TCP/IP mechanics so I am sure it's no big deal to send it and service it for your team.
Problem is - a lot of teams do not have as a great a grasp on the subject.
I find it hard to tell teams to develop that while they tackle vision.
Seems to me like it is asking quite a bit - a great challenge if you can rise to it - or a pain if you stumble.
Quote:
Originally Posted by NotInControl
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.
|
Firstly CAN had the same promise of being future proof.
Were not that many teams using it at the competitions I was at and I have the records from them.
This is not a dig at CAN or the Jaguar - just saying I sometimes wonder if CAN is FIRST's Beta/VHS.
Secondly to make more pins without getting fancy you can use addressing and multiplexing.
One of the problems I see with FIRST not really requiring electronics knowledge is that it seems we use TCP/IP like a hammer and forget that it depends on simple digital concepts. I realize that students do not have to use discrete TTL/CMOS anymore but I wonder if the logic or the finite issues of TCP/IP are more difficult to grasp.
You know when I was in school - you learned digital logic first - then took college courses on the network physical layer and then later courses on TCP/IP. It almost sounds like you advocate the reverse.
Quote:
Originally Posted by NotInControl
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.
|
My response:
I did not want this topic side tracked because as you can see that is what is going on.
So I asked very early to take the details offline, or at least, into another topic.
If I continue to dig into this - like I do professionally - you will eventually get your answers at the expense of my time.
However if I am not *very* careful I might be providing knowledge that someone can abuse.
Further, as you have said, the D-Link is back this year.
It is too late to alter course because of the way FIRST gathers the KOP.
So what we have here is something that is just bad for me personally any way you look:
1. No field I can test on without disrupting something.
2. Lots of time/money further documenting issues for problems other professionals have seen.
3. A distraction from my mentoring for Team 11.
4. A distraction from my personal projects.
5. A distraction from my professional projects.
6. Something I will still be cleaning up when I volunteer.
7. The potential it gets abused.
8. Helping D-Link fix their commercial product at my personal expense.
9. All the monetary, social and political head aches that come with all of the above.
I can have all that - so that we can use TCP/IP like a hammer on every nail.
Hmmm....
Walks over and turns off my light switch.
Did not have to worry about a dead iPhone battery to turn off the light.
Sorry if that was rough on you/FIRST/the guy next door/the aliens in orbit/the NSA whatever.
Sometimes you just gotta say what is on your mind, especially when you help pay the bills.
[DISCLAIMER]
THIS SARCASM IS PROVIDED BY BRIAN CAUSE SOMETIMES PEOPLE GRIND MY GEARS.
BRIAN's SARCASM IS NOT NECESSARILY THE VIEW OF FIRST, TEAM 11, TEAM 193 OR THE PEOPLE THAT MAKE TIN FOIL.
SMILE CAUSE IT IS GOOD FOR YOU.