The No More NO COMMS Challenge

All,
It is no secret that I am not a fan of the current FRC control system when it comes to the communication link (the radios, of course, but the entire chain of things that need to stay alive in order to avoid losing comms).

Every time I bring this up, without fail, someone suggests that teams that are having comm issue are just not doing it right; if they only sprinkled the blood of this chicken here and poked that voodoo doll there then comms problems would haunt them never more.

I think this is horse hockey* but I concede that opinions are not data.

So… …let’s get data.

Here is what I propose. Let’s get the best and brightest in the FRC community to come up with a list of behaviors that are “guaranteed” to make comm problems go away.

I will curate the list on this thread (or others as needed). Once we have the definitive list then we can recruit teams to sign up for the No More NO COMMS Challenge, where teams sign a pledge to abide by the tenants of the No More NO COMMS Challenge** and then we will see how these teams do with respect to having communications issues.

I propose that we make providing log files part of the pledge so that we can actually generate statistically significant data with respect to the reliability of the FRC communications link.

So… …let’s get cracking on the list.

Make it as long or as short as it needs to be, just make sure that when we get done, if a team follows every one of the steps, they will have no communications problems.

I am not opposed to using lists others have made as a starting point.

So… …what belongs on the list?

I am all ears.

Dr. Joe J.

*to quote one of Colonel Potter’s favorite euphemisms

**perhaps we can even have someone design a clever sticker they are allowed to place on their robots to signify that they have signed the pledge.

Well, let’s start here https://www.chiefdelphi.com/forums/showpost.php?p=1694886&postcount=286

I do like the idea of a cute logo/sticker attached to a set of best practices - will help make it stick.

For this to work, we really need a PDF document with some of those practices diagramed and photographed as well as thoroughly documented.

This effort has my support.

I’m in. As a KV who sees teams die time and time again this had my support as well. I’ll be thinking of things and suggesting stuff for our list as they come.

Not going to signup until I know what the list entails, but I am intrigued.

Intrigued here as well… I think that list is a good start, but I think we’re looking for best practices for any team, not a complete top-down rethink.

I would say that, from that list #1 is a good idea, but maybe not as far as 195 went. #2 should be a best effort - we don’t know the game and maybe we need to keep the top of the bot clear? #5 - Hot Glue - eh… “secure your connectors” should be sufficient, hot glue makes repair hard. #10 - SEVEN CAMERAS? Hole editing hell Batman! #12 - 4AWG and reaming power connectors? Eh… if needed, maybe… but no… I’d say #14, dedicated, good idea, but have a checklist to be done each match and signed off on.

To add to the list:

  • Use a dedicated VRM for the Radio. Anything else hooked into the VRM introduces additional branches that can short out - and a short on the VRM cuts power to the radio!

  • Properly secure power wires. This means using proper strain relief when hooking up every wire on the critical path (RoboRio, VRM, Radio), and doing proper tug tests on each wire to ensure it can’t come out easily.

  • Ensure the fuses on your PDP are in all the way! It’s happened every year since we went to the RoboRio - I see a team crap out on the field completely, or cycle every time they bump or move. You get back to the pit to find one or both fuses are loose or lost completely in the depths of the robot.

Notes from the list:
For 4, I like using something like this. It lets you put an easy to access plug right on the outside of the robot, so you avoid digging in for anything, even a switch.

I have to disagree with 5. I’ve seen teams add glue to thing, only to them power it on and have something not work because the glue worked its way into the connector and is preventing a connection. With the exception of the barrel jack on the radio, everything else should hold just fine without gluing. And if you use POE and mount the barrel jack with something like the 3D printed radio mount, hot glue won’t add anything.

12 is overkill for most teams out there. Yes, there are some that can benefit, but a whole lot of teams aren’t running enough current to heat up the wires significantly.

