Skip to content

WiFi Debugging

Note: This is intended as a resource to help debug WiFi issues when connected to the robot's WiFi network (the access point generated by the Raspberry Pi on the robot).

Sometimes there may be issues with a robot related to WiFi. These issues can include

  • Takes a long time to connect to the robot with the Deploy Tool or Drive Station
  • Deploy Tool and/or Drive Station frequently disconnect (loose connection to robot)
  • Robot "randomly" stops for a second or two then starts working again when controlling it with a gamepad
  • Robot responds late to gamepad input (high input latency)

While there are other problems that can cause these issues WiFi is a common one. WiFi-related problems can be caused by many things including

  • The distance between the robot and the computer
  • The other WiFi networks in your area
  • The WiFi adapter on your PC or WiFi settings on your PC
  • The WiFi adapter/settings on the Raspberry Pi

First Steps

  • Reboot the robot and your PC
  • If there are still issues follow the "Check the Channel" Steps in the debugging section below
  • If there are still issues run the bandwidth/latency tests
  • If there are still issues
    • If the bandwidth and latency tests seem OK the issues are probably not network related
    • If the bandwidth and latency tests seem to indicate a network problem see the PC WiFi adapter section below

Steps to Debug

Physical Location

WiFi has a limited range and you will likely get the best results if the PC controlling your robot is within 50 feet of the robot. Also make sure there are no walls or other objects between the robot and your PC.

Check the Channel

Short Version

The first step to debugging WiFi issues is to make sure your are on a channel where there is little interference from other nearby WiFi networks on the same channel. Using WiFi Analyzer apps (see recommendations for iOS and Android in long version section below) it is easy to determine what channels nearby networks are using. Ideally, you would choose a channel with no other nearby network on it, however in reality this is not always possible. The most important things to consider if there is not a free channel are:

  1. What channels are the closest (strongest signal) networks using
  2. How many networks are on a given channel

Try to find a channel with few nearby networks and with the weakest signal strengths from nearby networks. Avoiding the channel of the closest networks is key, which often means your home network.

You can use the Network settings tab in the Deploy Tool to change the WiFi channel.

Long Version

As widely-used as WiFi is it does have one major problem: WiFi networks compete with each other. There are a certain number of WiFi channels available and when multiple networks are on the same channel and both in range of your device they end up competing with each other. There are multiple WiFi frequency ranges divided into these channels. The robot uses the 2.4GHz channels (numbered 1 to 14*).

The biggest issues comes when two nearby networks are on the same channel (or close channels as there is some overlap in frequencies). For example, if you have a home WiFi network on the same channel as the robot this could cause many issues, especially since most wireless routers have much more powerful transmitters the Raspberry Pi does. It can also be an issue if other nearby networks are on the same channel, such as neighbor's networks.

The first step to debugging WiFi issues is determining the "best" channel. One easy way to do this is by using a "WiFi Analyzer" app on your phone or computer.

For Android I recommend an open source WiFi Analyzer.

For iOS there are fewer of these apps available for free, however Apple's Airport Utility app should be able to do this. You can follow this guide, however it is more basic than the recommended android app and lacks the ability to graph the channels as will be described below. Instead you'll get a list of networks and their strengths and channels. The same concepts described below still apply.

After scanning for wifi networks (following the guide linked above for iOS or just opening the app on Android) you will get a list of networks in descending order of signal strength. The list will also indicate the network's channel. These scans will show networks from other frequency ranges (such as 5GHz networks) so ignore any where the channel number is not 1 through 14. In the Android app you can tap "Channel Graph" at the bottom to switch to a graph of available networks and the channels they are on (this also shows overlap of channels).

Often this list of channels will be very long. The most important things to consider are

  1. What channels do the closest (strongest signal) networks use
  2. How many networks are on channels that the closest network does not use

Ideally you want to find an unused channel, however that is often not possible so using a channel further from the one in use by the closest networks (usually your home network) is the best option. From there you want to find a channel with the fewest number of other networks on it (you may also want to consider how strong of a signal those other networks have). This is where the channel graph in the Android app can be really helpful.

Once you decide which channel to use you can change the WiFi channel by using the Network Settings tab in the Deploy Tool.

