Quote:
Originally Posted by apalrd
1. The camera has to send complete images over WiFi 15 times per second. That's a lot of bandwidth, something WiFi can't always handle as fast as we would like.
2. The Dashboard Data is updated at the same frequency as the robot comm packets, 20hz or every 50ms. The Camera image is different, updating as fast as it can (which isn't very fast, usually around 10hz max)
3. If the robot slows down, either you are sending too much data and the field is throttling bandwidth, or your code is using more than the CPU can provide. I have seen both. If you only have a problem on the field, it's the first. Otherwise, it is probably the second. The solution is to compress the image more and send less (smaller image), or lessen use on CPU.
4. We have had problems with the Dashboard image, but we didn't use it anyway so we disabled it.
|
There's more than enough bandwidth to send the video. The main reason for the slowdown is
how data is sent, not how much.
Networking 101:
In the modern world of networking, there are two main network protocols,
UDP and
TCP.
TCP (Transmission Control Protocol) comes first. It is an extremely common and robust protocol (http, the "internet protocol", runs on top of it). It works by forming a connection between two devices and then sending data across the connection. The protocol is managed: code running behind the scenes makes sure that the data arrives to the program using a TCP socket
undamaged and in order. It does this in the following ways:
- If a packet doesn't make it across the network intact, TCP stops all other incoming packets from being received and requests the bad packet to be resent.
- If a packet arrives out of order, the TCP socket waits to deliver it until the packets that come before it in the stream arrive.
This can make TCP bad for use in real-time applications where getting new data (such as frames in a video stream) is more important than waiting for the old data to come in undamaged.
UDP (User Datagram Protocol) is the second type, and the simpler of the two. It is a
connectionless protocol. Unlike TCP, sending data over a UDP socket just "shouts" it at the target IP without first forming a connection. There is no confirmation that the packets are received. The header of each packet sent across the network contains only its source, its destination, a packet length, and a checksum to confirm that this data hasn't been mangled. Because of its connectionless nature and small header, UDP provides
no guarantee that the packets arrive intact or in order. It is up to the programmer to assure these things using data they send in the packets.
However, the less-structured nature of UDP can be an advantage in real-time applications where getting new data (such as frames in a video stream) is more important than waiting for old data to be resent or be put into order. Video chat programs such as Skype usually use UDP because of this.
How it relates:
The robot comm packets and dashboard packets are sent in UDP, which makes sense since up-to-date information is the critical factor here. However, for a reason that I cannot understand in any way, the video is sent using TCP. Consider why this is bad:
- If a frame of video is bad, it would make the most sense for the dashboard program to just skip it and move onto the next frame. However, this is impossible in TCP, as the connection itself stops until it can retrieve the bad frame, slowing down the dashboard.
- Not only is the dashboard slowed down, but the robot is slowed down too. The networking task in charge of sending the video has to stop sending new information in order to resend the bad data. This can cause performance issues in the robot as more time is spent "catching up" and less time is spent executing other code.
TheDominis and I appealed to the GDC some time ago to be allowed to develop our own UDP video system, but for whatever reason we were shut down. I'm still at a loss for why, but for now we're stuck with the TCP video feed.