I’m a mentor for a FRC team. We have purchased several of the original Beta XRP kits and I have personally purchased the new “current non beta” version of the board. When running the WPIlib version of the firmware I can easily connect to either the beta or non-beta version via Wifi. While driving the XRP in teleop mode and within a 15 ft range at home with one other Wifi router in the house, the XRP keeps disconnecting the Wifi. This is reproduceable with four different laptops. I’ve tried with a Lenovo T530 laptop, Thinkpad X1 Yoga, Thinkpad P14s and a HP-16z-db000 laptop. At first I assumed it was a power related issue. I thought maybe the battery pack barrel connector was not getting a proper tight connection causing brownouts. I’ve tried several different barrel connectors and have even soldered battery leads directly to the board and the issue stays the same. Random Wifi disconnects even while the XRP is stationary disconnects occur. Are there any known issues with the Wifi hardware/driver on the XRP boards? Is anyone else having similar issues? Just to confirm I’m using new batteries NiMh and they test good under load. I’ve even built a rig to allow the use of a Battery Beak (like for the FTC battery packs), and still testing good.
Hi there, sorry to hear you’re having trouble!
I suspect it’s not a power problem. Rather, I think the WPILib firmware or something may just get upset if communication drops for any reason (which inherently happens a lot with WiFi), and fails to reconnect properly.
@ZeeQueue is one of the WPILib firmware developers, who might be able to help here.
Thank you for the response. I’m a retired networking engineer, so I know all about Wifi issues. This is why I’m surprised the use of 2.4 instead of 5. I’ve noticed over the years the 2.4 connections are very unstable (especially in a crowded environment like class rooms full of XRPs and Romis). Doesn’t the Pico W have 5 capabilities?
If the error recovery protocols built into TCP/IP can be fully utilized, I think thing should get better, but 5 would be much better as well.
Thank you again.
Larry C.
Currently, 5GHz WiFi is incredibly uncommon in the microcontroller world, unfortunately (forget about 6GHz…). Everything is typically 2.4GHz (WiFi, BLE, Zigbee, Thread, etc.) or 900MHz (LoRa, Z-Wave, etc.). The only 5GHz microcontroller devices I’m aware of are the ESP32-C5, the NORA-W306, and the AW-CU488. Everything else with a radio is likely 2.4GHz or 900MHz. I’m hopeful that we’ll see more 5GHz devices in the future!
I also have noticed occasional drops in wifi, or at least dropped packets and/or jitter. This can be frustrating because the robot code is running in the simulator, so things like autonomous commands are very unreliable with these packet drops (the protocol is unreliable UDP).
Our team probably next year is going to add a 5th battery, because 4 NiMh is only 4.8v, whereas adding 1 more would bring it to the normal alkaline level of 6v. Have you tried alkaline to see if you get better performance? This isn’t mainly for wifi issues, I imagine network saturation is the main culprit here. But maybe it helps a bit? We also considered putting in a dedicated router for these devices and setting the channel as far away from the normal router as possible, but can’t prevent the neighboring routers.
We found XRP is a fantastic platform to teach FRC programming on! Hopefully it can get better.
We have also been looking at doing a version of this over Bluetooth. It is nice not to have to keep loosing the access to the internet each time you want to run.
For the gamepad support I have gotten down to around 60ms response. Not as fast as the 20ms of the roboRIO but enough for an XRP.
You can connect to a wifi router, and then you don’t lose internet.
But how do you use bluetooth for this? The robot code is running in the simulator, not on the robot, right?
Yes a router helps in multiple ways. Also correct on the robot code. It would be a change to the simulator.
Sound good. I’m guessing 16.6 Hz but reliable is going to be more usable than 50Hz but unreliable/jittery!
I have been unable to reliably connect any of my xrp bots to either of my wifi access points. Sometimes a bot connects and sometimes it does not. Once connected, the bot will disconnect at any time for no obvious reason. Consequently it is difficult to use the web server when trying to use a wifi access point. It feels like a power problem but I don’t really know. However I can get the xrp to act as a wifi access point fairly reliably. That is how I run the web server.
-Franklin
FWIW the “nominal voltage” of alkaline and NiMH cells are defined differently. The 1.5V for alkaline is at the maximum state of charge, whereas the 1.2V for NiMH is the average over the entire state of charge range. Under load, NiMH batteries actually maintain a higher voltage than alkaline after losing ~30% SoC:
source
Nominal battery voltages are misleading, much better to look at the discharge curve. NiMH batteries have a much lower internal resistance than alkaline, so they’re generally just better (except for the higher up front cost, but they’re rechargeable).
Additionally, the voltage regulator on the XRP has a cutoff voltage of ~3.5V. From my testing, the only time the voltage drops that low with 4x NiMH batteries is with very low SoC (<10%) under heavy load (eg. both drive motors stalled). But the low voltage LED on the new board will start illuminating long before a brownout occurs, so if that LED is not illuminating at all, then you’re almost certainly not having any kind of power problem.
With all that said, if you do find you get more stability from a higher battery voltage, would love to hear about it!