Hoping someone can help us with our radio. We have our roboRIO hooked up to a OM5P-AN. We get a lot of packet loss when we are connected via wifi, significant enough to interfere with manual motor control (i.e. motors will stop turning for a second or more).
We don’t experience loss when the driver station laptop is plugged into the roboRIO via ethernet or USB nor does it happen when the driver station laptop is connected to the radio via ethernet.
After checking the battery and wiring to make sure everything was well-connected and powered, we tried the following with no effect:
swapped out the radio with a different OM5P-AN
swapped out the roboRIO
re-imaged the roboRIO
reconfigured the radio with the Radio Configuration Utilitiy (16.2)
checked wifi channels to ensure there was no interference
At one point, we swapped out the OM5P-AN with a D-Link which we reconfigured with the Radio Configuration Utility. The D-Link had much less loss although there was a little. Swapping the OM5P-AN back in produced the same loss as it originally did.
Any thoughts? The driver station laptop is running Windows 7.
How sound are the connections going from the router too the VRM? Like are all of the wires tinned and soldered, are they just twisted together with electrical tape and bare copper shoved in to the VRM. Even crimped wires aren’t the greatest.
Yes, we did try with another laptop. It actually was worse there. That may have been that laptop. It kept losing track of its network card. The primary laptop has a pretty good track record for wifi but I know that is subject to change.
Forgot to include a snapshot of the loss graph. I hadn’t previously got a good look at the volts graph under it (wasn’t driving). Interesting. Not sure if it’s causative or correlative. Suspicous nonetheless.
In many ways this reminds me of 2015. We had lots of similar problems. Our packet loss sessions came on one minute intervals. At our last event, we quit enabling the USB camera and our problems went away.
I should get a macro for this.
Anyway we had a similar problem where our CAD software had some update thing that would eat our packets alive. Pull up task manager next time you run and see if anything seems out of place.
If you click on the little gear icon near the chart app, you can pull up a list of all the saved logs. It also displays more attributes than just the ones shown on the DS view.
See if there’s another event being logged coinciding with the lost packets.
On the CRIO it was possible to overuse the available ethernet buffers with network traffic, but I doubt something like that is happening on the roborio.
The other thing to check is to see if you are getting network interference from another wifi network in your workspace.
Because this is periodic, I’d open up the task manager, click on Processes and sort by the CPU column. Watch these displays together to see if something doesn’t jump up at the same time as the loss starts. This is commonly caused by a SW update or a scan.
Another solution is to leave the laptop on and plugged in overnight and let it finish its background stuff so that it will leave you alone. But I prefer to turn these things off as it will come back to life in the future and cause the same issues.
Thanks for the suggestions! We’ll investigate futher. Planning on:
check the wiring. You know what the electrical team is going to say if we ask if it’s solid; of course it is! Ethernet cables and connectors were already checked. They’re in great shape.
watch the process list for CPU usage and other culprits that may be hijacking packets
try out another laptop
dig deeper into the DS saved logs
The odd thing is for much of this, the DS should not have been sending or receiving very much data. The camera was disabled.
As for the voltage changes during packet loss, our lead programmer speculates that when the comm fails, the talons are cutting out and back in, causing a change in current draw. That’s a plausible explanation but I don’t want to assume it’s definitely the case. I expect to have more info later tonight.
Results were unsatisfyingly inconclusive. The wiring, while not tinned, is pretty secure so it’s unlikely the cause. We used a few more laptops to connect. They had no trouble connecting but all had varying amounts of packet loss. It wasn’t consistent. At times, it seemed like if the robot was enabled or disabled, the loss basically went away. It was tempting to say it was the network card except we would go back to a previously used laptop that was having more loss and it was also experiencing little to no loss.
I’m at the point that I’m thinking it has to be environmental. We checked wifi channels. No interference there. The motors and motor controllers are quite close to radio but they remained powered through the lossless comm periods.
We’re going to move the robot into another space and try it there tomorrow.
We had experienced this ourself, but again it was brought back to autodesk. We un-installed Autodesk, However still experienced loss. That is because of Akamai Netsession. This program is the Downloader for Autodesk, and is the background downloader causing grief.
Look for it in your add/remove programs. Or if you want to keep autodesk, Akamai has an interface options menu. You can Disable it. That will effectively kill the net connection for Akamai and then you shouldn’t experience the loss as well!
If it’s at all possible, I recommend using a machine with a clean install of Windows and nothing else as the driver station machine. There are lots of cheap machines out there. Slap a [cheap SSD](http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=100008118 50001077 50001455 50001404 4025 4093 50001183 100008118+4093+4025&IsNodeId=1&bop=And&Order=PRICE&PageSize=30) in there, upgrade to Windows 10, and you’re golden.
This was the cause of our packet loss. Every 11 seconds there were a 100% packet loss that was interfering heavily in our PID controller. Killing the process solved it. Thank you very much for the tip
We were having something very similer. Our school has 4 differn’t school wifi networks running, so from the web interface of the OM5P we changed the channel that it runs on. This way it was’t having to fight with all the school networks and then we could keep a solid connection to it.
We were having bad glitches the other night and found that the AP on the robot decided to be on channel 9. The school networks are on 1, 6, and 11. That meant that the robot channel had a huge amount of retransmissions due to interference. I looked at the configuration and that indicates it should typically be on 11.
Last night, the robot was on channel 1 and everything was fine. We also learned that the team’s new laptops only support 2.4 GHz. So we setup another router to bridge 5GHz so we can grab it if needed.
Ethernet cables and connectors were already checked. They’re in great shape.