The list should be separated into two parts. The first part is design/build. You need a specific list to follow in the shop as you design and build your robot. The second is diagnostics. This would be the list you use at competition to ensure everything keeps working right as you go through the event.

And I’ll finish with a rather recent quote that highlights how teams can so often shoot themselves in the foot. Said by one of my former students, unprompted, after (I assume) she witnessed it:

Sometimes, teams think the appropriate way to fix a broken wire is to strip off the insulation on either side, twist the sides together, and then tape it. Such tactics cause me immense internal agony and should be avoided at all costs.

#3 The barrel jacks that AndyMark sells are not great. I am not a huge fan of them. But properly securing the radio and the Radio Power Retention Clip* allowed 1257’s robot to fall while climbing and not lose comms.

#5 From a CSA prospective I can tell you that this causes more harm than good. Hot glue can seep into the connections and cause even more issues. Also fixing stuff becomes nearly impossible when there is hot glue everywhere. Also you have to configure your radio multiple times per season, more often than not.

#6 If every team ran a pre-match checklist, more matches would start on time. So please do this :slight_smile:

#12 You learn something new everyday! I never would have thought that would be legal but its perfectly legal. The modification of the SB-50 on the other hand, I think that that violates the “no modifications” bit of 2017 R44**

Certainly an interesting read :slight_smile:

*I can’t say that I don’t have a bias towards this as I made it. But I really do believe in it. It works with other barrel jacks too anyway :slight_smile:

**The one (1) ROBOT battery, a single pair of Anderson Power Products (or APP) 2-pole SB type connectors, the one (1) main 120-amp (120A) surface mount circuit breaker (Cooper Bussman P/N: CB185-120 or CB185F-120), and the one (1) CTR Electronics Power Distribution Panel (PDP, P/N: am-2856, 217-4244, 14-806880) shall be connected with 6 AWG (7 SWG or 16 mm2 ) wire or larger, with no additional devices or modifications, as shown in Figure 8-8.

I love this idea. When we get the list settled, we can publish the document in PDF format (hopefully with the No More NO COMMS logo on the cover – graphic designers in the FRC Community, I am lookin’ at all ya’ll)

What do folks think of me starting a public Google Doc that we can work in together?

Dr. Joe J.

The key thing to remember is that all actions that need to be taken, and all that have been listed so far, should support one goal. Namely, creating and supporting a robust pathway for data to get from the driver station to the robot and back.

Joe et. al. What do you think of the following structure? I am willing to continue this later but want other people’s opinion.

I. Ensure the driver station can transmit/receive data over the network
A. Have the driver station computer plugged in (a 3 amp outlet is provided on the field) or, if plugged in is not feasible, running on a fully charged and reliable batter
B. Have the proper driver station software running
C. Disable all software that may prevent the driver station data e.g. anti viruses, firewalls
D. Provide robust physical connections for data transmission.
Ensure that ethernet cables (and usb connections for usb to ethernet dongles)
are fully seated
[INDENT]1. Port savers/USB dongles can be cheap alternatives to replacing the ethernet port on your computer.[/INDENT]
II. Ensure the robot radio is able to bridge the wifi network from the field AP to an on robot ethernet network*
A. Provide a robust power path from the battery to the radio
[INDENT]1. Tighten the nut on the battery posts so that the wires do not wiggle**. Wrap in electrical tape for safety. Same principle applies for nuts on the PDP and main breaker[/INDENT]
[INDENT]2. Seat the Yellow 20 amp breaker fully into the PDP, your finger will hurt if you’ve done it correctly[/INDENT]
[INDENT]3. Create a strong connection between the weidmuller connection on the PDP and the wires for the VRM***[/INDENT]
[INDENT]4. Create a strong connection between the weidmuller connection on the VRM and the wires from the last step***[/INDENT]
[INDENT]5. Create a strong connection between the weidmuller connection on the VRM 12V/2A ports and the wires for the radio***[/INDENT]
[INDENT]6. Seat the wires providing power to the radio using the barrel connector, POE port (make sure it clicks) or both (both is recommended)[/INDENT]
[INDENT]7. Prevent the barrel connector from coming out of the radio during a match[/INDENT]
[INDENT]8. Don’t let your 6 guage wire hit the button on the main breaker[/INDENT]
[INDENT][INDENT]a. Secure the barrel connector using one of the many 3D printed fixtures available across CD[/INDENT][/INDENT]
B. Prevent radio resets from hard hits
[INDENT]Insert info on shock mounting here[/INDENT]
C. Secure Ethernet path from Radio to Rio
[INDENT]Insert notes about ethernet switchs[/INDENT]

