[FRC Blog] Radio Silence

[bdaroz]

Originally Posted by Anupam Goli

I'm not a betting man, but I'd wager that a significant percentage of the radio reboots happened because the power connector wouldn't stay in unless you taped the darn thing.

Regardless of rat's nest wiring or not, it's still a pretty bad situation to sit there still for the majority of the match just because your radio power cycled...

One of our early Saturday matches had that happen... despite enough electrical tape that it probably degraded the signal significantly.

Unfortunately it wasn't until after our only competition did we find out we can power it via PoE from the VRM and the power connector for redundancy.

[MrRoboSteve]

Originally Posted by Anupam Goli

I'm not a betting man, but I'd wager that a significant percentage of the radio reboots happened because the power connector wouldn't stay in unless you taped the darn thing....

I'd take the other side of that bet in a second. Of the 300+ matches I helped run this year, nearly all of the issues with radio power were upstream of the barrel connector. It was possible for it to come out, just not common.

The staff made good engineering tradeoffs this year on radio features.

[GeeTwo]

Originally Posted by MrRoboSteve

I'd take the other side of that bet in a second. Of the 300+ matches I helped run this year, nearly all of the issues with radio power were upstream of the barrel connector. It was possible for it to come out, just not common.

The staff made good engineering tradeoffs this year on radio features.

I'm with you on the bet. Once we tightened the connections on the 120A circuit, our radio disconnects went away.

I'd still like to see quicker network connections, both for demos and competition. The long cycle time on initial connection made troubleshooting far more time consuming than it should have been.

[Alan Anderson]

I was CSA at five events this past season. I think I might have seen three occasions where the power connection at the radio was an issue, and one of them was because the team was using the wrong size connector.

Originally Posted by GeeTwo

I'd still like to see quicker network connections, both for demos and competition. The long cycle time on initial connection made troubleshooting far more time consuming than it should have been.

If you want quicker connections for troubleshooting, use USB tethering.

[Chris is me]

We had our barrel connector come out twice, and we used the right size connector. One incident that was particularly humorous is when a team's defense manipulation arm actually landed on the radio connector with lots of speed / force, pulling it out of the radio. So I guess that's one reason to use PoE.

[frcguy]

A trick we used was to loop a ziptie around the barrel connector. Using this method, we had one FMS disconnect the entire season (caused by a faulty Ethernet cable).

http://i.imgur.com/GdhH1Tq.jpg

[kjohnson]

Originally Posted by Anupam Goli

I'm not a betting man, but I'd wager that a significant percentage of the radio reboots happened because the power connector wouldn't stay in unless you taped the darn thing.

You should place that bet. I saw a multitude of radio barrel connectors eject themselves vs defenses (especially the rock wall). After each occurrence I advised teams to tape the connectors in place and it resolved their problems. From the detailed notes I took as FTA, I'd be willing to wager that 75% of the "phantom" radio reboots were related to power on the radio end, not the VRM.

