Quote:
Originally Posted by Justin
Question, and let me just preface this by saying I have no experience with this years control system.
Isn't the field, etc. using the 802.11n wifi protocol this year? It's my understanding that wireless-N is capable of throughput somewhere in the 100mbps range which makes me wonder why on earth you would be limited to 900 some K and have to compress video down to 160x120. It seems with N you ought to be able to do at least standard def video.
I would think something like this would be the whole rationale for using Wireless-N for filed communications otherwise it seems like way overkill if you're just going to move a few K worth of data round.
I apologize in advance if my severe lack of knowledge makes this question a total waste of time.
Just curious,
Justin
|
While 802.11N does have high raw throughput, it is not only throughput that matters. Control of the Robot, and real-time video, require very low round trip latency and low jitter. This is why UDP protocol (unreliable datagrams) is used at the modest rate of 50 packets packets per second in each direction. Packets aren't worth much if anything in this environment if they are delayed much more than 25 ms.
TCP protocol provides reliable streams at the expense of delay and jitter. TCP is unsuitable for real time applications except where the error rates are extremely low, e.g. a local Ethernet loop. With wireless, there are retransmissions that occur at layer 2 to get around interference issues (these apply to both UDP and TCP) but the retransmissions at Layer 3 for TCP would basically kill any hope of meeting the latency and jitter requirements.
There are solutions (QoS) that can prioritize UDP traffic and allow a smooth coexistence of UDP and TCP. It's a good bet that these will be deployed in future competition. FIRST has wisely chosen to deploy slowly and move step by step as it rolls out the new system. The system seems to be working extremely well at the regionals. We still haven't seen how it performs with four fields in the Georgia Dome.
The next logical step will likely be to deploy RTP/RTSP for the camera. The present camera uses MJPEG as multi-part MIME messages in an HTTP response carried over TCP/IP. This is really unsuitable for the field environment, although it may work well in the lab.
The biggest gain for the moment is that 802.11N operating in the 5.4 GHZ band(s) provides many more channels and they are largely uncluttered at the moment. The 2.4MHZ junk bands (as the FCC calls them) are filled with, well, junk. As mobile phones (and venus) begin deploying 802.11N in the 5.4GHZ bands, the interference is going to dramatically increase. Accordingly, it's wise to remain ultraconservative.
At the moment we have about 400kbps of reliable bandwidth in both directions. To those of us who started with 75 baud, this sure seems like a lot
As for compression, the only way to get images under 2K bytes is to use low resolution (160x120) and very high compression. Remember, the camera produces MJPEG images - not MPEG. MJPEG video is just a series of jpg pictures at the frame rate. Each frame stands by itself (like an MPEG I-Frame). There is no compression involving differences with forward and backward frames and in the real-time environment these delays cannot always be tolerated.
And don't apologize for asking questions - that's what the forum is about.