The theoretical maximum transfer speed over wireless is 5 MB/s. The actual maximum is less, due to
packet and header overhead. The camera can easily saturate the link at that speed. When congestion
starts to drop packets, it makes the problem worse over tcp, as the lost packets have to be retransmitted.
1000 mbit / s = 100 MB / s
_100 mbit / s = _10 MB / s
__50 mbit / s = __5 MB / s
We did some experiments with the camera and the crio.
Ex.0 (wpi lib) receive images via http on crio and retransmit to DS via TCP.
This failed last year (2010) when we tried to run video. FIRST restricted all video to run over TCP.
Positives:
- ???
Negatives:
- data sent over TCP, lost packets are re-transmitted
- camera data saturates network link disabling robot communications
- crio tcp network stack backs up setting off hardware watchdog
- did not reach 20 fps, camera task never yields
Ex.1 receive images via http on crio and retransmit to DS via UDP.
This was our first idea this year (2011) to improve the situation. We got approximately 4 img/s.
One drawback to this experiment is that the crio task for receiving the images from the camera
and sending them to the DS is never idle, so it takes away available CPU cycles from controlling
the robot. We are not currently able to measure what performance other tasks impact the processor.
Positives: data sent over UDP, lost packets are not re-transmitted
Negatives: did not reach 20 fps, camera task never yields
Ex.1 receive images via http on the DS and display them at 20 fps.
Positives:
- 18 to 20 fps display on DS
- packets backup into camera not crio
- no hardware watchdog timeouts on crio
Negatives:
- data sent over TCP, lost packets are re-transmitted