VEXcode Blocks, PID, and the future of programming in VEX

From what I’ve seen so far, the newly released VEXcode Blocks application is incredible. Vex has come a long way fast. After last year’s struggles, VEXcode is a pleasant surprise. It has a professional feel, not clunky or full of obvious bugs. It doesn’t feel incomplete either, it has built-in tutorials, an extensive help system with meaningful information for each block, and many sample projects. The Vex IQ and V5 versions are almost identical, which will make programming the easiest part of migrating from IQ to EDR.

There is also a feature that allows you to create a drivetrain with a built-in gyro. I haven’t tested it on a real robot yet, but I’m going to assume that it will work much better than encoder based turning functions like those built into Modkit. If it works as it should, then I wonder if there is any reason left for teaching PID. With Cortex, the main reason students wanted to learn PID was to get their lift to go to and stay at a specific location. (V5 smart motors alleviated the need for that.) Once they learned PID for their lifts, then they could apply the same algorithm to get the robot to drive straight, with the help of a gyro. Now if that is taken care of by this new gyro-drivetrain feature, is there any compelling reason for them to learn PID?

In a broader sense, I’m wondering how this will impact text-based programming for Vex in general. Learning a text-based language is a lot of work and takes time. Whereas using the blocks will be like instant gratification. This will be a game-changer. Programming should no longer be an obstacle for any team.


Honestly the introduction of V5 motors doesn’t affect the usefulness of PID loops or other methods of precise movements very much. You would still want a PID loop for smooth movements of the robot, the lift, and many other crucial weighted mechanisms.

As far as block coding goes, it is honestly much better to get kids into text based programming pretty early. Often times block code languages end up restricting the ability of programming a robot as not every function possible is added as a block and if it was it would most likely ruin the simplicity of it. In addition to this it is much better to teach kids text based programming as this is what they will have to use in the real world.


The ‘exclusive’ choice of either VEXCode v5 Text and VEXCode v5 Blocks isn’t neccessary, you can load both types of programs on the same brain onto different slots.

@jrp62 is correct, Blocks is extremely accessible to all students. This allows all kids the opportunity to learn how to program, which should be our goal to introduce them all to programming. They’ll be able to write a good program with blocks, it’s really well done.

For the the students that have advanced in programming skills, the choice allows them to try programming in Text and try out advanced ideas onto a different brain slot.

This new normal challenges the claim of ‘we only have one programmer’, which I really like. Any kid on the team will have the opportunity to grow in programming.


I can more details later, but I would say that I wrote the gyro turn to be good enough but not great, it can be improved upon quite a bit by using a real PID loop.


Depends on your definition of “kids” - I have to consider a whole range of future coders from K-12… For K-2 we are looking at coding robots without computers… Literally with “blocks” :slight_smile:
For 3-5 VEXcode IQ is great and moving forward 6-12 VEXcode V5 Block or Text depending on readiness … and many other solutions for those wanting to go their own routes.

So, no single solution, but VEXcode for us in education handles a whole spectrum of readiness and two hardware platforms, IQ and EDR…


and that is nice thing about VEX platform (software and hardware) you are given references that are “good enough” to get started, but you can greatly improve - and that improvement you bring is called engineering :slight_smile:


I don’t think that’s the right mindset to look at it from. Ignoring the fact that robot performance can be greatly improved with programming concepts such as PID, that’s not even the main point of participating in programs such as VEX. After all, if students are able to get into STEM programs in university without relevant extracurriculars, one could argue “is there any compelling reason for them to participate in VEX?” Of course, the answer is that yes, there is, because it’s fun, and the skills learned may be useful to them in the future. Necessity shouldn’t be a requirement. Besides, robotics programming is a great way to introduce precalculus and calculus concepts to students, as they are able to see clear applications of what they are learning.

I haven’t tried out VEXCode v5 Blocks myself (hopefully I’ll have time to this week), but one advantage that I do hope to see from it is an easier path for students to pick up text-based programming, as it will be built into the same environment, using (hopefully) similar libraries etc.


Honestly, every generation of VEX products and software adds a bit more abstraction between the user and the hardware.

With Cortex, until IMEs came along, teams had to hook up a separate encoder to their motor and program their own PID system just to get the motor to move a certain number of degrees. With v5, it’s just one function call.

With PROS for Cortex, teams like 5225A had to code their own tracking routines to make super-accurate autonomous programs. Now, the algorithms are already written and ready to go in PROS for v5 (via OkapiLib). Path planning and following, high-precision odometry, and (coming soon) pure pursuit closed-loop path following are all plug-and-play for teams like Invictus to use for their Worlds-winning skills routines.

And so it is with VEXcode Blocks and the gyro turn function. We’re moving away from having to micromanage every last detail of code. Teams can now iterate upon complex designs much faster - but they aren’t going to have as good of an understanding as to how exactly the code they’re using works. Maybe this is a good thing, maybe it’s a bad thing? It’s as much a philosophical question as it is an education one.


Possibly being pedantic, but we used RobotC for Cortex; the team didn’t switch to PROS until they switched to V5.

While I welcome this, from my experience getting tracking/odometry working on our 2018 bot I would say that these solutions only go so far. A generalized ready-made solution, like the integrated PID in V5 motors, or equally a path following algorithm in OkapiLib, may work for all robots, but a different algorithm built from scratch for a given team’s use case will generally perform better. This can be as simple as changing the PID coefficients on the velocity controller (which I am aware V5 lets you do), or as complex as creating a custom multi-variable feedback loop algorithm for a certain type of maneuver that you do once or twice in programming skills (which we did in 2018). At least with OkapiLib being open source, teams are able to understand and modify the algorithms as they see fit, but this doesn’t apply to every abstraction that you mentioned.

I agree, and I’m not sure how I feel about it either. To be honest, while it may have been a pain to go through many iterations of algorithms that didn’t work, I wouldn’t trade that for a ready-made solution. Everyone who was involved in the effort to develop tracking and motion algorithms at 5225A learned an immense amount about programming, math, and applications of physics just by needing to sit down, figure out why one algorithm behaved the way it did, and convince ourselves that a different one might work better.

This isn’t just a question for teams to consider—as you point out, it’s also a question for the philosophy of the competition. I touched on that a bit in my response to the Student-Centered Policy Document; it’s not clear what place open source libraries should have in VEX. At a high level, it depends on what the goal of any given team is. If it is purely to win, then of course ready-made solutions will help, but I don’t think that should be the goal.