Hey everyone! My name is William from team 663B, and I have recently graduated. As such, I wanted to share with you all my pet project for the past few years: the program that I used during Change Up. I present to you: Project Cerebellum, a semi-intuitive graphical settings editor for the VEX V5 Brain. Let’s review some of the features:
A motor configuration menu where you can alter:
A sensor configuration menu where you can alter:
A controller configuration menu where you can alter:
What button the configuration is assigned to
What type of motors the configuration moves
What voltage the button moves the motor at (including reversed voltages)
A drive model configuration menu where you can select whether you want your drive model to be Tank, Arcade (Left), Arcade (Right), or Split-Arcade.
A complex autonomous editor, that allows the user to select a pre-defined autonomous, or create their own using an on-screen representation of the field.
15 custom autonomous slots
Reads text from the standard input (PROS terminal) as an alternative to using the on-screen keyboard for text areas.
Now, I’m going to be candid with all of you. This program works, but is VERY janky. Editing it was a nightmare, and when I started this project, I didn’t even know how to use a class.
The program saves any changed data by reading from and writing to an ini file on the MicroSD Card. Without a MicroSD Card, any changes made will not be saved the next time the program is ran.
To set the program up, all you need is to build it and insert a MicroSD card into the V5 Brain.
Once ran, create a new motor in the motor menu and open the configuration. Set the port and the motor type using the menu in the upper right (something other than Left Drive, Right Drive, or Sorter. You can also define your own motor types by editing the motor_type_list vector in globals.cpp). Then, open the button mapping configuration, and create a new button. Set the button you want to use, and go to the next page. Set the controller type using the drop-down menu to be the same as the motor you defined earlier.
Finally, set what voltage you want to the motor to run at on the final screen (-12000 to 12000).
Pressing the button you set earlier should cause the motor to move.
Toggle-able button configurations
Proportional-loop motor controls
Tipping-Point Configurations (Change Up only)
Adding a controller button in the button mapping menu crashes the program unless a motor has already been defined.
Workaround: Define a motor beforehand.
Having more left drive motors than right drive motors causes the program to crash the next time it is ran.
Workaround: Define the same number of left drive and right drive motors before rebooting the program.
I wrote it, so it was legal for me to use it, but I don’t think that it’s legal to use someone else’s code in competition. It’s tailored for my team’s robot anyway, you’d have to make significant modifications to have a working autonomous with it.
I think this this follows suite more with “nonfunctional decoration” because the code does not change the outcome of a match nor gives competitive advantages (maybe excluding the autonomous portion, which may need to be clarified by the GDC). That being said, for the most part I doubt any competition will assume there is anything wrong with other teams using this code publicly released.
Alas, it is functional code… and specifically could be considered in violation of <R2>
<R2> Robots must be a representation of the skill level of the team. The Robot must be designed, built and programmed by members of the Team. Adults are expected to mentor and teach design, building and programming skills to the Students on the Team, but may not design, build or program that Team’s Robot.
That said it is great to share code excerpts and learn from one another - but keep <R2> in mind.
I realized he stated “autonomous creation” and was thinking maybe not a good idea for teams to copy its entirety as the code literally simplifies autonomous making for every team.
Honestly, I feel as though something small like an autonomous picker publicly would not raise red flags. But for directly copying code that students are capable of making their own autonomous inside of a graphical program on the Brain seems a bit of a stretch (if teams are considering copying this code for themselves), as few teams would be able to make such a code on their own.
Well, the “autonomous creation” is just set of pre-programmed instructions for every possible action on the field for Change Up. Once again, this is specifically tailored for my robot and Change Up, so it would have little use for other teams without significant modifications.
I don’t see any issues using this code since it is publicly posted and is available to all teams. A lot of good teams use OkapiLib which can give a much more of an advantage and it’s perfectly legal. Using code that is only available to some teams is what violates <R2>, because it gives your team an unfair advantage over other teams that don’t have access.
I’m not saying anyone should or should not use this code, that’s up to you to decide. Generally, you should try to understand the code you are using and not just blindly add it to your project, and always credit the author/source. All I mean to say is it does not violate any rules. There is value in both learning how to write the code yourself and in learning how to work with code written by others, you should find a good balance.
Not about “unfair advantage” but skill level. That is the measure. Let me give you a stripped down example - middle school team uses a PID library from their HS teams. During interview with judges, it is clear the team has no clue what PID really does, the HS team tuned variables for them, … that is an example of a team using other people software above their skill level. Sorry, that team certainly would not be considered for Think Award, and if certainly should be flagged for R2 violation.
Feel free to argue otherwise.
I like the underlying intent of the rule is for teams to be operating at their level, not taking shortcuts outside their skill level.
Whilst I agree with the rules, the issue I always have is that every student is effectively using someone else’s code. The OP example is using lvgl, an open source project, and PROS, a semi-open source project created by students. PROS is using the VEX provided sdk, which in turn is using vexos. So at what point do you draw the line, this just feels like another slightly higher level graphics layer built on top of lvgl, seems like it should be ok for anyone to use as long as the functionality it provides is understood.
that was my one and only point - copy paste not good, finding solution to problems and adapting good.
I draw this from the button example code you provided, and we tweaked for autonomous selection - it was pretty good stuff, but there were a number of teams who copy/pasted, with no clue really how it work, not attempt to attribute the code - kind of weird to see you teams colors on other V5 brains. This was all before <R2> clarifications… and the example we have of very inexperienced teams getting other teams to tune their robots without understanding what is going on.
I think there are a lot of creative ideas out there - explain, share, etc… all good. If you benefit, understand, re-explain/adapt, and give credit where credit is due.
I look forward to the day teams share 3D models to solve game challenges.