That’s great! It’s unfortunate that there aren’t enough Fosters for every VRC team. In the team workshop that we run every season here in AZ I try to get across the basics of how each sensor works, as well as basic PID constants as well. From a judging perspective, I think that students that demonstrate a deeper understanding of how the components on their robot work should be rewarded. However, I hope we can agree that a team shouldn’t be worried about a G2/R2 violation if they aren’t able to explain how the VEX PID on their motors works.
One does not need to understand calculus in a mathematical sense to be able to understand PID. It’s enough to simply explain that in this context “derivative” = “velocity”, and that “integral” is just an accumulation of your error, along with suitable analogies such as a car stopping at a stoplight, etc. Middle Schoolers absolutely can understand the concepts behind PID.
I think they made the best call; that’s the clearest way the game manual can be interpreted.
Since I sort of started this whole conversation, I’ll be responsible for my half of the deal too. I’ll put installation and usage tutorials on the back burner and instead make some videos that explain PID, odometry, and the euclidean motion alg in that order. My goal is to both educate on the topics and show how one might arrive at their own solution (i.e. build their own codebase).
I will have all three videos out within the week, so before the first day of Mall of America.
I really like the thinking that this conversation has brought forth and I’m excited for the future of software collaboration in VEX.
I really don’t like this ruling, because I think if you take it to the rules as written conclusion, it makes a lot of things CoC violations that shouldn’t be.
For instance, any team using LVGL to draw graphics on their robot is now, as I read their interpretation, violating the rules. Which means that, for example, this thread where jpearman provides a port of LVGL for VEXcode is him assisting in code of conduct violations, because I’m pretty sure most high school students wouldn’t know where to begin writing a C/C++ graphics library.
LVGL is code, it’s on their machine, jpearman even did some work to make it work for vexcode which makes it a “custom library”, and as we know
Blindly using code without understanding the code functionality is not consistent with the educational goals of this program.
So shame on you jpearman for undermining the educational goals of this program (read with heavy sarcasm, obviously)
Obviously for the past few years I’ve found myself in a grey area regarding providing code for students competing in VRC, On the one hand, everyone is using thousands of lines of my code every time they use V5, IQ generation 2 or EXP. On the other, if I provide a library that extends VEXcode it can become an issue for students that use it. It’s why I’ve stopped providing complete solutions over the past few years. LVGL, idk how that should be treated, it’s complex code, not sure I understand it all because I’ve never really bothered to use it very much.
I guess my thinking would be along the lines of did the code contribute to a robot wining a match. A graphics library may assist in displaying useful feedback on the V5 screen or a more complex UI for selecting auton’s and such, but it really doesn’t make the robot perform any better and most of the time the V5 is so buried inside the robot the screen is difficult to see anyway.
Fair, but that’s not aligned with the GDC’s ruling. Does PROS now need to remove (or provide the option to remove) LVGL and/or LLEMU to provide teams a way to comply?
I would have been more aligned with:
Students should be able to understand and explain the code used on their machines.
But, instead, the full quote is:
Students should be able to understand and explain the code used on their machines, and students should be able to demonstrate that they can program on a level equivalent to the code included on their machine.
And that last clause:
students should be able to demonstrate that they can program on a level equivalent to the code included on their machine.
Is the sticking point for me, with which I vehemently disagree. Part of the beauty of software/software-engineers is using code written by more talented, experience and knowledgeable people. IMO, as long as the students can:
Explain, in reasonable detail (and with some affordances for details/knowledge beyond their ken) what the Open Source implementation (or OpenAI-generated code) does and how it does it.
Explain why they chose to use the code.
Explain how they integrated the Open Source implementation with their own code
Explain how they benefitted from (and what troubles they had) using the code
That said, in the wake of this ruling, teams would probably be wise to make sure more than one student on the team can explain the team’s code to mitigate against cases where a team with a “solo programmer” has their programmer unable to attend an event.
I understand what this ruling is trying to do, and I support the spirit of that effort. I think, however, that this particular ruling can be mis-applied, and the threat of that mis-application will have a chilling effect.
To put a fine point on it, where is the line for a team to use PID? Below is somewhat linear, though I’m sure there could be cases where the level of understand/explainability hops around a bit
Level 1 - Team only says that PID allows them to move their robot more accurately
Level 2 - Team explains that PID takes data from the motor’s rotation sensors and helps move the robot more accurately
Level 3 - Team explains the P-term to some degree, and that they tell the robot how far to move and it controls the speed based on how far from the target the robot currently is.
Level 4 - Team explains how they tuned the P-term
Level 5 - Team explains the D-term to some degree, and explains what caused them to increase the complexity of a P-only implementation. May also explain the challenges of tuning both parameters
Level 6 - Team explains the I-term to some degree, and explains what caused them to increase the complexity.
If only that were true. I seem to spend so much time dealing (re-writing so it works) with software (sdks) written by, how to explain, engineers who have no clue.
Please, can someone ask 95% of PROS users to explain what kind of scheduler FreeRTOS uses? I would be shocked if they could. PROS isn’t any fundamentally different from any other libraries for the V5, especially libraries that sit on top of the SDK like mine, it’s third party software that contributes to robot performance that can be used with no understanding of how it works.
I think some further official clarification is needed on just how close to the bare metal the requirement for understanding how one’s robot’s programming goes.
The GDC is obviously not going to expect students to know how VEXos works, so the likely answers would either be “anything on top of the sdk or vex-provided api”, or “anything on top of a library that interfaces with the sdk”. if it’s the former, PROS becomes disallowed (which while funny im pretty sure isn’t what the GDC wants), but if it’s the latter then PROS would be safe, but things like sylib’s velocity controllers and math utils would be too, which I’m also pretty sure isn’t the intention. Hence why I’d like some more specific guidelines from the GDC, preferably with examples.
My understanding of the ruling would be that if a team can’t explain up to level 6, then using PID is illegal and would result in an event DQ. If a team gets to level 5 then they can legally use PD.
On another note, it seems like using vex’s built in drive functions are illegal for most teams. Using PROS’s okapilib is illegal. Pretty much anything beyond telling each of the motors to spin for a certain number of degrees is illegal.
Guess we’ll be seeing an unprecedented amount of event DQs this year.
If teams/adults follow Student-Centered Policy and the EP/Head Referee/Judge Advisor follow Code of Conduct Report tool process, an event-level DQ should be rare as corrective first action is educating and correcting issues, not immediately jumping to DQ. Early season will likely have a learning curve, but as the new system is gathering reports, clearer guidance will be communicated to teams and event volunteers by the RECF.
The RECF student-centered policy repeatedly talks about “outside sources” or “custom algorithms”. VEXCodePro/VEXCode clearly is not an outside source. I don’t know what the GDC would rule on PROS, but it seems pretty clear to say that VEX’s built-in PID functions will be legal. On the other hand, you’re definitely right about OkapiLib being illegal for lots of teams.
One thing I don’t understand is how match DQs will work. Does this just mean that if a team was using code that they can’t explain for skills auton, only their skills auton wouldn’t count? In addition, if the team explains one of their autonomous routines but not the other, does that just mean they are barred from using the second routine?
Let me fix this for you: Guess we’ll be seeing an unprecedented amount of teaching going on this year.
I’m pretty excited about that. Thousands of roboteers learning what PID means, how it works and why they should use it. Hundreds of team programmers learning how graphics work and what is going on in the library they are about to use.
We teach roboteers all about gears: torque vs speed, why tooth mesh is important, etc. So I’m not seeing a problem in teaching them about the software part.
I feel for James and his interactions with engineers around software practices. If we can be a very small part of teaching future engineers, we should jump on that with both feet.
That’s completely unrealistic. I am a professional software engineer at a medium level of seniority and I just took a look at the LVGL source code and I wouldn’t have the first clue where to begin understanding how that code works, let alone how I would begin teaching a student how that works. It’s hard enough trying to explain what something like a pointer is to a student, outside of a very select few high school students none of them would have the ability to understand LVGL, and even if they could they likely have much better things to do that would make their robot actually competitive, or frankly they should be looking into more advanced programs than VEX.
If a team is able to use something like the LVGL library in a meaningful way, that alone should be worthy of praise. If we’re actually saying that the bar is “you can’t use LVGL unless you can implement an optimized graphics library designed by professional C/C++ programmers yourself” then no teams are going to learn anything about how graphics work because the bar is set absurdly high. And honestly, it makes me question the educational priorities of this program.
As a side note, if the goal really was to force students to learn how to do these things on their own, then I have no idea why the trend with V5 is to just hand magic black box solutions to students. You want PID? Here’s an algorithm that does it for you. Rotate to angle? Don’t worry, IMEs are built into the motors so you can call that magic black box function. You want position on the field? Here’s a magic black box GPS sensor that spits out position. Autonomous selection? Don’t worry, we already have a menu built into the touchscreen on your brain, no need to write your own user interface to select it.
All that magic black box handwavy stuff is just fine, but heaven forbid a team extends on LVGL without understanding how it actually works…
As a student, this ruling makes total sense to me. Once the q&a was asked I had to start thinking about how things like PID, odom, autonomous selectors, ect. actually work and I have learned a lot in the past two weeks. I think the fact that you as a pro
is why this ruling is so important. In a competition about the engineering process, a library should be used to save time not skip through said process. Knowing how to problem solve is a much more valuable skill than being able to use GitHub (which is still very usefull), and the fact that a middle school team that can use GitHub could have equal if not better code than someone who spent months problem solving and troubleshooting code is troubling to me.
Key phrase in my mind is "… program on a level equivalent … " LVGL is super big on the use of pointers. So if your roboteers don’t understand pointers, then they are not going to understand how LVGL works. The docs even say:
Nobody is asking for a “Google Technical Interview Question ™ - write a duplicate of LVGL, here is a whiteboard and a pen.” I think they are asking for “how does something like LVGL work.” At it’s heart its a window / widget manager, that is something pretty easy to explain. Not everyone uses all the functions so being able to explain the functions they do use would give them a pass.
There is a super awesome library that was presented in 2019 that creates a really nice dashboard. The team programmer should be able to explain how the library grabs data, sticks the data into a widget (using pointers), collecting all the widgets into a window (using pointers) an having the LVGL draw it. If your roboteers don’t understand pointers then that’s going to be a problem.
The issue in understanding the LVGL code is understandable, it’s some pretty magical code that runs on a variety of platforms, so there is a lot going on. Anything that is cross platform with that array of functions is going to be a hard hill to climb. But again the GDC response wasn’t to duplicate the code, it was to understand what is going on.
The rule is there to encourage roboteers to learn, not to just blindly copy “stackoverflow” into their robot code. And to cut out bad behavior by non-roboteers in the coding part. They are now going to need to teach the programmers what, where, how and why of the code they are using.
And here we agree. Not a fan of the magic black box approach, but now the roboteers will need to learn what is going on with IMU, PID and the misnamed GPS. So I look to that as also being a win. I struggled with “Mr Foster, we want to do a 6 wheel drive base and the one we have only does 4”. So it’s a little bit back to square zero and teaching new skills.
I agree that this phrase is key, but I think we’re reading that phrase completely differently. In order to use LVGL, you need to be able to program on a level equivalent to an incredibly optimized library written by professionals. The bar is not “need to understand at a high level what the library is doing” or “be able to use some of the concepts being used in this library”, the bar is “program on a level equivalent to”. And virtually no high school students are able to program on a level equivalent to an open source project developed by numerous highly skilled professionals.
Indeed, I would say that no very few developers in the world would be able to “program on a level equivalent” to a major open source project by themselves, because it’s the result of a large group of very smart people working on a thing over the course of years coming at it with their own experiences and perspectives. Which is why you use libraries instead of rolling your own thing, because groups are smarter than single developers.
If you can’t stand at a whiteboard and explain to me how you’d implement something like LVGL yourself, not how you would use the functions it exposes but how you would actually implement the functions yourself, with the level of optimization that LVGL has, then you clearly cannot program on a level equivalent to the code included in your machine. So, sorry, here’s your official warning team, you failed the technical interview, either delete the library from your code or you’re getting DQ’d.
This doesn’t actually solve that problem. Because either the code given to them by VEX is exempted from this standard, or they need to be able to demonstrate they can write a RTOS on the level of VEX OS, a wireless stack on the level of VEX OS, and demonstrate a general working knowledge of ARM development. Because all of that is “code included on their machine.” Also, any team using block programming would be pretty much instantly disqualified based on any interpretation that applied to VEX supplied code.
“Team must be able to demonstrate an active understanding of all code on their machine. If publicly available third party libraries or templates are used, teams must be able to articulate how those libraries or templates were selected, how those libraries or templates were integrated into their code, and demonstrate an understanding of the concepts being used by those libraries.” would be a fine line. “Program at a level equivalent to” means no teams can use LVGL.
LVGL now has many contributors, but it was mostly written by one person, at least up until about 2020 when they formed an LLC and decided to start making some money from the project. LittleV was the nickname (after translation) for Gabor Kiss-Vamosi who I believe is still the primary developer, it was originally named after him, LittlevGL.
LVGL isn’t really aimed at the vex community, that is, I don’t see it as something aimed at end users of a product. It gets distributed as part of the SDK/development environment for SOC devices from many manufacturers, so if, for example, if you were developing a product based around an esp32 chip (popular in many low end IoT products), the solution provided by espressif for graphics is lvgl, just add the library and start using it. LVGL is, however, well documented and on its own doesn’t really do anything at all, you have to invest a significant amount of time in learning the APIs to get it to do even the simplest of things. Once over the learning curve then it can be very powerful, but the learning curve is not trivial.
For the specific case of LVGL, adding the library to your robot does nothing, writing code to create a clever UI using LVGL on the V5 brain needs skill, do that yourself and explain the code and I think you are good to go. However, grab someone else’s cool UI written using the LVGL library without being able to understand that code is not ok. I think in the case of LVGL, “Program at a level equivalent to” means being able to explain the LVGL APIs and how you have used them in your program.
Are you sure that’s what the ruling says? Are you sure that’s how EPs/Judges/Inspectors/Head Refs will ALL interpret it?
Students should be able to understand and explain the code used on their machines, and students should be able to demonstrate that they can program on a level equivalent to the code included on their machine.
@AlecMiller and I might be inclined to say, “If the team is using an external library in a meaningful way”, they have demonstrated to us “that they can program on a level equivalent to the code included on their machines”. Some other Ref/Inspector/Judge/EP might say “Here’s a laptop with no internet access and an empty room and your Engineering Notebook, please duplicate the library you used during the lunch period or you’ll be DQ’d from the Event and written up”. I would posit that the “rewrite from scratch approach” tracks closer to the wording than @AlecMiller and my interpretation.
Of that, I agree with “to cut out bad behavior by non-roboteers in the coding part”. The rest, I believe, is an overreaction to trying to curtail this behavior. Vex Roboteers already, generally, produce pretty poor code. This is somewhat to be expected given they are both “young” and likely more drawn to the mechanical engineering aspect.
That said, one of the best ways to learn how to code is to look at other’s code. See how they structure it. The famous 3 stages of mastery are: Imitation, Integration, and Innovation. This would seemingly cut the floor out of programmers at the first 2 stages.
