I think some common sense can be applied (and i’m sure there will be responses with many more grey areas)
The PROS team is a VEX partner developer, it does not really contain any higher level functions like a drivetrain, they have all been (as far as I’m aware) contained in additional libraries such as Okapi.
PROS also allows some additional complex libraries such as lvgl (as does VEXcode, but no one really uses that). lvgl has a not insignificant learning curve, if the student understands how the library is used and wrote the code using it, in my opinion that would be ok, a robot is not scoring any points by using lvgl.
Now the more complex question is about the lemlib type library. Unlike lvgl, these libraries are designed to move the robot and score points, I think that’s the differentiating factor.
I will openly state that I agree with the spirit of the RECF/Vex stance that students should understand their stuff, I disagree with where lines are drawn.
A team uses the (closed-source) Vex supplied DriveTrain class to move their robot. A different team uses InsertOpenSourceTemplateHere DriveTrain class to move their robot.
One is legal, because Vex supplied it, but it’s closed-source nature prevents the students from learning how it works. The other is, in certain/many cases, illegal but offers the students a way to learn how it works. I suppose, and probably rightly, RECF would say in the second case, as long as the students actually put in the work (and document) of learning how the open source on works, it too, is legal, though there may still be questions of whether it represents their skill level.
I agree and the code is totally learnable, it just requires a team to take the time to learn the algorithm, which I do not think is an unfair ask. All it does it respects the time and effort of those who choose to write their own code. And if it takes a team extra time to learn a piece of code, then perhaps they aren’t ready to implement it, maybe by worlds they will be able too. It isn’t like you need crazy algorithms to get a good auto.
Going off of the docs for most libraries/how they are marketed. The intention of libraries is to “level the playing field” however, I think the best way to do that is not to provide the code, but to provide a white paper instead, where you can have pseudocode, and actually teach people about the logic. For example, the difference between George Gillard PID and just using the LemLib PID class; one teaches you how it works, the other provides limited explanation of the inner works (outside of "go to declaration in VSCode).
perhaps I will prepare some pseudo code and explain how the only relevant functions work, source code would not be as helpful as it needs to deal with some platform specific stuff, old gyro sensors with reversed output etc. that just tends to obscure what it actually does.
I guess I consider the code trivial, it really doesn’t come close to the complexity implemented in other libraries. The non inertial sensor version is just calculating wheel rotation based on the known parameters and then using spin_for motor commands. The version using the inertial sensor (or gyro) implements a P loop and stops when close to the target.
I will say that I believe there is value in both. Taking a concept and making it functional code is a skill. That said, seeing LemLib’s implementation - how they’ve structured the code, is also very insightful. Having seen a lot of Vex code, the median quality is significantly below that of LemLib. Part of the reason the median team’s code quality is poor, I believe, is that the teams simply don’t know what “good” code looks like. One of the best ways to address that is for teams to read and use high quality code.
I think this would be great. I section of the knowledge base that covers what is inside the black box of VEXcode.
Swinging for the fences here… jpearman could write an advanced VEXcode that approaches some/all features in the current libraries – documented in an expanded API – KB articles about how it works – RECF curriculum to learn the code running in the black box – RECF online certification for use of the advanced library – teams present certification at inspection.
Back to this, and where I disagree with RECF’s policy, is that tools like CoPilot have a fantastic opportunity (admittedly with risk w/r/t student-centered policy) to help show students how to transform poor quality code into higher quality code, or, at least explain why int meme=1; probably isn’t a good idea in competition robotics code. Especially given how widespread and inexpensive/free these tools are, they can be a great floor-raising feature for teams who do have access to people who know what good quality code looks like.
I’m just posting the question here, not trying to argue. I believe discussion can lead to improvement. But if you feel that differing opinions aren’t welcome, I won’t respond further.
I understand that making a new game from scratch, each year, is much more difficult than we give the GDC credit for.
That said… the GDC needs to expand their pool of people so that a prelim design can be evaluated to see if it’s going to sprout multiple competitive designs, or will require a cookie cutter bot to remain competitive.
import java.util.Scanner;
public uh{
public static void main(String[] args){
int googoogaga = 4;
int googoogaga2 = 4
int googoogaga3 = 4;
int googoogaga4 = 4;
Scanner hdks = new scanner(System.in)
System.out.print(“enter: );
int fhdidb = hdks.nextInt();
}
}
and it gave me:
import java.util.Scanner;
public class Uh {
public static void main(String[] args) {
int number1 = 4;
int number2 = 4;
int number3 = 4;
int number4 = 4;
Scanner input = new Scanner(System.in);
System.out.print("Enter: ");
int userInput = input.nextInt();
System.out.println("You entered: " + userInput);
}
}
but its reasoning for changing the variable names was just “not descriptive” and “userInput” and “numberX” aren’t exactly great variable names if you are actually gonna use those variables and take in many inputs. Not to mention it didn’t change the class name of “Uh” which is a terrible class name. It can certainly help make code better, but if i were a teacher looking at this I would change almost every name declaration, put all the googoogagas into an array/ array list, change the use input prompt, put the scanner declaration at the top of the program (that last ones for personal preference). This is all to say that a human will do way better than AI because while AI can change variable names it can’t teach or understand code that’s bad.
Perhaps a more realistic example, with at least a little more context for the LLM to reason over. From James’ submission request, I asked “Improve this code” and pasted in one of the OverUnder examples (it was easy, all the code was in one file) to my free ChatGPT account:
Key Improvements
Remove redundant includes – #include "vex.h" already brings in cmath, string, stdbool.h, etc.
Avoid repeating motor sets – group your drive motors in an array/vector so you don’t copy-paste spin/velocity calls six times.
Fix button hitbox bug – in Button::isClicked(), you used y + width instead of y + height.
Eliminate duplicated auton blocks – you have two if(autonToRun == 2) blocks. Rename one to autonToRun == 3.
Use functions for repeated code – e.g., setDriveVelocity(), stopDrive(), spinDrive().
Fix drive/turn math clarity – right now you divide by wheel circumference inside the function, but you could abstract this with constants.
Add constants for wheel size and gear ratios – makes math easier to update.
Simplify cubic drive scaling – instead of typing the giant cubic equation 6 times, use a helper function.
Improve naming – intakee() → runIntake(), slapper → SlapperMotor, etc.
It also produces its suggestion on what the code should look like, omitted here.
I ran several prompts for MCL odometry with advanced PIDs including Bezier Curve paths though Microsoft’s Copilot (the GPT-5 version) and it was able to use the correct syntax for 700+ lines of code. I haven’t been able to test it (not enough distance sensors and not enough robot…) but everything looked correct. I could post it in a seperate topic, but I don’t know how that would work with, you know, <G4>.
Branching off of AI just writing code, how much are Students allowed to use AI to learn? As of now, I think AI is the single best learning tool for most topics. I beleive students should be able to use AI as a tool for writing code, but that is a difficult can of worms to close. So, would using AI to teach be fine?
TL;DR, I think AI may be able to write code for Vex, given the propper prompts and with some human debugging involved. Also, AI as a coding tool would be cool.
I do this for a living. My company is actively prodding developers to use AI MORE.
There is still a human in the driver seat. The human still needs to have context and reasoning capabilities. The human still needs to be able to describe to the coding assistant what they want and what the assistant did wrong (which, invariably it will do something the human didn’t intend for, or whatever).
And we are mindful that junior / inexperienced developer may not have the discernment skills to know when to let the AI cook and when to reign it in, but we also see junior developers generally using AI more than principal engineers, often to ask the coding assistant to help them understand the code base, figure out where to start, “rubber duck” ideas, etc.
