Field control - a technical analysis

VEX V5 General Discussion Technical Discussion
1

Field Controller - description
(Please do not quote these posts as they contain embedded images, thanks)

The following post contains technical details about how the VEX field control system works and specifically the VEXnet Field controller kit. I’m posting this as an aid to teams and event organizers who may not have experience debugging field control problems and to try and dispel certain “myths” that surround its use.

So you walk up to the field with your robot, you plug the RJ45 cable into the competition port on the joystick and hope everything works when the match starts. Lets look at the overall system that you, your alliance partner and the opposing teams have just created.

The four robots (teams) are shown as the two red and two blue blocks above, each of you have plugged into a “Driver Interface” which is also sometimes called the “alliance splitter”. This small black box looks like this.

It has connections for you and your alliance partner, four further connections for the old (now mostly unused) 75MHz controllers and single connection to the “Match controller”.

There are also three led indicators.

Disable - This slowly flashes orange when the field is disabled.
Driver - This will be solid green when in the driver controlled part of a match.
Auto - This will quickly flash green when in the autonomous part of a match.

There are two driver interfaces, one for the red alliance and one for the blue. Each driver interface is connected to the “Match Controller”, another small black box that looks like this.

The Match controller has two bi-color leds, one for each driver interface connection.

If the led is green then the driver interface is correctly connected, if the led is red then it is not.

The match controller has a USB connection to a PC that is running the tournament manager software. Tournament manager is controlling all aspects of the match, the Match controller and driver interface have no intelligence but we will get into that a little later. First lets look at the hardware in detail.

Hardware Description

**Match Controller
**
The heart of the match controller is a Silicon Labs CP2103 USB-UART bridge. This device would normally be used in a USB serial adapter, something like the old orange programming kit (although that used a different device from prolific), however, in this application it’s really being used as a sort of USB to digital IO device. The CP2103 has six output signals that are under control of the tournament manager software, two of these are traditional serial handshake lines called DTR (data terminal ready) and RTS (ready to send). The other four are specific to the CP2103 and are called GPIO signals (which stands for general purpose input/output). The six control signals are sent through a 74ACT04 hex inverter which acts to both invert and also buffer the signals. They are then split into two groups of three, each group going to one of the two driver interfaces. Here is a conceptual schematic showing this.

The three signals going to the driver interface are as follows.

Enable/disable - When this signal is low the robot is disabled, when high it is enabled.
Driver/Auton - When this signal is low the robot should run the autonomous code, when high it should run driver control code.
LED Power - This signal is used to power the leds in the driver interface, when high the leds can illuminate, when low all leds will be off.

The match controller uses a bi-color led to display the “connected” status of each driver interface. This is achieved by using a simple mechanism where the driver interface shorts pin 8 of the cable to ground, when detected by the match controller this changes the color of the led. This signal is also made available on the CP2103 on the CTS (clear to send) input for driver interface 1 and DSR (data set ready) for driver interface 2. In theory these two signals can be read by the tournament manager software but I don’t think it’s currently used.

The power for the match controller is taken from the USB 5 volt input, this is converted to 3.3V inside the CP2103 device but also used to power some other components directly.

**Driver Interface
**
The driver interface is far simpler than the match controller. It accepts the three control signals generated in the match controller, the two match control signals (enable/disable, driver/auton) are directly fed to the VEXnet connectors, there is no additional buffering. Logic is used to also monitor these signals and control which led illuminates. Here is a schematic of the driver interface.

The driver interface has one additional function, when you are connected to it, certain wires in the cable are shorted to ground (0 volts). One of these lines tells the joystick that you are in “competition” mode, that is, the joystick should check the two match control signals discussed above. These signals are important, if the cable to your joystick does not make a good connection then you may not be in “competition” and “match” modes, see post #3 for details on how to check the leds on your joystick to verify you connection is good.

A bad cable or a dirty connector on your joystick can make any of the control signals become intermittent, it’s important to respect these parts, treat them gently, don’t step on the end of the cable or place anything except the correct cable in the competition port.

Part 2 will cover software control (5 image limit, I need more)

11 Likes
2

Software Description
(Please do not quote these posts as they contain embedded images, thanks)

The control signals to the robot (or rather the joystick) are very simple. One signal either enables or disables the robot, the other selects driver control or autonomous operation. The match controller has separate signal buffers for the two alliances but it’s important to note that both blue robots receive exactly the same control signal as there is no additional buffering in the driver interface. The same is true for the red alliance, both teams receive exactly the same control signal. The tournament manager software controls when these signals are switched, to verify operation independently from the tournament manager software I created a small application to communicate with the match controller and allow them to be switched individually. In addition to this, it provides test modes for driver control and autonomous in a similar way that tournament manager does. Here is a screen grab of the Mac version (PC version is similar).

