connection error lighting system

VEX V5 General Discussion General Forum
#1

Has this ever happened to you? In the middle of a pivotal gateway match, your robot suddenly sputters and dies. No matter how much you desperately mash onthe controls, the only sign of life on your robot is the dim light on the cortex indicating that it has lost connection to the field. Your coach signals frantically to the referee, who is too engrossed in the action of the game to take any notice. All you can do is watch helplessly as the opposing team continues to score unabated.

Well my team was sick and tired of connection errors like these ruining our chances at victory. That’s why we designed a lighting system for our robot that acts as a connection indicator.

The basic idea is that you mount one or more LEDs to your robot in easy to see locations. You then add code that will illuminate the LEDs whenever your robot loses connection to the field. Before a match, you speak with the ref and tell him or her about this lighting system. Then, if you happen to lose connection during a match, the fact that it is a connectivity problem rather than a problem with your robot will be immediately apparent to the referee.

Here is a picture of how we mounted an indicator LED to our robot.

[ATTACH]5443[/ATTACH]

The LED then plugs into one of the digital input/output ports on the cortex.

This is how I got the LEDs working in RobotC:

First, under Robot->Motor and Sensors Setup, register the input port you plugged the LED into as a “Digital Out” port. Then, give it a name (in my program, I called it ‘LED_RED’).

Then, in “pre-auton”, add the following line of code:


SensorValue[LED_RED] = 1;

The reason for this is that the LEDs will turn ON when given a value of 0, and will turn OFF when given a value of 1. By default, the digital output port will return a value of 0. Therefore, you want to send it a 1 in order to turn the LED off before the start of a match.

Then, in the operator control “while” loop, add the following lines of code:

    if(bVexNetActive){
      SensorValue[LED_RED] = 1;//off
    }
    else{
      SensorValue[LED_RED] = 0;//on
    }

‘bVexNetActive’ is a variable that says whether or not the robot is currently connected to the joystick through vexNet. If it is false, then this means that you have a connectivity issue.

And there you have it, your very own connectivity lighting system! Once you have set up the system like this, you can test it the next time you’re driving your robot around by powering off the joystick or unplugging the vexNet from the joystick. If the lighting system activates when you do this, then you will know that it is working properly.

The primary reason for using a lighting system such as this is that it makes it clear to everyone watching the match that there is a problem with the field. While proving to the ref that you’ve been having connection problems will not always change the outcome of your match, it will compel them to take whatever steps necessary to solve said problems, whether that entails replacing hardware or resetting the field. This will help improve everyone’s game experience in later matches :slight_smile:

Perhaps some one who is familiar with EasyC can post code for getting the lighting to work in that environment…

Eric Beckmann
Programmer for Team 3129 “The Green MacHHHHine”
DSC_0068.jpg

#2

I love the idea. My team is probably going to be implementing this.

Just question though, how can you be sure that this piece of code plus an LED diode will correctly diagnose a field issue? How does this test [of if vexnet is connected or not] distinguish field failure from intermediate functioning by the individual robot, i.e. bad usb connector (intermittent vexnet key plugin), banged up cortex, or overdrawing of current causing wireless disconnection?

Otherwise, doesn’t this have the same purpose as the existing “sad” LED patterns on the joystick, just in a more visible way? Is the purpose just to tell you that there is no connection, not to diagnose why? Is there any way to differentiate a field issue from a robot issue, other than noticing that none of the robots run?

(I’m not my team’s programmer, so I admit I have little knowledge as to how the field and code interact, just want to understand if this is a magical field diagnosis tool or just a “louder” error light.)

#3

Unfortunately it doesn’t really work like this. Connection problems are much more likely to be the result of a problem with the robot in question than with the field.
For example, slightly loose battery connections can cause a loss of power for a split second - this is enough to lose Vexnet connection (and then of course it has to reconnect…). Backup batteries definitely help (when they’re full!) but they aren’t magic. This often happens to my team if there is any kind of jolt during the match (and there have been a few other threads about how to avoid this). The same can happen with the connections to the Vexnet key itself.

Believe me, as a competitor, I know how frustrating it is when your robot cuts out and you don’t know why. But having helped run many events also, I know that field problems are extremely rare. In 180 matches at NZ nationals we only had a field problem once.

