The Pitfalls of VEX Robotics' Software
Published 2025-03-30
Last Updated: Never
It’s my senior year of high school, and I’ve been taking a year-long robotics class, mostly just because I’m going into Computer Science in college and my school doesn’t offer much else in the way of CS classes. I’ll be the first to admit that mechanical engineering is absolutely not my strong suit. I’ve had a number of mechanical issues throughout my time in this class, but I’m not going to try and deflect the blame for that onto anyone but myself. However, when it comes to the programming part of building a robot, I understand what’s going on a little bit more.
Since I feel qualified (enough) to talk about the software side of things, I’m going to detail the issues I’ve encountered personally during my time in this class so far, and how I feel that VEX’s shortcomings can ultimately make things hard for students who are above the introductory level but not already firmly comfortable with programming.
First, however, a little context might be good for those who need it. VEX Robotics is a robotics program created by the Robotics Education & Competition Foundation. They organize worldwide robotics competitions where teams design, build, and program a robot to succeed at the specific challenges laid out in each year’s game. The objectives change every year, but they always take place on the same square field, where your team and a partner team compete against two other teams to score the most points possible. (I actually competed in one of these competitions, though only at a local and then state-wide level, when I was in middle school and to give them credit, it was a lot of fun.) On top of these competitions, VEX also makes a range of classroom kits and lesson plans that are designed to teach kids about engineering and programming. My school’s robotics class uses the current generation of VEX hardware (known as VEX V5, which I’ll generally just be referring to as V5) as the basis for all our robots. I’ll be the first to admit that V5 is an absolutely massive improvement over the previous VEX EDR parts, from the brain to the software, but that doesn’t mean that it isn’t still frustrating to work with.
First Stop: The IDE
During the transition from VEX EDR to V5, VEX started using their own editor for programming their robots. EDR used ROBOTC, which was created by Robomatter, Inc. and not VEX themselves. To the best of my knowledge, their new editor, VEXcode, was originally just available as a desktop app for macOS and Windows. Like too many programs these days, VEXcode is just a (probably Electron-based) web wrapper app, and with schools transitioning from having real PCs to Chromebooks en masse, that meant they had an editor they could also make available as a website. For a while, you could either use VEXcode on the web, or use the wrapped version of VEXcode as a desktop app (which looked and functioned the same), or use a third option, a more advanced editor named VEXcode Pro V5. The Pro editor was based on Monaco (the editor component of VSCode) and was therefore also web-based, but it had support for more features like having multiple source files in your project. I don’t know very much about it, since I never used it personally, but I do know that it has since been discontinued. Instead, VEX wants people who need more than VEXcode can provide to use VSCode and their extension, which I actually think is a decent solution. None of the VEX-made editors ever had support for things like source control, so just using VSCode and an extension means you don’t have to compromise on any modern IDE features to use VEX’s stuff.
We’ll get to the VSC extension later. For now, let’s talk about VEXcode.
First, I’m going to acknowledge that VEXcode is clearly designed for people who are unfamiliar with programming. That’s a feature, not a bug. They like to push their block coding, which is pretty obvious since that’s what VEXcode always opens to first. But what happens when you lean too hard into making an environment that’s beginner-friendly? You end up with a rough experience for anyone who’s ready to go beyond it.
Despite being a Python developer far more than a C++ developer, I essentially haven’t touched VEXcode’s Python mode, because I have to use C++ for my class. It’s very possible that things are a bit different in Python world, though I wouldn’t hold my breath, since most of my issues have more to do with the editor than its language support. Without further ado, here are my issues:
Cloud Compilation
As a website, VEXcode doesn’t exactly have a compiler available to it directly. This means that you’re entirely dependent on remote servers that compile your code for you, which in turn means no internet = no development. The desktop version of VEXcode is essentially worthless because of this. Why bother having the editor locally if it doesn’t offer more features and can’t compile without being online anyway? And on top of this, what happens if the servers are down? If you only use VEXcode, then there would be no way for you to get code onto your robot. Imagine being mid-competition and realizing you need to make a quick programming change only to discover that the servers are down and there’s nothing you can do. This might also just be an issue with my school’s internet, but my first compilation after opening a new VEXcode tab always fails with a “can’t connect to the server” error. Not a huge deal, but it just seems like there’s a bug somewhere if the first try always fails.
Missing Code Smarts
VEXcode has no live code monitoring. That means everything from missing a semicolon to accidentally faceplanting into your keyboard mid-function won’t trigger any visual feedback that something is wrong. Once you compile you’ll get the familiar red and yellow squiggles below your code letting you know that adsfdjfjlkjfsadfds(); isn’t a valid function name and that you assigned testVar 15 times without ever accessing its value, but not any sooner. This is especially annoying as a Python developer, because I often fall victim to the classic blunder of not remembering my semicolons when writing C++. In any other editor, I’d get a little indicator immediately letting me know that “hey you forgot your damn semicolon”, but in VEXcode I have to wait for the previously-mentioned cloud compiler servers to process my mistake first before the editor can inform me of it. On the flip side, once the editor is showing you errors or warnings in your code they will not go away until you rebuild again. Even if you delete the entire line they were on, you’ll still have a lost red or yellow highlight over nothing at the end of your previous line. I get that the complete separation of editor and compiler probably plays a part in the lack of code monitoring, but online VSC supports at least partial IntelliSense, so clearly it’s possible to watch for errors live in a browser editor. This feature being absent makes it hard for someone brand new to Python/C++ to get started, because it adds a level of clunk to the development process that could get frustrating really easily.
On a related note, VEXcode has fairly limited autocomplete. Unlike live monitoring, it isn’t completely absent, but it’s limited in what it can suggest, as it only autofills code from the VEX library. It also just doesn’t always appear, for reasons I haven’t really been able to determine.
Who needs more than one file, anyway?
I mentioned this briefly during my introduction to VEXcode, when I mentioned that the Pro editor VSCode extension had support for multiple source files. This is worth mentioning because VEXcode doesn’t. You only get a single source file. Is this a big deal? Probably not, but it feels like a strange limitation to have, because you could very easily get to a point while writing competition code where you want your driver control and autonomous functions to live in separate files. The code involved in both of those sections can get pretty long.
Hidden Lines
When you create a new VEXcode C++ file, most of the code included in the file template is hidden away in a pragma at the top of the file. By default, this isn’t a whole lot, just a function related to playing sounds from the brain and a function to seed rand() using the battery current, battery voltage, and current time. The function that does all of that is named vexcodeInit() and is automatically called at the start of main() with a big scary comment that reads Initializing Robot Configuration. DO NOT REMOVE!. I understand why you’d want people to not change this code if they don’t know what it does, but I also find it strange to hide it away. This code has comments that explain what it does decently well, and I think that it could be useful for students to see it.
My bigger issue, however, comes in when you start adding devices to your robot. VEXcode provides a graphical menu for this, which is quite handy. But once you add a device in that menu, what does it actually do? If you never notice and decide to click the tiny plus sign that expands the pragma, you’ll never find out. This is because VEXcode hides the actual code for setting up devices inside that hidden section of the file. This feels really bizarre to me- why wouldn’t you want students to see how devices are actually initialized? Hiding something so crucial to your program seems like it would hurt students’ understanding of how their code actually works, and makes it difficult to transition to VSC later because you’re suddenly on your own without ever having seen an example of what you need to do (and as we’ll get to later, the API docs will not be your friend).
Second Stop: The SDK
Like all good programmable things, VEX offers an SDK with which to program the programmable thing. And like a lot of programmable things, this SDK is entirely proprietary. Obviously, I’m a bit more bothered about open source software than your average high school student, but this time the lack of openness does actually have an effect on the average user.
And why is that? VEX’s documentation is bad. Really bad. Sometimes-entirely-incorrect bad.
The first place I ever encountered an issue with the documentation was when I was, for whatever reason, trying to write code that detected if my drivetrain was actively on the move or not. I figured the easiest way to see how to do that would be to go to the API documentation (for some reason located under the “Tools” menu bar item in VEXcode) and find the docs for the DriveTrain class. Doing that was easy enough, and I quickly found the method isSpinning(), with the description “The isSpinning() command returns if any drivetrain motor is on and rotating to a specific target.” Already I was a little confused- why should this method only be for driving to a target? Why shouldn’t it also return true if the drivetrain is just on and spinning without a destination? The questionable implementation of this method wasn’t my biggest problem, however. The biggest problem is that this method simply does not exist for instances of DriveTrain. Instead, there’s an isMoving() method, but this method isn’t listed in the API documentation at all.
I’ve only observed a handful of these cases, but it still raises some concerns. If they have blatantly incorrect methods listed, how reliable are the rest of the docs? Will they actually behave as described? Without any way to actually see the internals of the VEX SDK, there’s really no way of knowing. And as an end user, that’s incredibly frustrating. I’ve had similar experiences with the Qt for Python (PySide6) docs, because they’re full of poor explanations and incorrect examples that were auto-translated from C++ to Python. I don’t like to criticize documentation written for open source projects with few maintainers, because I understand that writing documentation isn’t the easiest and their time may be limited. But neither of my examples are volunteer projects. Both VEX and Qt’s documentation have paid employees behind them, and I feel like it’s reasonable to expect better from them. This is especially true in VEX’s case, as their target audience is students who might not have a lot of prior programming experience, so their documentation should be designed to accommodate that and be as user-friendly as possible.
Third Stop: The VSC Extension
As previously mentioned, VEX discontinued their dedicated “Pro” IDE in favor of having students use VSCode with their dedicated extension. This is really great in theory, because for better or for worse, VSC is an industry standard now and getting students familiar with it can be incredibly beneficial. It also resolves some of my previously mentioned issues with VEXcode by supporting multiple files and IntelliSense. However, it still has a number of issues. The extension doesn’t feel super polished, with frequent download errors when trying to actually get the code onto your robot, and questionable documentation (seeing a theme here?). There is also no official Linux support, so while the extension does work on Linux, VEX won’t tell you anything about the steps required to get it working. Where there is documentation, there are of course errors, like how the VEX API docs tell you that printf() (which prints to the serial console) is only supported in VEXcode and that you’ll only be able to print to the screen in VSC. This is blatantly not true, as the VSC extension opens a split terminal window with one half dedicated exclusively to the serial output of the robot.
While I do find VSC with the extension much nicer to use than VEXcode, it just still leaves something to be desired. At least on Linux, the extension takes a while to start up, and it’s not fun having to wait for it to be ready just so I can actually start on my work. It’s a major step in the right direction, but given that the issues I’ve had with it seem to have existed since its release in mid-2022, it’s a very wobbly step. Not much improvement seems to have been made, and with the last update being over 4 months old at the time of writing, it doesn’t look like they’re in any particular hurry to change that. If you’ve looked at the extension page on the VSC marketplace then you might be thinking “well the extension is open source, so if you really hate it so much why don’t you go fix it?”. First of all, check your attitude. You’re allowed to express criticism on something that you difficult to use without also having the knowledge on how to perfectly rectify that issue. Second of all, it’s not actually open source! The marketplace page links to a GitHub repository and an associated issues page, but the repository is nothing more than a README and a license and the issues are disabled. The repository description is “Source code for VEX’s Visual Studio Code extension.” but unless they’ve secreted embedded their code into the text of the MIT license, I don’t think that repository contains the source. Don’t worry though everyone, the README says that “The source code to this extension will be open sourced.” so it’s coming they swear! We just need to wait another 3 years. It’s really the cherry on top of everything else.
Closing Thoughts
I don’t want this to come off as though I absolutely hate VEX Robotics or anything. Like I said at the start, I really enjoyed my time competing in the 2018-2019 season, and would’ve loved the opportunity to do it again. I just think that there’s a lot of room for improvement across VEX’s entire software ecosystem, and that right now there are a lot of issues that make it less approachable than it needs to be for a lot of students. I can work around it, but I’ve observed how much trouble other students have had in my class getting started when VEXcode doesn’t provide them with the resources they need to get started.
I think that’s all I have to say for now, so I hope that you enjoyed finally getting another exciting blog article from me. I promise I’ll try to write more frequently now, because I have a lot of things I want to talk about. I just often lack the motivation to actually put them into words that I can publish here.
Oh, hey! You can leave comments now! If you have any thoughts or corrections or just want to tell me how awesome this article is, you can do so below using your GitHub account.