As can be seen from this screen shot, GPIO0, GPIO1 and GPIO2 are used for driver interface 1, GPIO3, DTR and RTS are used for driver control interface 2.

When the tournament manager software is controlling these signals it ensures that the driver/autonomous selection is always made before the robot is enabled rather then trying to switch them exactly at the same time. This ensures that a robot is not briefly put into the wrong mode when a match starts or restarts.

One unusual aspect I found is that tournament manager constantly toggles the driver/auton control signal when the robots are disabled before and after a match. I have no idea why it does this, it may just be a bug or the joystick possibly detects this and takes some type of unknown action, who knows (well only VEX and DWAB I guess).

Here is a composite scope capture showing how the control signals for one driver interface are switched for a single match, it illustrates the timing of the enable/disable and driver/auton signals.

In addition to controlling these two signals, tournament manager also controls the LED power signal to flash the leds on the driver interface. This function is completely independent from robot control, however, if the driver interface leds are working correctly then it’s a very good indication that field control is working. Part 3 of this post will cover what to look for if you think field control did not work for you.

Here is a scope grab showing how tournament manager controls the LED power signal when robots are disabled, the “flash” rate is 1 Hz. These were captured before the inverting buffers and are therefore show inverted as compared to the actual signals.

There are a few important things to understand about the field controller software.

  1. Control is one way using two simple signals, there is no feedback from the joystick or robot to field control.

  2. The field control is holding you robot in disable until released, that is, if for some reason field control was not working, a disconnected cable or something like that, then your robot will be enabled.

  3. Field control does not use any form of “special” commands to your robot, it can not erase your program, it does not directly tell your robot what to do, it only “releases” your robot when the match starts.

  4. If your alliance partner was released by field control and you did not move, then it’s not a field control problem. The signals that you are receiving are exactly the same as your alliance partner, in fact, you are directly connected to your alliance partner joystick through the driver interface.

  5. If both you and your alliance partner have problems when the match starts, it may be a field control problem, see the next section and check the leds on your joystick and the driver interface, they are there to help you.

7 Likes
3

Debug
(Please do not quote these posts as they contain embedded images, thanks)

There are some things that you can do to ensure that you are connected to field control and that it is working correctly.

  1. Check the game led on your joystick before the match, when you robot is disabled this led will flash yellow, it will show that you are in competition mode and that you are connected through the driver interface to the match controller. This led will also flash yellow on the cortex but (unfortunately) can be harder to see.

If the driver interface has been disconnected the led will not flash and will be solid green.

Before the match the leds should be like this (single joystick, slightly different if a partner joystick is used as well).

Also try and check the driver interface, the disabled led should be flashing orange, this shows the tournament software is running correctly.

  1. When autonomous starts, if you did not move and suspect field control, then check the joystick leds again, if the game led is flashing yellow then call a field tech, something is wrong. If the game led is flashing green then you have been enabled and are in autonomous mode, field control has worked correctly and the problem is yours. This is how the leds should be during autonomous if field control has enabled your robot.

If you did not move and are still in doubt, then also try and check the driver interface box, the autonomous led should be flashing green.

  1. When driver control starts, if you did not move and suspect field control, then check the joystick leds again, if the game led is flashing yellow then call a field tech, something is wrong. If the game led is solid green then you have been enabled and are in driver control mode, field control has worked correctly and the problem is yours. This is how the leds should be during driver control if field control has enabled your robot.

If you did not move and are still in doubt, then also try and check the driver interface box, the driver led should be solid green.

The VEXnet and robot leds will show other problems, things such as a bad wifi connection or low battery power. These are not field control issues and cannot be caused by problems with the field control system.

7 Likes
4

I have noticed that on some controllers the robot light will flash green when connected to field control, but on other controllers it will flash red. I have had both and both seem to work fine, but I was just curious as to what the difference is.

5

The robot light will flash red when connected to the field (or a competition switch) if there is no 9v backup battery connected (or if the backup battery is running low on charge – 0v-8v).

6

That’s correct.

I’m showing the “ideal” condition on the animations.

Robot led may quickly flash red indicating no backup battery. With V4.01 this only happens when the robot is disabled, as soon as the robot is enabled it will show main battery status, I understand the motivation to do this but it may be even more confusing as it will be red, then green during auton, then red, then green again, not sure if it will really help, we will see.

The robot led also be yellow or red with the slow flash, meaning low main battery, this will latch. Adding a partner joystick will change some of the flashed as well, see the joystick user guide.