Most people don’t realise how simple the field control system is. It can’t do anything to your controller that a competition switch can’t; all it does is provide an electronic way of switching so it is timed perfectly. The connection is still handled 100% by the Vexnet system between the joystick and the cortex. The only thing that could go wrong is switching between disable/autonomous/driver at the wrong time if it, or one of the cables, was damaged. Any other problems I can think of (software problems or operator error) would cause all robots on the field to stop moving.

If you think this is happening, all I can say is, learn the joystick light combinations for disable, autonomous, driver, and reconnecting Vexnet, and look for them when it happens. Hopefully the refs know these also! If it is reconnecting Vexnet, you may be sure it is not a field problem.

#4

@chris@aura

Good points! One thing that actually is different with a field control system as opposed to a competition switch is that the field control system tells the joystick and robot’s VEXnet keys to operate on a different 802.11 WiFi channel (and frequency) I believe. I don’t remember where that is documented, but I do remember hearing about that multiple times.

#5

Chris’ post is spot on. While I appreciate the original poster’s diligence in trying to help himself and others troubleshoot problems, this one is a bit misguided. My main concern here is that if someone sees this post and loads the code onto their robot, and then has a problem in the match and see the light, they’ll think they are 100% sure that there was a field problem, when in reality there could be many other things that went wrong as mentioned by Chris and Edward. For a frustrated team that wants to believe the problem is something other than their robot, this is a dangerous thing as it will be even harder for the hard-working field crew to convince them that most likely it really is a problem with their robot and not the field.

In reality, you have everything you need to diagnose a field problem right on your joystick. The next time you have an issue, the first thing you should do is look at the “GAME” LED on the joystick. That light tells you what your joystick is being told to do by the field. The only way your robot can stop moving due to a “field issue” is if that light is blinking fast yellow, which means the field is telling your joystick to be disabled. If the GAME LED is off, then it means you’re not connected to the field, but here’s the catch: if you’re not connected to the field your robot is enabled by default. So, if you actually “lost connection” to the field during the match, your robot would still be enabled.

I strongly recommend that anyone heading to a competition should open up the VEX Cortex + Joystick User Guide and look at page 8 where all the LED combinations are shown. It’s a little confusing at first since there’s a lot of combinations, but if you study it for a bit you’ll recognize the patterns. Whenever I’m running an event I keep a few copies of this printed out at the scorer’s table for quick reference by my field crew and so I can show it to teams when something goes wrong. They always assume it’s a field problem until I show them that document and how the lights on their joystick are really indicating something else (usually a user code fault, dead battery, or a problem with their VEXnet key due to rough handling causing a loose connection).

Just like Chris, I’ve been a competitor too and I will admit there was a time when I also assumed that anytime my robot didn’t work it was “because of the field”. It’s enraging when you’re trying to compete and your robot won’t move. We all know that. However, the best thing to do in this situation really is to keep an open mind about what the problem might be and above all don’t just throw your hands in the air and give up because you assume that “it must be a field problem and there’s nothing I can do”. If you assume it’s a field problem you’re denying yourself the chance to actually fix the issue and avoid the problem in the future.

#6

So if I wrote code in the competition template to catch when the robot is disabled, and have the robot light up when it is, LEDs could serve as a larger warning beacon?
Just wondering for curiosity’s sake… I know the joystick serves the purpose already…

//Andrew

#7

I don’t think so, because as far as I know the robot can be disabled for other reasons as well. For instance, if the VEXnet link is lost, the master processor will disable the robot so that it’s not driving around uncommanded.

#8

I agree with everyone who’s replied so far. I realize that connection errors could be the result of a lot of things besides field errors. So right now, our lighting system really acts as a more visible version of the connection LEDs on the joystick and cortex. However, this saturday my team’s going to try and find out if there are ways of detecting these specific problems. If anyone knows already how to do this in robotC, help would be appreciated :wink:

#9

Building on what Chris and Dave wrote:

If you robot dies on the field, it is NOT the fault of the field controller.

If you can’t see a mechanical problem and you didn’t download a software error just before your match, it’s almost always a power problem:

dead batter(y)(ies)
bad connector
low battery power
voltage drop due to stalled motors causing circuit breaker trip
bad connections between the communications and the controller (yellow radios on PIC and the VEXnet key with Cortex)

The number of competition faults I’ve debugged over the years that are NOT one of these I can count on my fingers, and I’ve been involved in VEX for six years now. The only confirmed field problems I’ve ever had have been (possible) bad cables and one (ONE) tournament where the field controller module developed a problem during quarterfinals. The symptom of a failed field controller is that BOTH the robots on that tower stop dead and the yellow disconnect light flashes. A field control failure is not subtle and does not only affect your robot.

