Quote:
Originally Posted by JesseK
On the field in 2013 I witnessed the FMS peak at ~2Mb/s by itself for some reason, even though the FMS whitepaper calls out ~1Mb/s. This is included in the 7Mb/s allocation. That meant we basically had 5Mb/s for everything else and even approaching 3Mb/s for our own data would cause latency issues for all robots on the field.
We only focused on FMS bandwidth last year because we really wanted 640x480@10Hz/30% and wanted a baseline bandwidth to figure out the boundary conditions. I was trying to stitch telemetry data with image data. Wasn't worth it, to be honest - we wound up having to go down to 6Hz before the FTA's stopped complaining about latency. This year we're going to try 320x240@20Hz with 30% compression. Hopefully our whiz kid network programming student is making the net code efficient enough for the telemetry data to keep up.
|
Well, if he is just transmitting raw textual data, he should be fine. If the is sending images or horrendous arrays of image data, big problems will arise.
Also, how do you guys get unlimited speed on the robot? Doesn't the data go through the FMS switches anyways, so is limited to 7mbps?
I think what might be one problem is the Tx power is a bit low. On my DD-WRT router, I can set the power and at full power, I get up to a quarter mile range.
I think the only way to reduce your bandwidth is to have the processing done onboard and only allow the basic FMS communications to run on the network.
If I write an image processing script onboard with the ability to transmit back images, I'd probably write a bwm-ng script so I can monitor the bandwidth and pin the GUI to a specific frequency to keep a constant data rate, e.g. 1mbps.
Another approach would be to just skip everything autonomous and make to robot fully autonomous.