Yes. I’ve seen the ‘stuck in autonomous’ happen because of a crossed pin in a joystick too in addition to ‘stuck in disabled’.
If you look at the pinout for the competition port (documented in the schematics at the top of the thread), you’ll see the first 4 pins are this:
Ground
Driver/Auto#
Enable/Disable#
Ground
If pins 1 and 2 are shorted, you will be stuck in auto mode. If pins 3 and 4 are shorted, you’ll be stuck in the disabled state. This happens because the field controller is providing a +5V signal on the driver or enable pin, but this signal is fed through a resistor on the field control board. When the pin is shorted, then the joystick Driver input (or Enable input) has a direct connection to ground (0 ohm) and also a connection to +5V (through a 100 ohm resistor). The path of lower resistance wins, so the joystick reads the signal as 0 volts, which indicates Auto or Disable depending on which pin is shorted. For some reason, the 3/4 short has appeared more often in my experience - I suspect this might be the result of people plugging in the wrong RJ connector (from the partner cable or programming cable) into the competition port. Since those connectors are narrower, the plastic on the outer edge might compress the pins in the competition port further until they reach the end of the little slot that holds them in place which then allows them to jump to the neighboring slot.
Shorted pins in the joystick is usually somewhat easy to diagnose because of a side effect of the driver interface design. As detailed before, each driver interface has a single connection that provides power to the LEDs on the board. When we implemented VEXnet support in Tournament Manager, we decided to turn that power on and off to create an effect of blinking on the driver interface LEDs similar to the Game LED on the joystick (I think the game LED used to blink yellow slowly for disabled on the joystick, now I believe it blinks rapidly instead). Since the joystick can’t short out the LED power, the on/off status of the LEDs will still match whatever state Tournament Manager is commanding for the field. Thus, if the match is supposed to be in driver mode and you see the auto light on, but it remains on steadily, that’s because TM is sending the driver state and not toggling the LEDs (because the joystick game LED remains solid on during driver mode). This same thing can happen if the disabled pin is shorted - the yellow disabled LED will be on, but during autonomous, TM will be toggling the LED power rapidly, causing the yellow disabled LED to flash in a way that it otherwise doesn’t (a rapidly flashing yellow disabled LED on the driver station interface is a dead giveaway of a short and the easiest one to spot).
Okay after reviewing the disconnect footage again, I noticed something interesting. In every video where the vexnet key is visible, its light is solid blue for some length of time during the disconnect. This appeared odd to me since that doesn’t happen during normal operation.
Will update this post with results of testing scenarios to generate a solid light.
Update:
-Ok, simulating a disconnect robot side (by power-cycling the cortex) did not yield the solid blue light.
-Simulating a disconnect joystick side (by power-cycling the joystick) did yield the solid blue light.
I will attempt to procure a solid blue light by using only the field control and will update this post with results.
Update two:
-Starting a joystick and cortex not connected to field control and then connecting them to field control (specifically when pin 6 is connected to signal the change to competition channels) did yield the solid blue light.
-However, disconnecting pin 6 or disconnecting from the field control all-together does not yield the solid blue light. This leads me to believe that this is not what is happening for the videos.
I also tried shorting different pins together, this however yielded no unexpected response from the joystick of any kind.
Therefore, based on the evidence above, I believe it is one of two causes:
A field control-caused joystick crash/reboot, whether that be through static or another cause.
Some other factor that would cause the vexnet key to immediately seek out a new channel.
#2 brings in the possibility of wireless interference, however considering how astronomically unlikely it is for a source of interference to simultaneously disconnect two vexnet links, I believe the first explanation is the most likely at this point.
I would also like to point out that the main processor in the joystick, the NXP LPC2458FET180, is the same processor that is used as the system processor in the Cortex. The cortex’s processor, as we all know, does not handle static well.
While I can’t specifically speak to the reliability of VEXnet keys, since I’ve only experienced one true drop-out, in an area with an extremely crowded & active 2.4 band, I can speak to the reliability of devices on the 2.4GHz band in a completely different field, where we experience extremely odd disconnects without having a real diagnosed cause.
Let’s take one of the most reliable Wireless DMX Rx/Tx systems on the market, the City Theatrical SHoW Baby 6 as an example. At this point I’ve worked with about 30 or 40 of these devices in a wide variety of configurations, and what I’ve found to be the case is that their performance in an empty theatre or arena is far superior to that of a filled venue (but by no means does a filled venue cripple this system), I would assume the same to be the case with VEXnet 2.0. These devices utilize frequency hopping, as I’d assume the VEXnet system would do, and for the most part, these units don’t have real connection dropouts, but every once in a blue moon, I experience drop-outs that are almost always solved by terminating the DMX run (which is achieved by running a 120 Ohm resistor across our data pins at the end of the chain), and in-turn reduces the overall system noise. It’s generally accepted that DMX termination isn’t necessary, but a luxury, but is also the first point of failure I look to when solving an issue with a lighting system.
To the point of no other system like VEXnet existing, I suggest you look into some of the wireless DMX systems, they’re definitely not for robotics, but are some of the most robust 2.4 GHz products I’ve ever encountered. The same company as I’ve linked above, City Theatrical, has released a product that can handle 8 concurrent, wireless DMX universe streams at the same time, which is an insane amount of data. (Multiverse)
I have no knowledge of the internals of the competition controllers and how they may terminate data, but is there a chance that there is some form of internal termination issue somewhere in the chain (Comp Controller => VEX Controller => VEXnet => Cortex)?
Hi,
This thread was loads of help working on my new project. its not finalized yet any I would appreciate feedback from more experienced users. Especially on the emergency stop and display code…
A bit of info,
My project is making a field control system that is operated with buttons rather than the TM software. Check it out on git-hub at Jchisholm204/RasPi-Vex-Field-Controller
@Jchisholm204 Interesting project. Some of us had kicked around ways to so a stand alone field in 2014-15. I ended up using an Adunio with 8 segment LED displays to do a count down. The interface was dirt simple. Press one button for Auto and it would count down 20 seconds. It would turn the team interface to Auto, count to zero and stop. Press the next button and it would do the same for Driver mode. Third button set the robots to disable and zeroed out the display.
You might want to reach out to the people that write the Tournament Manager Software (like @Dave_Flowerday)
Presently TM runs a remote display, you can plug the match controllers into the USB port and then the driver interface plugs into the match controller. I don’t know if there is a way for the Pi to do any local GPIO to TM.
We held a Tournament on Feb. 1, 2020. During the event we had major problems with the Field Control system. During a match, at random times, one alliance would go dead. The control unit for the two alliance cables went dark, no LED’s lit. We replaced all the control hardware 2 times and the problem continued to occur. The only way to recover was to shut down TM and reload the TM program recovering the saved matches. The failures occurred on one tower consistently during Qualification matches. Then it occurred on the other one during a finals match. We could not identify any common team, controller, or such. Any suggestions to prevent it from happening next year would be great! All robots were V5 hardware. The TM server was running on a Windows laptop with only one USB port connected, to the control system.
Are you talking about the Match Controller - the part that connects via USB to the computer?
If so, those LEDs are always lit as long as the board has power (software has no control of them at all). They’re wired in such a way that they are always either red or green - they cannot be “off” when the board is on. If those LEDs were off entirely, the only way that can happen (as far as I know) is if the computer turned off power to the USB port. And, I’ve only ever seen that happen due to a short circuit or similar condition causing excessive current to be drawn from the USB port. Basically, there had to have been a hardware issue - either a bad match controller as suggested above, or some other fault (bad cable, etc.), or possibly a static discharge event (if the environment was dry, there have been cases where teams picking up the field control cable cause a static discharge into the cable which then travels back to the match controller and can cause it to lock up, though I believe even in those cases the LEDs on the match controller stayed lit).
Did you run the Computer Configuration tool that gets installed with TM? You need to be admin to run it as it changes various Windows settings. I’ve seen what you describe so many times and I believe it’s related to Windows power saving settings.
Since this thread has been revived, I figured I might as well bring attention to this post again. Would VEX mind sharing what the results of this testing was? Were disconnects able to be caused with an ESD? Since Paul is no longer with VEX, I’m not sure who to tag here… so @Grant_Cox?
No. The Match Controller with two lights showed green at all times. I replaced it and all the cables after the first failure. The fault showed up in the alliance controller that has two cables to connect to the driver joy stick units. When it is operational, it shows that is is in Autonomous mode, Driver mode, or blocking with 3 LED’s. Therefore 1 LED is lit at all times. Those 3 LED’s went out when the failure occurred. The alliance tower went dark and of course both teams remotes stopped transmitting. The problem only appeared during driver control period. It happened several times on the north side of the field and finally one time on the south side. Simply exiting TM and restarting TM restored normal operation and each time it ran long enough to complete the match.
I am still going to say it sounds like either bad controller or bad USB either it be cable, computer, or something like BIOS power throttling a USB port. Does not sound like the match controller was faulty.
Yeah some laptops or pre-built desktops have had issues (very rare on newer) situations with BIOS or something on the Motherboard shutting down usb ports that require power. Powered USB hubs were mandatory for awhile in our trailer but newer devices from companies like Dell and Lenovo kind of made them obsolete as we never had that issue again.
That will only configure OS settings. I know for a fact that all Macbooks have power shutoff limits on USB ports, I know tons of cheaper brands I have experienced the same thing. That utility does not effect bios or custom software from vendors which could cause the same symptoms.
Can you provide details on the laptop you plugged the controller into? How old/new is it? Was it used to control only a single controller or multiple?
I had a similar issue with equipment I had borrowed. Everything was already setup with an older laptop that was connected to three match controllers. We had an issue with one of the three controllers. After I looked closer, that field controller was plugged into an eSata port. It works like a USB port, almost. It worked for most of the tournament but then the controller would flake out just as you described. Running the configuration utility would reset it and everything would work again, until the next crash. I verified with REC that this was the likely cause of the match controller issues because it has a very limited voltage range that it was designed for, something the eSata port doesn’t comply with.
On another note, I always have TM running on its own dedicated laptop, with nothing else connected to it. That way, if something goes wrong with a field, only that specific laptop needs to be rebooted and none of the other connected devices are affected.