I’m writing some teacher and student-facing guides to smooth out some reliability issues classrooms have been experiencing with XRPs. Right now, I’m relying on a mix of the official guidance, this forum, and some inference from micropython/XRP hardware. It’s made me hopeful that we can enhance user experience, but I hesitate to offer confident answers if I’m finding mixed ones myself.
Is the primary BLE reliability issue mostly browser-related? That’s what I’ve heard, with ghost states making it difficult for students to reconnect. At least on my end, knowing WebBluetooth quirks helps smoothing out reconnections.
Can we teach users to optimize code to prevent CPU hogging, or is that not a major issue in XRP bluetooth reliability? I mean more than just the infinite loop issue - are loops missing (sleep) a possible issue too?
I know battery power is another issue, but can a combination of better batteries + optimized code make a better difference than one of those alone? Has anyone modded different power setups and had better results?
I don’t mind stress testing these out on my own, but if the answers already exist, I’d love to know. Thank you!
Hi, I don’t use python all, but i may have an idea on how to help the power issue. I use the 4xAA battery pack included int he normal setup connected via an adapter to the USB port to power the logic. I then use a 4xC battery pack to power the motors and other peripherals via the normal power connecter. I am a FRC mentor so my focus was getting a more stable power source for the WIFI subsystem on the boards. Loosing WIFI connectivity has been my biggest issue with the XRPs (both board versions). But since both BTLE and WIFI use the same hardware subsystems it should help some for BTLE as well.
Yeah, our main issues are similar - classrooms are experiencing such frequent connection issues that it’s compromising their desire to use the platform in the first place. So while I know that the FAQ offers a couple reliability tips, I’ve been digging into what more to communicate to teachers to make the experience better.
So you’re using a barrel → micro USB adapter for the batteries and just having extras so you can separate peripherals + logic? Interesting. We’ve got a bunch of miscellaneous battery cases so I might try that.
Do you experience better performance outside of BTLE/WiFi reliability with that setup? The reason I ask is for classrooms that might not want to go with the multi-battery pack setup. If we can teach them how to properly optimize blockly + python code, if CPU hogging IS causing BTLE issues then it might lead to more reliable connections.
Hello,
My issues seemed to be stemming from a condition in FRC known as “brown outs”. It means the same is in the power utility world. I have built a mecanum XRP and driving four of the main motors at the same time uses quite a bit of current. The AAA batteries just didn’t seem to be cutting it. I have no experience with Blocky or Python, C++ and Java only on the XRP. I’m not sure how much you can affect the CPU hogging with the compiler/emulator they have implemented.
My logic was to move the main load to a secondary power source. Thus semi isolating the logic system from the physical work section of the robot.
A secondary benefit of this method is that the XRP now has better traction. With mecanum that is very important.
I had gotten into a discussion with the developers here on this forum about the choice of WIFI bands. The 2.4 band has so much interference any weakening of signal has a very large impact. I had asked why they hadn’t changed to at least the 5 band with the newer chipset. I didn’t get an answer that convinced me they had looked at it.
The recommendation was to tether via USB.
FYI, my XRPs were both doing a Power On Reset when they browned out. I was able to watch the LEDs and verify that was the case.
My back ground in in military mainframes and then PCs and networking when they became popular in the 80s in the private sector. When I retired I was doing telecommunications and internet security for a nation wide insurance company.
Good luck. I’d love to hear if you get any positive results. I’m feeling like I gave a bad recommendation to our FRC team with the XRPs. The Romi’s were more reliable, but had less potential for expansion due to the way the hardware was implemented. I was hoping we could put together a full swerve drive (8 drive motors) with the XRPs. The best I can do is 4 without customizing interfaces.
We had some Bluetooth connectivity issues at first. What OS are you using? There are a few settings that we tried that might have helped. using wireless remotes made the problem worse.
I’m going to assume your using windows (Oddly, our old Lubuntu Chromebooks seemed the most reliable).
Turn off Windows Bluetooth Power Saving:
Open Device Manager.
Expand Bluetooth and right-click your Bluetooth adapter.
Select Properties, then go to the Power Management tab.
Uncheck "Allow the computer to turn off this device to save power.
Disable Chrome Memory Saving for the Editor:
*Open a tab and launch https://xrpcode.wpi.edu/Open another tab and go to chrome://settings/performance
*Under Memory Saver, find Always keep these sites active and click Add.
*The XRP Code Editor should appear under “Currently open sites”—select it and confirm.
Install as an Offline App (to reduce Wi-Fi interference):
Another thing you could try is installing the code editor as a standalone app, and then turning all the computer’s Wi-Fi off. The 2.4 GHz spectrum might just be getting too crowded.
*Open Google Chrome and navigate to https://xrpcode.wpi.edu/
*Click the three vertical dots (⋮) menu in the top right.
*Select Save and share (or Cast, save, and share).
*Click Install XRP Code…
*It can now be run directly from the Start menu offline.
Ultimately, I think the biggest culprit was battery power, alkline batteries just don’t work well for this platform. We switched to good-quality NiMH cells and regulated 1.5V Li-ion AA rechargeable, which i think made the most difference.
I’m using Windows to stress test the robots, but typically classrooms are using Macs or Chromebooks. Currently testing with Alkaline batteries, but we’ve got some NiMH cells (I didn’t purchase them so I can’t speak to the quality yet) so I’ll be seeing if I can do some testing with those, too.
So far I’m finding clear performance dips with unoptimized code, but haven’t had that many issues with BTLE drops yet. But I haven’t had the chance to test with several devices in a room yet, and these tests are pretty non-scientific at the moment.
I expect some problems are with gaps in troubleshooting training for students and instructors, and that’s leading to frequent incorrect reset attempts and frustration. But any levers I can give in trainings are helpful, especially if they’re backed up by whatever performance metrics I can see.