Radio communications issue

First of all, this is the stuff we are using on the robot:
Linksys WRT54G Router(Radio)
cRIO with the standard Modules(Analog, Digital w/ Sidecar)
Jaguars w/ CIMs(CAN), Sparks w/ Solenoid and Compressors(Although shouldn’t be relevant?)

Our team has used our T-Shirt canon(yes, it’s a bit old) for the past 2 years at homecoming at our school, but the communication with the radio has been weird. We have tried it many times with no people whatsoever in the stands and it works absolutely fine, but the 2 times that we used it with people in the stands(many hundreds of people) we get sparratic radio communications, although there is a solid green light in the DS, and there is anywhere from a 2-6 second delay for either using the joysticks or pressing the fire buttons. I was first thinking people cell phones were interfering with just noise, but someone told me that they wouldn’t put out anything on that frequency, I only saw one hotspot. Then I got thinking and thought devices might be auto-connecting to it but it has a password. I don’t know hardly anything about how WiFi works so I thought that the devices might be pinging the router but apparently it just broadcasts it out every so often. The only thing I can think of at this point is using a hidden network or switching to 5G, but as I said, I only saw 1 hotspot and I don’t know if changing the network to a hidden network would do any good. We had LOS and we were using 2.4G, not to mention we were only about 25 feet away. The problem did disappear when people started leaving the stands so I think that is a strong indicator of students’ cell phones interfering, but I don’t know why, and I don’t have any ideas on possible solutions. If anyone has any ideas of what it could be or have experienced an issue similar to that of ours, I would be grateful for any help you could provide. Thanks.

I would try switching to 5G if possible, and definitely go hidden if you can.

Wifi interference is a potentially major issue for FRC robots, depending on exact environment, and at SoCal events last year for sure there were signs EVERYWHERE (and a periodically-displayed message from FMS) saying “Turn off your WiFi on your phones please”.

It’s not that they’re auto-connecting, it’s that they’re pinging it to find out what it is. That response send takes radio resources.

Also, for your next event: Try tethering. If anybody asks, have them make a PA announcement that if they want the robot to drive wirelessly they need to turn their phones off completely. (They don’t need 'em anyways for the game, eh?)

3 Likes

In addition to changing over to a 5 GHz channel and going hidden (stop broadcasting SSID), I would turn off the “channel/SSID search” features on both radios. Manually setting the connection will help minimize loss of connection.

Every cell phone and smart device that is present is trying to look at the broadcast of your SSID and network to see if it can connect, and what data is being shared on the network, causing delays. Even with 25 people it is likely you would start having drop outs, but it would probably be minimal and you wouldn’t notice. Once you start having 100+ devices around and you’re on 2.4 GHz, you’ll really start noticing drop outs and delays.

3 Likes

We tried tethering as soon as it happened the second time, but ti was too late and I forgot to configure the ethernet network interface for the cRIO, but we are definitely thinking about tethering for the next one, it would just be a pain not to be able to drive around as much, as it is a huge stadium. Thanks for the advice!

I’ve noticed similar behavior in cRio era FRC bots in crowded venues.

Wireless communication is a huge issue for FRC Robots as a whole. The more people in the venue, the more that will have wifi on, that autopings all networks it can see. That can easily overload the networks. Depending on how much work you want to do, and bandwidth utilization of the t-shirt cannon, you could switch it over to a different frequency entirely… Perhaps some high powered Radio Controlled Transmitter/Receiver that is usually used for RC Cars or planes normally.

I was thinking about using an RC transmitter/receiver set for the canon but I think it would be sad to see the whole cRIO go, plus the drive system wouldn’t be as robust and we couldn’t use encoders.

Why would you have to get rid of the cRIO? There would probably be a significant amount of code that would have to change, if not all the code. But, the cRIO is a fairly open platform all things considered.
https://www.ni.com/en-us/shop/compactrio.html

Why would the drive system be less robust, and the encoders be unusable too? As it is currently, the controller sends the inputs to the cRIO and then all calculations are done locally. Swap out the Linksys Router for a transmitter/receiver and it still will work exactly the same. The only difference will be in the communication protocols used to get the controller inputs to the cRIO.

1 Like

I was saying that we were thinking about swapping the cRIO out for a RC Transmitter Receiver set which do not run any code at all, I do not know what you are referencing. That would cut out the code that the cRIO is running.

an RC Transmitter Receiver set would most likely just be a swap out for the radio and laptop/controller you are using currently.

When using an RC Transmitter Receiver set, you will still need some way to decode the information that the Receiver sends out, as an intermediary between the motor controllers and the Receiver. For most off the shelf parts, you are not able to just hook them up to motors and have it work.

You might use a raspberry pi, or some other microprocessor instead of the cRIO though. But that part is still necessary. See this website as a quick reference(https://maker.pro/pcb/projects/remote-control-car). In this example, the cRIO would replace the decoder.

You should just be able to hook up the pwm output of the receiver right into the jaguars we are using, that’s what we did with our other bots that use RC stuff. We didn’t use any intermediary circuitry although you definitely could, but it would require a big systems swap and a bunch of re-coding.