The game led is the important one to monitor with respect to field control.

3 Likes
7

As always, very thoroughly done. Thank you for these analyses.

I have a question though:

What effect does field control have on VEXNet? More specifically, is there an overhead or is there a one time transmit?

I’ve occasionally observed robots that have issues only on field. These aren’t disconnect issues, at least not perceptibly. That is, there is LED indicator showing broken link on either robot or joystick. I’m aware of the “you’re driving it rough” argument, but I’ve been able to rule that out -driving your robot rough (even more than you would in match) still won’t cause issues. Can I completely rule out the the switch?

Thanks

2 Likes
8

You are welcome.

Field control has absolutely no effect on VEXnet beyond causing it to switch to “match” mode, this happens when the cable is first connected to the joystick.

The joystick is constantly transmitting packets of data to the robot, the robot is replying with status. Some bits in these packets indicate the competition state, this is a fixed overhead, the messages are not large. There are no special messages when the competition state changes (I should add, this my assumption based on what happens when tethered, the wifi is probably based on UDP, there will be dropped packets so any system that relied on a single packet with a special command would never work reliably).

I have found no evidence that field control is any different from a competition switch in terms of the pure control aspect.

4 Likes
9

Fascinating stuff. Thanks for posting this. :slight_smile:

10

First of all, thanks for the great detailed analysis, one that hopefully clears up a lot about when the field is/is not at fault for teams. :slight_smile:

I have one question which has always piqued my interest and am wondering if anything you found out answers it.

If a team (mistakenly) plugs in both the RJ-45 into the competition port and the RJ-11 into the joystick (programming port presumably) then the Driver Interface will show a solid orange LED for Disabled (no flashing) and will keep the drivers of that alliance in a Disabled state whilst the other alliance is fine.

I originally thought this was just due to a plain short on one of the pins used in the Driver Interface, however from the data you’ve given it seems this lack of flashing must be coming from the host PC itself? Which then must mean there is at least some form of communication back to TM itself?

Anyway, wondering if you’d noticed this, or tested it, or know what causes it?

2 Likes
11

I’m not 100% sure what you are asking, however, if you mean plugging a cable from the 75MHz port (which is an RJ11 4 pin connector) into the only acceptable port on the joystick, the partner joystick port, then the following happens.

Pinout of the partner port on the joystick is as follows.

Pin1 GND
Pin2 Tx Data from the joystick
Pin3 Rx Data to the joystick
Pin4 GND

Notice that pin1 is 0 volts, now on the 75MHz connector pin 1 is used as the enable signal, so by connecting both you have permanently connected the enable/disable signal to ground thus disabling both alliance robots. The orange disabled led should still flash when match control thinks it really is disabled but as soon as driver control starts the disabled led will stay constant orange due to the joystick essentially disabling itself. During auton mode the orange led would flash quickly (this is all in theory, I didn’t try it).

If a student managed to plug the RJ11 into the programming port (which is 6 pin and larger) then potentially 5V could be fed into the driver interface, not a good thing, results would be different however.

There is no further communication back to TM that I can find, the schematics in Post #1 are accurate, however, I will try this when I get a chance if I can convince myself that no damage will happen.

3 Likes
12

Ah yes, of course. I guess usually by the time an alliance is complaining their robots aren’t going it’s already into driver control hence the constant light. I just mustn’t have been thinking it through properly :stuck_out_tongue:
Thanks for that.

13

If anyone ever sees this condition on a field and it isn’t because someone plugged in the 75MHz cable somewhere that it doesn’t belong, another thing to check is to look inside each RJ45 port on each joystick (and driver interface if needed) and verify that there are no bent pins inside any of them. In the past I’ve seen a few failures where a pin inside the competition connector for a few teams’ joystick had jumped out of its slot and gotten bent into the slot of the pin next to it (hard to describe, but you’ll know it if you see it). This caused the same shorting effect and basically the same behavior described here.

I can confirm that there are no communications from the joystick back to TM. TM has no way to detect the condition mentioned above.

One more caution: as shown in the schematics here, the driver interface red/green LEDs on the match interface tell you if you have a driver interface plugged in. However, they do not necessarily mean that the entire driver interface is working correctly. The green LED really only tells you that 2 of the 8 wires inside the CAT5 cable are working. I’ve seen cases where that driver interface LED on the match interface was green yet there was still a problem because one of the other 6 wires inside the CAT5 cable between the match and driver interface was damaged.

James, thanks for the detailed explanation. Hopefully this helps at least a few teams understand that when the event staff tells you the field isn’t causing your robot to be disabled (when your partner is still active), they aren’t just trying to tell you something to get you to go away. However, having been passionately involved in a robotics team for many years, I do understand why teams would prefer to believe something outside of their control is responsible for a loss.