#10

Once again, I agree with everything people have mentioned about the various problems that could cause connection errors. However, I would like to say that one thing I forgot to mention in my original post is that the connection error lighting system works best when several teams in a match use it.

What really got our team thinking about devising a solution like this was a series of matches that we had at the Bellarmine Vex tournament back in January. During one of these matches, we noticed that in addition to our robot, there were two other robots on the field experiencing intermittent connection errors. Furthermore, all three robots seemed to be losing and regaining connection SIMULTANEOUSLY. We did not appeal to the refs immediately after that match, but continued watching subsequent matches on the same field. Time and time again, we observed the same symptoms. In each match, two or three robots would lose connection simultaneously. To us, this most definitely indicated that there was something wrong with the field. We finally mentioned this to the refs, who in turn notified those in charge of running the field. Those people made all the necessary fixes (which involved replacing some network cable) and after that no one who was on that field experienced connection difficulties of any kind.

If two or more of the teams in each match had been using a connection error lighting system, then it would have been more quickly apparent that there was a problem with the field. Now while it could still be possible that each team could have a problem with their individual robot, such as a low battery or improperly attached vexNet key, etc., the probability of all three teams losing connection simultaneously because of such problems is almost zero. The field is the only remaining culprit.

In other words, if several teams in a single match have these connection lighting systems, and only one robot’s light comes on, then that means that the connection problems that that robot is experiencing is not a field error. HOWEVER, if MULTIPLE lights come on at the same time, then that is grounds for claiming a field error.

Once again, we’re not trying to use this as a way to complain if our robot has an issue. We want to use this as a way for multiple teams to detect and analyze field faults.

#11

When you say 3 robots lost connection *simultaneously * (your emphasis), I can tell you definitively that the field did **not **cause this issue. There is absolutely no point of failure on the field that can shut down 3 robots at once but leave the 4th running. It’s simply not possible, no matter which piece potentially failed (hardware, software, cables, or anything), to shut down 3 of 4 robots at the same instant.

Sorry, but no, it’s not. It simply means that any one of a dozen issues already discussed in this thread could have occurred.

And again, my concern is that by pushing this “system” and encouraging others to use it, you are incorrectly convincing these teams that their problems are a result of a field issue. This is doing those teams a disservice by drawing their attention away from finding the true root cause of their problem.

Another point here: I find it somewhat hard to believe that a match would have 3 of 4 robots completely dead and that none of the event staff would have noticed. At every event I’ve worked at including the World Championships, anytime a robot isn’t moving the field crew steps in quickly to get a good look at the LEDs on the robot and joystick (this is why it’s in the rules that your robot LEDs need to be visible!). I have seen matches with 3 dead robots, but in every one of those cases the field crew quickly determined the reason for each robot failing and concluded that it was not a field problem but rather 3 separate issues for each team that all happened to occur in the same match (almost always battery-related), and because of that they did not stop the match or replay it.

Also, If I did see a match with 3 dead robots, I’m not going to waste precious time trying to look at your lighting system while you’re busy trying to explain it to me. I have no idea how you’re really activating that light at that moment in time and therefore I cannot trust it. For all I know you did something bad with a pointer and your code wrote a bunch of 0s out to all the memory locations and turned the LED on at the same time it crashed. I have everything I need to diagnose a potential field issue by looking at the joystick LEDs, and those are much easier to see than an LED on your robot anyway.

#12

I want to add my support to what Dave is saying here, the chance of disconnects being related to field control is remote. Having done a fair amount of study of both the cortex, EasyC, ROBOTC and the field control system (including building my own) there is really not much to go wrong when compared to the complexities of say the WiFI connection. As others have said, the most likely situation of a cable being disconnected will have the opposite effect and allow driver control rather than disabling it. Our teams use LEDs as an aid to debugging and to give confidence that the software is running correctly. I would see your approach as similar to ours in that you could use it to indicate any one of a number of error conditions.

#13

Ditto to all. One other likely cause is the VEXNet keys themselves. Our bot has struggled with connection issues for half the year. We replaced one key and it helped. But at our last match the RECF staff swapped us out with two brand new keys and we had ZERO connection issues from that point on.

Personal opinion is the physical keys are a potential weak link in the system and prone to damage in the course of normal play.

#14