This should help fix many WiFi related issues, however keep in mind that WiFi routers will "seek" the best channel, meaning they may change what channel they use to try to find the best option. The Raspberry Pi does not do this, so it is possible that the best channel for the Pi will change over time. If you find this happening a lot it is advised to change the settings on your home WiFi network (if possible) to use a specific channel instead of "Auto" or "Best".

*In many countries there are restrictions on which channels can be used. In the US the allowed channels are 1 through 11 (source). If you try to configure the Pi to use a channel out of the allowed range for the configured country it will not start the WiFi network and you may have to re-flash the SD card to get access to the robot back.

Test the Network

After making sure your network is on a "good" channel, if you are still having issues it will often be useful to test network bandwidth and latency. The bandwidth is simply how much data can be sent in a certain amount of time. The latency is how long between when one device sends data and when the other receives it.

In both tests we will be testing between the Raspberry Pi and your computer.

Testing Latency

To test network latency we will use a tool builtin to most modern operating systems called ping.

On windows open a command prompt (Win+R then type cmd.exe and hit enter). In the command prompt run

ping -n 10 -l 32 192.168.10.1

On Linux/macOS open a terminal and run

ping -c 10 -s 24 192.168.10.1

This will send 10 packets of 32-bytes each to the raspberry pi and wait for it to send the same data back. It will report how long it took for each packet in milliseconds. A value below 10ms is generally good. If it frequently jumps higher you may want to consider changing WiFi channels and/or rebooting the Pi or your PC. If this does not seem to help see the PC WiFi adapter section below.

Testing Bandwidth

To test network bandwidth we will use a tool called iperf.

As of the Beta7 image iperf3 is included in the image. For older images you will need to copy the sources to the Pi and build from source.

On the Pi login via SSH and run 

iperf3 -s

Then on your PC download iperf3 and run (in the same directory as you extracted iperf)

./iperf3 -c 192.168.10.1

This will give useful information about bandwidth between the Pi and the PC. Generally if the speed is above 2Mbits/sec you should have no problem with the robot, however if the speed suddenly drops to 0 or close to 0 you may want to consider either rebooting the robot or your PC and trying again and/or changing the WiFi channel. If this does not seem to help see the PC WiFi adapter section below.

PC WiFi Adapters

Sometimes network issues are related to the WiFi adapter in your PC. Sometimes an adapter may have trouble with certain channels and sometimes the WiFi adapter may just be weak or have a bad driver. If you are experiencing network issues if possible it is always recommended to run the bandwidth and latency tests from multiple PCs. If one seems to have problems and another does not the problem is likely with the PC WiFi adapter. If both have issues the issue may still be with the Pi.

If you suspect the problem is the PC's WiFi adapter you have a few options:

  • Update your WiFi drivers. If you are using a Windows PC that came with WiFi check the manufacturer's website for driver updates or check the WiFi card vendor's website.
  • If you are using a USB WiFi adapter make sure it is plugged into a USB 2.0 port not a USB 3 port (including a USB-C port using an adapter). Make sure the adapter is not behind your PC (if using a desktop PC). You can also try a different USB port and/or a USB extension cable to move the adapter further form the PC.
  • You may want to consider a different WiFi adapter. Ones that connect to a USB port are generally the easiest way to do this. See the next bullet for information about some of these.
  • If you are using a USB WiFi adapter with builtin antenna these will always work better than the ones without an antenna. That being said, I've had good results with some without antennas including TPLink's TL-WN725N. If you're willing to spend a little more on one with an antenna those almost always are the better option, but if not the TL-WN725N is a decent option and not very expensive.

Advanced Options on The Pi

To perform these steps you will need to be able to login to the Pi via SSH. Alternatively you can login via the UART console using a Raspberry Pi console cable.

Edit /etc/hostapd/hostapd.conf as root (sudo nano /etc/hostapd/hostapd.conf)

Somewhere in the file there should be the following two lines (don't worry about what they are equal to in the file). If one or both don't exist add the missing one(s) at the end of the file

wmm_enabled
wme_enabled

These options can be set either to 1 or 0. Try all of the following combinations and re-run the latency and bandwidth tests after applying each. After making a change make sure to save the file and run sudo systemctl restart hostapd or reboot the Pi. If you find a setup that works leave the file alone and keep that setup.

wmm_enabled=0
wme_enabled=0

wmm_enabled=1
wme_enabled=0

wmm_enabled=0
wme_enabled=1

wmm_enabled=1
wme_enabled=1