Requesting details on VexOS 1.1.1

@DRow posted

Improvements for new smart field controllers (Controller, Radio and Brain)

Are there any details on the “new smart field controllers”?


The changes in vexos 1.1.1 are compatibility changes, that is, they allow the competition robot to play more nicely with the match control system we will use at worlds.
There are changes to the way we assign competition radio channels.
There are changes that allow more concise logging of match data.
Things like that.


Will the new control system solve the issue in which the radio and controller become disconnected after you unplug from field control?


it is quite annoying how this happens, in my experience it demands a power cycle of both controller and brain before it’s willing to reconnect. It’s pretty problematic because robots will often end the match somewhere you can’t reach them, and being able to drive them back over would be preferable to having to climb onto the field and pick it up.


This is by design, we want you off the radio channels as soon as possible. In fact, the new system may very well cause everything to disconnect soon after the match ends.


I am assuming this is to force all elements (including robots) to come at rest at the end of a match?

1 Like

from the wording, it sounds like the purpose is to intentionally prevent too many robots from being on the radio channels at once by forcibly breaking the connection after a match ends.

1 Like

radio channel management has conflicting requirements.
We want the minimum number of robots on the competition channels at any one time.
But we also want the robot to be able to quickly reconnect if a connection is lost during a match, balancing these two requirements means that at match end (when the existing field control is disconnected) and the controller moves from competition channel back to pit channel, the brain will not reconnect until power cycled. We optimize to give best possible results during an actual match, everything else is secondary.


I am hoping new system reduces number of “oopsie” failures when a team trips over their own alliance cable to tower and breaking hardware - rendering field unusable for remainder of eliminations.

1 Like

the removal of field control towers entirely and the ethernet cable monster that follows would really be nice, hopefully this new control system involves this.


It’s not really possible to do match control wirelessly. VEXnet is a point to point connection with the controller as the host. The controller will be connected to field control hardware via smart cable.


Would we still be able to use competition switches in future updates? If not, is there some way to emulate a robot in its disabled state with code running, w/o having to modify the code itself?

We have not removed any functionality, competition switch and VEXnet match control hardware are still compatible.


One issue with current system is fried controllers when (argh) middle school kids plug smart cable into V5 Joystick controller field controller cable (cat 5 jack that allows smart cable to be inserted… ). Do not USB-C would solve this problem across the system… power, data … Micro USB interface in V5 Brain is so fragile that many broken …

I hope moving forward, mission critical interfaces will be more robust and fool proof in terms of examples of plugging smart cables into field control jacks.


yes, I believe we may provide a plug for teams to block that port.

All the more recent products (EXP, GPS, IQ generation 2) have migrated to USB-C connector.


All charging hardware interfaces world wide should be USB-C - for example v5 joystick.

fingers crossed this will happen sooner than later.



Update to 3-wire controller to prevent unintentional firing of pneumatics on user code start

I thought all this year that it was a bug with my code or PROS itself lol. I never allocated time to debug it because it wasn’t that serious. It’s nice that it’s fixed now though. (I’m assuming this is regarding the same thing I experience, more testing will tell)


We changed the default configuration for three wire ports in vexos to be analog input, it was digital input previously. When configured as analog input we do not use a pullup resistor which we do when configured as digital input, this means when your code configures the port to be a digital output for pneumatics, the logic level on the 3-wire pin does not change. This should help with the momentary firing of the solenoid when user code first starts, however, if the user code is stopped with the digital output set to logic 1, it will be reset to logic 0 when the code is restarted, we can’t do anything about that.


Bet you didn’t think this detail would still be annoying so many years later. It’s all fundamentally caused by competition framework not running usercode for a while.

Does make me wonder if the right answer all along was a special tiny piece of user code that is allowed to run immediately at boot, more akin to competition field control with pre auto than full outer OS layer and eventually running user code.

I guess v5 mostly solves annoying port initializing stuff by making every device smart and just auto detect every smart port.


Soooo, does that mean no more ethernet and that field control will be done through one of the smart cable ports?

So much for the wireless field control rumors.