search

carologistics / hardware

3D Models, hardware specs and documentation for our Robotinos
0 stars 0 forks source link

Trying a new access point to reduce network issues #21

Closed hndr-k closed 8 months ago

hndr-k commented 2 years ago

During RC2022 we struggled with our WiFi maybe using a different access point could improve this issue. Therefore research regarding a more robust network and possible access points is needed,

nlimpert commented 2 years ago

In my opinion the lack of performance is caused by the TP-Link APs that were mounted on the robots. In the past @morxa spent quite some time researching for a proper WiFi AP that is suitable for a RoboCup scenario and came up with the Engenius EAP1300. This AP in combination with the Thinkpad laptops mounted on the robots was quite successful which is not what we are using currently.

I would suggest to instead opt for PCIe WiFi cards that have to be installed in the Robotino and extend the antennas to a topmost position of the Robotino. Keep an eye for PCIe cards that do not have any region locking onboard and that also fit into the Robotino.

At RC2022 the product manager of the Robotino (Christian Deppe) admitted that the TP Link is not really suitable for such a setup (while it is ironically sold with the Robotino - top Festo quality).

my 2 cents.

mhenn commented 2 years ago

I guess the first step should be to evaluate the current network utilisation. Seeing that we used several GB within just a few games during the RC, using the LTE setup, points to unneccessary wasteful behaviour on our side.

Since we had below 50 % signal strength(tested with several different devices), while sitting right next to the router during the RC, I actually don't think that just changing the receiver will change that much.

Therefore we should re-evaluate all network components as well as aforementioned our usage of the network, before buying anything.

nlimpert commented 2 years ago

Just to be clear; the trouble wasn't low throughput, latency or that we can't use all of the possibly available bandwidth of the particular WiFi standard. Instead the problem was paket loss, which did not occur with the LTE setup anymore (using tailscale).

Also the info that we used several GB per game was also misleading as the actual value differed in the end (given the details from the provider's app - iirc in the end Simon's phone still had 15 GB available before the final games).

Also keep in mind that during this RC you probably tried the signal strength with the Linksys AP instead of the aforementioned Engenius.

So for the evaluation I'd ensure that one is looking at the actual problem (paket loss as mentioned above).

nlimpert commented 2 years ago

Before the question arises why we used the Linksys AP instead of the Engenius; that was setup right after we discovered the poor performance with the general WiFi setup using the Engenius AP and the TP Link devices on the bots in the hope of having less paket loss. However in the end that didn't work too.

hndr-k commented 2 years ago

Regarding the paket loss, did we check the buffer queue of the socket? As I have encountered similar problems within ROS, which was due to full UDP buffer, if a messages had to be split in too many UDP pakets. Did we use TCP or UDP this RC and if TCP was chosen, why so?

So if there is a specific reason for TCP, it would be helpful to know.

TarikViehmann commented 8 months ago

We settled with the Ubiquiti LR ap to span the network and with PCI cards for the robotinos.