4 Likes
14

Wow!, beautiful explanation, thats, we had the issue, when our alliance team did not show up, and our robot did not move in both autonomous of driver control, and we had a spare 9V battery connected at all times, which we still are using. We thought it was the field control, but did not know how to rule that out.

I had asked this question in other Q&A and they pointed me here. Nice one…

15

James, could you go into more technical details in this thread then?

Here is a quote from one of your posts:

#5 says that if both robots are affected than it may be a field control problem.

However, I have very hard time understanding what would be the mechanism of of both alliance partners being disconnected and reset mid match and somehow it is their fault and not the fault of the field hardware.

All field control components, including the cables are EP/field technicians domain, all internal Joystick components are non-modified VEX electronics.

If I understand correctly the only things that might be teams’ fault are:

  1. Plugging cables incorrectly - then how come everything worked since the beginning of the game?
  2. Having low joystick battery or intermittent battery connection - then why both robots undergo reset?
  3. Having bad (shorting?) partner joystick cable - again how could this affect the other robot?
  4. Shaking controller too much causing RJ45 to:
    a) disconnect - then why both robots are affected?
    b) short - then it is problem with the cable that is part of the field setup.

I am very puzzled.

4 Likes
16

Hi @jpearman ,

I would also like some more detail regarding this.

Do you know if there is static protection of any kind on the competition control line inside the joystick? We are concerned about this but cannot find a schematic.

I’ve just noticed that the full alliance disconnect at US open happened as both robots were touching the field perimeter, and the full alliance disconnect in world finals 2017 happened exactly as a robot touched the fence. These could easily be coincidences however.

Has there been any testing done relating to this to your knowledge?

Thanks for all the work you do for the vex community.

Cheers,
Lucas

3 Likes
17

I originally sent @jpearman this post as a PM, but as it seems we are reviving this thread it would probably be best to have this discussion here. Begin post:

I read your thread; while I already had a general understanding of what goes on to switch between autonomous and driver and enabled and disabled, it was a very informative read as to the specific electronics inside the field control system.

However I didn’t find any explanation of the circumstances of the simultaneous disconnections that I have been consistently observing throughout my years in vex. All of the explanations in that thread dealt with either being in a wrong state of the match or being disconnected from the field control system. Neither of these is what I have been observing.

One thing does draw my attention though; under the driver interface section of your first post, you state:

and at the top of your second post:

Is it correct to stay that, given the presence of buffers in the match controller and the lack of them in the driver interfaces, a static shock introduced into the system somewhere between the match controller and a team on the red alliance’s joystick would theoretically be able to reach both of the red alliance’s joysticks, but yet would be unable to reach the blue alliance’s joysticks?

Is it possible for such a static shock to affect the operation of the joystick, specifically in a way that would cause it to drop a vexnet connection?

I have a video that capture the lights on the joystick (albeit grainily) during one of these disconnects that I will add to this post. EDIT: https://vexforum.com/index.php/conversation/post/265449

3 Likes
18

I don’t have this information.

So it’s really hard to post analyze what may have happened during these disconnects, especially when I was not present at the field to see first hand what happened. I’m not sure if we know if it was a simultaneous VEXnet disconnect or both teams somehow being placed in the disabled state. The latter would have shown on the leds on both driver interface and team controllers, but I don’t have that information.

All I’m really saying is that it’s unlikely the tournament manager software had disabled the robots. It’s unlikely that a cable became disconnected as that places the robots into an enabled state. If a short occurs in the competition connector on one alliance member it can disable both teams, there’s a direct connection between the signals for both teams (on the same alliance) so if there is a short in one it will disable both. Static is a potential cause, but I have no evidence one way or the other to support that, and I wouldn’t blame field control for that issue. My point is that there are other, in my opinion, possible causes without making the blanket statement that it’s the fault of field control.

3 Likes
19

I cannot speak for the habits of other teams, but the three teams I mentor are not exactly gentle on the hardware. The controllers get dropped, they poke things in the connectors, forget to unplug and just walk away from the field causing the cable to be pulled out, partner joysticks get plugged into programming connectors etc. etc. My point is, be respectful of the hardware, abuse it and it may let you down at unfortunate times.

3 Likes
20

@jpearman is there a way around the random (but not really random) alliance disconnection problem? I don’t want that to happen to me at worlds again. I attached a link to a worlds match in which my alliance partner and I were unable to move for a good 10 seconds. I don’t think the driver interface lights were set to disable if I recall correctly.

1m57s