We had a meet today, and there was a lot of interference. We had several times when our robot went out of control in teleop, which doesn’t happen when we practice. We had a team help us take the control hub off of selecting a wifi channel automatically, and just selecting one, but that didn’t fully fix the issue. Do you have any suggestions on how to make sure that the robot doesn’t go nutso even in a venue with lots of other wifi connections? We have ordered a new grouding strap in case that is the problem. Is there a best practice for connecting and starting everything up? For example, should we turn on the robot first and then the driver hub? Plug in the remotes before we turn on the driver hub, or after? If we went down to the 2.4 wifi might that help? Any links or advice that you’d be willing to share would be greatly appreciated, and we will pass it on, because it wasn’t just our team struggling today. Is there a way to code in something that might at least make the robot stop if it disconnects, rather than just doing its own thing? Thank you so much in advance.
It’s far more likely that you are experiencing ESD issues and that wifi itself is a red herring here.
There’s a pretty good discussion here about managing ESD.
And a deep dive white paper here.
With the adoption of 5Ghz radios wifi drops due to saturated bandwidth really isn’t a thing anymore. The only thing to be aware of is that 5Ghz is more susceptible to physical barriers than 2.4Ghz. So if your Control Hub is buried deep in a mass of metal, that can be an issue.
Can you be more specific regarding “Robot goes nutso”? Do you mean the robot appears to be lagging behind in commands (keeps running even though you’re telling it to stop, etc…)? I assume the robot only goes “nutso” in Driver Control, but works relatively fine in Auto? Or do the servos stop working sometimes?
I feel like I need more information about what’s going on. I agree with @cmacfarlane that 5GHz has a lot of bandwidth but doesn’t cut through interference, 2.4GHz can cut through interference but if your Control Hub isn’t thoughtfully positioned on the robot you’re going to have problems no matter what frequency you go to (depending on if that’s even the problem). ESD can often be a red herring itself, so I am incredibly hesitant to point any fingers until you can provide some more specific details. If you can’t that’s okay, but it’s impossible to make a good diagnosis otherwise.
One more thing to ask, are you using a Driver Hub and a Control Hub? What is your hardware?
-Danny
Yes, auto works fine, but when they switch to teleop the robot definitely does not respond correctly to the controller. Sometimes it spins like crazy, sometimes it makes the arms on our hanging mechanism go up and down out of control even if those buttons aren’t being pressed. Our driver did notice that there can be a lag in the communication. Other robots are having the same trouble. This link shows what is happening: https://photos.app.goo.gl/4AuS8rZwYjjXyLyd6 our robot is 16312.
Thanks!
Yvonne
In that match at least, seems like the trouble starts at 1:30, when the robots make solid contact.
The problem started right when auto started. That was why the drone launched, the motors that operate the arm started going up and down.
I’m sorry, I see I missed fully responding…we have a control hub with an expansion hub and use the driver hub and 2 Logitech controller s. We are using Android Studio to code.
Yes, auto works fine, but when they switch to teleop the robot definitely does not respond correctly to the controller. Sometimes it spins like crazy, sometimes it makes the arms on our hanging mechanism go up and down out of control even if those buttons aren’t being pressed. Our driver did notice that there can be a lag in the communication. Other robots are having the same trouble. This link shows what is happening: https://photos.app.goo.gl/4AuS8rZwYjjXyLyd6 our robot is 16312.
Thanks!
Yvonne
I presume you mean the problem started right when the Driver Controlled period started?
Thanks for the clarification. Some of the concerns I had included venue Wi-Fi issues interfering with the robot controls, but using a Control Hub and Driver Hub combination allows the control connection to use 802.11w which encrypts control packets thus preventing many issues. This along with the common practice to change team Wi-Fi passwords for every event and keep it a guarded secret only to the coaches and drive team (this should be standard practice for all teams anyway) are best practices for keeping a safe and secure Wi-Fi network.
I can definitely understand lag and disconnections if there is just an incredibly high amount of venue Wi-Fi congestion, robot Wi-Fi congestion, and/or audience/participant HotSpot utilization going on. This is consistent with your reports of the robot spinning (possible robot “rotate” commands that did not get any updated “stop” commands from the gamepads, and possibly received other command packets just barely keeping the hardware watchdog alive). What I don’t understand is why, as you reported, motors that were not being commanded would move - that is not something that generally happens. Even in cases where data packets are corrupted, they don’t typically get corrupted in such a way where corrupted gamepad data would be allowed to be passed on to robot software (at least I’ve never seen it, but I’ll admit I haven’t seen everything).
I’m sorry I don’t have a good answer for you.
-Danny
Yes, I did mean the problem starts right when teleop starts.
Is there a way for other people to get our password? I don’t know that anyone on our team knows it (we would have to look it up). I can tell the team to change it though.
There were definitely a lot of robots experiencing this type of issue, and I believe most of them are using the driver hub and control hub. Does the addition of the expansion hub cause an issue?
What can be done other than asking the audience to turn off hotspots and wifi? It is so difficult to see teams who have worked so hard to design, build, program and driver practice hit the field and have no control. Is there any advice on order of how to turn on equipment, or when to plug in remote controls etc? Is there a Remote control that is less susceptible to the problem?
I appreciate your time.
This feels like an issue one of our local teams has also been experiencing, where ESD causes the gamepads to disconnect from the driver station. In that case, when their robot would hit something on the field (truss, field wall, another robot) the gamepad would disconnect and they would have to hit start+A or start+B to reconnect the gamepad to continue playing. Sometimes the robot stopped altogether, sometimes it continued on a command path for a few seconds before stopping. The robot itself seemed to be fine – it still had green lights, opmode continued to run and robot continued without a reset/reboot – just the gamepad disconnected from the Driver Hub and needed reconnection.
The gamepad-disconnects-due-to-static issue has been discussed somewhat at Gamepads sometimes disconnect from DS following ESD event · Issue #703 · ftctechnh/ftc_app · GitHub . I was a little shocked (pardon the pun) when the local team contacted me for help and it turned out that ESD can indeed cause gamepad disconnects to a driver station, and that this had been reported/experienced before. I never expected ESD on the field to so directly affect a driver station gamepad connection several feet away.
This also feels like one of those instances where a Logitech gamepad gets connected with the controls in a non-neutral position, and that position becomes the new “zero” that is used to send commands to the robot. I don’t know if an ESD gamepad connect/disconnect would also reset the controller’s idea of joystick/trigger “zero”, but if so it could explain why controls went “weird”. (The local team was using Etpark controllers, which might not have the zero-set issues that the Logitech controllers are known to have.)
@jcrywr It might help to know if the misbehaving components on your robot were controllable by joysticks/triggers, buttons, or both. I.e., were any of the misbehaving components commanded by button presses (on/off) as opposed to analog controls?
Of course, this could also be something as simple as intermittent connections on the Driver Hub USB ports. Our team has broken a USB port or two by being a little rough/careless with how they plug in gamepads and their handling of the cables while plugged in. However I’m thinking 16312’s issue is not a USB port issue because the driver station is fairly stationary when the team is having difficulties. It could be an intermittent USB cable though, if we’re looking at gamepad issues.
Returning briefly to the idea of an ESD-generated gamepad disconnect, what would make it particularly troubling is that the ESD event could potentially come from any robot on the field, not just the one being controlled by that particular gamepad.
So, I hope I’m not sending the discussion here on a wild goose chase, but that’s what the video and descriptions remind me of so far. Feel free to ignore this post if it doesn’t feel helpful. But I can report that the ESD-gamepad-disconnect mentioned in the GitHub issue has been a very Real Thing for a couple of teams I work with locally, as in it has been something repeatable for them, with video examples, across multiple Driver Hubs and Control Hubs, etc.
Pm
- Coach, FTC 7172 Technical Difficulties
If this is the case, then Mr. Phil’s assumption might be correct, and ferrite cores placed at the beginning/end of the USB cable may tamp down the effect.
This also sounds exactly like what REV claims they’re seeing in reproducing the BHI260AP IMU ESD issue; shocking the area (creating an EMI event) induces bad behavior in “sensitive” circuits not “connected” in any way to any element they shocked.
Shocking indeed!
-Danny
Thank you. This is actually very helpful.
The arms are controlled by buttons, as opposed to the wheels by the joystick. When the plane launched, that was due to a button issue, although the team wouldn’t have pressed that button right at the beginning of teleop (I assume they did not, but the arms definitely did not respond to the control correctly in end game.) Do you have a recommendation on what gamepads seem to work best? We will look into getting the ferrite chokes.
Thank you for taking the time to reply,
Yvonne
We will get some ferrite chokes. Thank you for all of your help in this. Shocking indeed made me laugh 
_Yvonne
To be honest, I love the Logitech F310. It’s a solid gamepad most of the time, you don’t have to worry about internal batteries or keeping it charged or draining batteries in anything it’s connected to. You also don’t have to worry about the cable pulling out. However, my kids aren’t a big fan of the deadbands and the sensitivity issues. They also don’t like the hand-feel, as they’re more comfortable with the PS5 controllers. Also no kid is going to steal one, their general expression is “ewwww.” I say that’s pretty perfect.
Of all the other controllers we support, the next (and last) controller I like is the PS5. The kids love the feel, they love the responsiveness, they love the layout, they love the features. I love the fact that it’s USB-C on the back (the usb cable doesn’t pull out as easily) and the rumble support and LED feedback (especially for telling you if it’s been configured for use) is pretty handy. I also love the fact that the joystick doesn’t have a MODE button that swaps the DPAD and the left analog stick at random (pet peeve about the Logitech F310). I always plug a USB battery pack into my Driver Hub anyway, so the fact that the PS5 controller charges its batteries using power from the Driver Hub isn’t so bad, but if I didn’t have the USB Battery Pack it would be a no-go. However, it’s a bit pricey. And I don’t trust them out at demos, theft is always a big concern for me.
-Danny
FWIW, my team is using the PS5 gamepads this season. Last season we used the PS4 gamepads but we’ve not liked the micro-B USB connectors (and had some failures at offseason events), so we’ve switched to the PS5 controllers for this season anticipating that the USB-C connectors will be more robust.
Once our drivers started using the PS4 (and now PS5) controllers, they’ve never wanted to go back to the F310. I agree with @ddiaz on the many good points of the F310 and that it’s a solid choice, but we’ve also had just enough issues with them that the PS5 is where we’re at these days.