*Insert griping about the open mesh radios
**Insert Al’s thoughts about washers on the battery post here
***These steps are somewhat vague because I have yet to establish an opinion on ferrules in weidmuller connections

Fully supportive of this effort.

It helps me as CSA and me as a mentor as long as the requests of the teams are within the rules governing the coming year.

Sounds good! Want those interested to PM our emails or something?

Very supportive of this idea. Ideally once the document is finalized it can be translated to help international teams with less-than-proficiency in English. I don’t have any tips to add off the top of my head that aren’t already in this thread, but I will put them here if I think of any, and I’d be happy to help edit the document together.

I would suggest that we format the document into 3 sections: things to do when building the robot, things to do once or twice per event, and things to do before every match. That should help teams see what they need to do when they need to do it, instead of having to scan through the document to see what they need to do.

I really like this. Maybe also provide a checklist they can go through?

We have used goat’s blood with great success in past years.

Seriously however, I started developing some rudimentary batch scripts to run through network config on windows and try pinging various pieces on our robot to help less-experienced team members still diagnose where the problems were at. Although network config is less of an issue that it was pre-2015, would a standardized set of these be useful?

One tip I would add is to make sure all power and network cables are protected from being hit by game pieces, field elements, or other robots.

What is your view on the legality of using gluing the barrel jack on the radio? I have seen a few decent solutions via 3D printing, but that isn’t a technology accessible to everyone.

I’ve heard and seen many an inspector become irritated over the use of glue on a connection like that, a few demand it is taken off.

From personal experience over the years on these radios, I have seen a direct relationship to the matches a robot sits dead while not using glue and robots running flawlessly where glue on the exterior of the barrel connector is the only change. As with any item it can be used inappropriately, but when used to secure the externals of the connector it can do wonders for a team who is losing power to their radio over and over as the robot takes collisions on the field.

My view is… It’s complicated.

(2017) R71. The Driver Station software, roboRIO, Power Distribution Panel, Pneumatics Control Modules, Voltage Regulator Modules, RSL, 120A breaker, motor controllers, relay modules (per R34-B), Wireless Bridge, and batteries shall not be tampered with, modified, or adjusted in any way (tampering includes drilling, cutting, machining, rewiring, disassembling, etc.), with the following exceptions:

Is hot glue included in the “etc.”? Unless someone asks on the Q&A, you’ll get different answers from different inspectors, and even from different LRI’s.

For me, the concern is that it’s impossible to tell if the hot glue got into the connector or if it’s just on outer casing. Other methods of securing the barrel jack, or better yet using POE, are going to be better. Why tell people that the best option is glue, when glue itself can present an issue if done improperly? I’d rather promote practices that won’t cause issues from an overzealous rookie.

Anything can be done improperly by an overzealous rookie, but even then there are plenty of veterans who make simple mistakes.

Agreed with your first part of the message. Its tough because the radio a flawed product when used in our application and teams can’t be blamed or left with few solutions when they are trying to secure it down to avoid losing COMMs because that little connector shifted.

Well I know what question I’m asking this year so someone can tell me to look up “etc” or “hot glue” in Merriam websters.*

*Still mad.

And Joe - please start a Google Doc - happy to contribute.