[phargo#1018]

While I understand that the VRM is likely not the cause for the radio dropouts, at a system level all components of the system should be compatible. Compatibility requires an assessment of such factors as tolerance stack-up.

The present VRM can provide Voltages as low as 11.93 Volts at the regulated 12 Volt output. It might be wise to require that the radio operate within the present system - or to alter the present system to operate the radio.

Either specify ~11.5 Volts as the minimum operating Voltage at the radio input or change the VRM such that it provides a minimum of ~12.5 Volts at the 12 Volt output. Either of these solutions removes the possibility of hardware conflict due to Voltage tolerance.

Intended as a suggestion.

[techhelpbb]

Originally Posted by Tanis

Sure, but you will also remove the possibility of teams having camera feeds back to their driver station, and you will likely have to cut out a lot of the other diagnostics as well, because the bandwidth on those things is pretty low.

If you want to do that, then FIRST doesn't need to police the WiFi band any more and the camera limits go away. So this is probably exactly the opposite of the issue. As long as FIRST allows teams to continue to use WiFi and puts FMS only on the 900Mhz then there is no real issue except a slightly more heavy robot.

In point of fact during the bid round in which the RoboRIO was accepted I proposed in writing to FIRST this exact solution.

You also have to start dealing with the limited range and the connection dropping when certain objects come between your DS and your robot again.

That's interesting. Why would 900MHz have a harder time with objects than 2.4GHz or 5GHz? It should be the opposite unless you turn down the 900MHz transmit power substantially. In 1996 we used 900MHz serial for the robot control to the Parallax BASIC Stamp 2 control system with large metal field pieces and I saw no evidence of this issue.

As for the DLinks from previous seasons- one of the major reasons they were dropped was that they were the biggest culprit in the "christmas trees" that we saw in the past. This is when all robots on the field would start moving jerkily or dropping out completely. The DLinks didn't quite conform to the WiFi standards, in a way that almost guaranteed christmas trees in poor connectivity situations.

The D-Links were FCC certified and confirm to the necessary transmit and receive standards. They didn't fully support QoS correctly and therefore the harder the field tried to rate shape them the harder they'd try to send. They only made it worse with some crazy boot behavior and TCP/IP oddities.

Then again if we simply stop allowing power to the radios to be disconnected we'd not have to worry about these crazy boot issues except when loading the field. I really think FIRST should find a way to support batteries for those radios as others have mentioned, but finding a wide enough selection of COTS radios with this feature is going to be tough. I doubt FIRST wants to make custom mobile robot radios as I have mentioned it to them before.

Picking a radio for FRC is not an easy task, and it is often a game of tradeoffs. Knowing the team at FRC working on it, I think they understand the tradeoffs and requirements very well and will make a good choice.

On this we agree these stationary bi-directional transmitters were not meant for mobile robot applications. It's literally a game of compromises till someone decides to make a mobile robot radio in the price range. Frankly the compromises do not actually bother me - the lack of warning about those compromises does bother me. I really do think you can't test for all the problems you will find in use with the sample set you will likely have before you buy. Therefore I am neither surprised nor all that frustrated by Kate's announcement. These radios are cheap compared to the cost of sitting dead on a field. I am actually happy that FIRST has realized the importance to the degree that they are prepared to try to do better continuously even if this is inconvenient.

[cbale2000]

Originally Posted by techhelpbb

If you want to do that, then FIRST doesn't need to police the WiFi band any more and the camera limits go away. So this is probably exactly the opposite of the issue. As long as FIRST allows teams to continue to use WiFi and puts FMS only on the 900Mhz then there is no real issue except a slightly more heavy robot.

In point of fact during the bid round in which the RoboRIO was accepted I proposed in writing to FIRST this exact solution.

So much this. The only real benefit to using WiFi instead of Serial over 900Mhz is the ability to have live video feedback to the driver station, actual command signals take far less bandwidth.

Considering that for most teams reliable video feeds from the robot is nice to have but not a necessity (except those doing vision processing on the laptops of course), to me it makes far more sense to ensure a reliable command signal to the robots over the luxury of a video feed. The old radios (pre-2009) would boot and connect in under 5 seconds, and were supported by a backup battery (through the controller), meaning even if you did somehow drop connection, you'd pick it back up almost instantly, no more sitting on the field for half of the match because of a momentary brownout or sudden impact.

Switching away from the overcrowded 2.4Ghz and 5Ghz frequencies alone would be a huge benefit to field connectivity (plus people could set up WiFi in the pits again), and separating control signals from video could open up more bandwidth for both. Plus these days there are a ton of options available for compact radios of various frequencies due to the growth in the RC aircraft and DIY electronics communities, so finding a suitable Transmitter + Receiver for FRC uses should be much easier now than it was 10 years ago.

[Thad House]

Originally Posted by techhelpbb

The D-Links were FCC certified and confirm to the necessary transmit and receive standards. They didn't fully support QoS correctly and therefore the harder the field tried to rate shape them the harder they'd try to send. They only made it worse with some crazy boot behavior and TCP/IP oddities.

The big issue with the DLinks was that the frequency backoff was hardcoded into the radio, and the value was the same for every radio produced. This meant that if they ever interfered with eachother, that would all start trying to separate from each other, but they would do so at the same rate, which just caused them to keep interfering. That was the root cause for the Christmas Trees. The new radios have that number legitimately randomize, which actually actively allow the radios to not interfere with each other. So even though they were FCC certified, for our uses they had issues, and our options for radios have to be specialized so those issues don't happen.

[techhelpbb]

Originally Posted by Thad House

The big issue with the DLinks was that the frequency backoff was hardcoded into the radio, and the value was the same for every radio produced. This meant that if they ever interfered with eachother, that would all start trying to separate from each other, but they would do so at the same rate, which just caused them to keep interfering. That was the root cause for the Christmas Trees. The new radios have that number legitimately randomize, which actually actively allow the radios to not interfere with each other. So even though they were FCC certified, for our uses they had issues, and our options for radios have to be specialized so those issues don't happen.

Why would that be an issue? You could christmas tree with a single field and all the radios sharing 1 or 2 channels. All 6 robots share those channels if this were the case as you propose a single collision would take out the whole field and clearly that did not happen as packet loss was constant. Where were they going to frequency hunt when they are channel locked? Now on the few occasions they had single channels with no channel bonding there were some christmas trees but they also had lots of traffic from video cameras all trying to flood into the field and competing with the TCP mechanism for re-transmit. QoS is supposed to alter this behavior to give FMS the advantage without making the cameras retry more and more.

Furthermore: even if they follow the same path to degrade they are all at various orientations, distances and signal strengths so the odds are very low they'd actually all block in that way.

[frcguy]

Originally Posted by cbale2000

Considering that for most teams reliable video feeds from the robot is nice to have but not a necessity (except those doing vision processing on the laptops of course), to me it makes far more sense to ensure a reliable command signal to the robots over the luxury of a video feed.

I completely disagree. The camera feed on our driver station was extremely important to us this year. We played several matches without it, and it made it extremely hard for our driver to line up a shot, and I am very confident we are not the only ones to rely on a camera this year. Although I understand there are connection issues, taking a brute force approach and taking away something that teams use is a little absurd. I am sure that we can find a solution that works for everyone.

[AdamHeard]

Originally Posted by frcguy

I completely disagree. The camera feed on our driver station was extremely important to us this year. We played several matches without it, and it made it extremely hard for our driver to line up a shot, and I am very confident we are not the only ones to rely on a camera this year. Although I understand there are connection issues, taking a brute force approach and taking away something that teams use is a little absurd. I am sure that we can find a solution that works for everyone.

I would be a fan of a proprietary low bandwidth (but quick connecting) radio for controls channels, and then the option for teams to run wifi as well for anything they desire.

[cbale2000]

Originally Posted by frcguy

I completely disagree. The camera feed on our driver station was extremely important to us this year. We played several matches without it, and it made it extremely hard for our driver to line up a shot, and I am very confident we are not the only ones to rely on a camera this year. Although I understand there are connection issues, taking a brute force approach and taking away something that teams use is a little absurd. I am sure that we can find a solution that works for everyone.

Don't get me wrong, having a live feed is extremely useful, but if you had the choice of possibly spotty camera connectivity / low fps but near-perfect control connectivity, or a single connection point that will leave you dead on the field for half the match if ANYTHING goes wrong, which would you pick?

Personally I'd rather have continuous control and a possibly temperamental camera connection than the chance of having my whole robot parked on the field doing nothing. I also think that, if the rules continue to allow driver station cameras, it will eliminate much of the need on-board cameras due to the far better framerate and resolutions possible with such a setup. On-board cameras are still great for targeting, but there are plenty of ways to score a goal reliably that don't require a live video link.