10703Z Change Up Reveal

@trontech569, @Sidoti, @Xenon27, and @Vexation-15486H : Thank you all for your kind words! It’s been a lot of hard work, but a great learning experience and very fun!

@VexTeamZ: I wholeheartedly agree with this. I’ve always thought EDNs could use a bit of attention!

@1691A Thank you so much! Yeah, that competition was a blast! Y’all are absolutely amazing, and it was great to work with y’all!

@Tiezzz03 I’ve actually gotten a number of requests to post a link to my full EDN and code. I’ll be working on both up until Worlds, but after that, I’d be glad to post the completed versions of these. And I’d be happy to answer any specific questions you have in the meantime. I hope this helps!

@Eli_63303 Thank you so much! It’s always wonderful to work with y’all! Best of luck in the coming seasons - I know you’ll put East TN on the map! :smile:

@2775Josh Thank you so much! I know y’all already have a great notebook, but since it sounds like you are trying to improve, let me know if there’s anything I can do to help :wink: And I wouldn’t say I carried y’all at FRA. That two-goal-and-center autonomous was killer. It was a good team effort either way, and definitely one of the highlights of the season for me!


Thanks for post it.
I wonder, know how you made the buttons on the brain’s LCD?
That is my struggle. I tried made it but it was fail. I read other message from forum. It not much help me understand fully. I hope you will a lots of help me.
Like choice the 4 autonomous by buttons on the Brain’s LCD mean will a lots of save on the 8 programming files.

@Tiezzz03: Yeah, the brain screen autonomous selector can be tricky, but it’s very useful once you get it figured out!

The exact code depends on how you want the selector to function. For example, you’d need to consider if you want two buttons to be able to both be selected at the same time. Or, instead, you might want a toggle that so that only one option can be selected at once (such as left side or right side).

Furthermore, you need to think about how user-friendly you want it to be. Personally, I’ve made mine so that I can toggle back and forth until I select “ready” (and I have a condition so that at least one button must be selected before “ready” is available to be selected). Once I select “ready”, whatever buttons I’ve selected, and the boolean flags that are assigned with each button, are locked in until the program is ended and started again.

A much simpler option would be to omit a “ready” button and just check for whatever button is pressed first, and go with that. Of course, if you select the wrong button, you would need to end the program and restart in order to change your selection, but that might not be a huge concern for you.

Here’s some general pseudocode of how I do it with the “ready” button. I’m sure that there are much shorter and more efficient methods of doing this, but this is the way I’ve found to be effective (@jpearman could most likely share some ways to improve this). Again, this code is pseudocode and will not work verbatim, but it should give you an idea of the concept.

bool button1 = false, button2 = false, ready = false;

/* you'll also want to add constant integer values for the dimensions of each button 
(in pixels). these will be used to draw the shape of the button as well as to define 
the region of the brain screen which, when pressed, will change the boolean flag for 
that button to true. I've found it to be easier to use an array for the coordinates 
of each button (this pseudocode assumes you are using a rectangle for the button),
but you could easily just have individual constants for this */
int button1Coordinates[6] = {left x, right x, top y, bottom y, width, height};
int button2Coordinates[6] = {left x, right x, top y, bottom y, width, height};
int readyCoordinates[6] = {left x, right x, top y, bottom y, width, height};

/* now you would print what you want the initial brain screen to be prior to any selections. you can use Brain.Screen.setFont(), 
Brain.Screen.setFillColor(), Brain.Screen.setPenColor(), Brain.Screen.setPenWidth(), etc. to customize your brain screen exactly the way 
you want it to look. you can use the constants above (or reference the appropriate index, if you've used arrays) to draw the button */
Brain.Screen.drawRectangle(button1Coordinates[0], button1Coordinates[2], button1Coordinates[4], button1Coordinates[5]);
Brain.Screen.drawRectangle(button2Coordinates[0], button2Coordinates[2], button2Coordinates[4], button2Coordinates[5]);
Brain.Screen.drawRectangle(readyCoordinates[0], readyCoordinates[2], readyCoordinates[4], readyCoordinates[5]);

Brain.Screen.printAt(x coordinate where you want the text to start, y coordinate where you want the text to start, "button1 label");
Brain.Screen.printAt(x coordinate where you want the text to start, y coordinate where you want the text to start, "button2 label");
Brain.Screen.printAt(x coordinate where you want the text to start, y coordinate where you want the text to start, "ready");

while(ready == false) {
	/* here's where button1 is toggled on. use the coordinates from above to check the region defined as button1 */
	if(Brain.Screen.xPosition() > button1Coordinates[0] && Brain.Screen.xPosition() < button1Coordinates[1]
	&& Brain.Screen.yPosition() > button1Coordinates[2] && Brain.Screen.yPosition() < button1Coordinates[3]
	&& button1 == false) {
	  /* set the flags according to which button is pressed and if any other buttons need to be toggled off by button1 being pressed */
	  button1 = true;
	  button2 = false;
	  /* here you would clear the screen and print what you want to screen to look like now that button1 has been pressed. you would use similar 
commands as above, specifically Brain.Screen.drawRectangle() and Brain.Screen.printAt() */

	/* now, you'd do the same thing for button2 */
	else if(Brain.Screen.xPosition() > button2Coordinates[0] && Brain.Screen.xPosition() < button2Coordinates[1]
	&& Brain.Screen.yPosition() > button2Coordinates[2] && Brain.Screen.yPosition() < button2Coordinates[3]
	&& button2 == false) {
	  /* set the flags according to which button is pressed and if any other buttons need to be toggled off by button2 being pressed */
	  button2 = true;
	  button1 = false;
	  /* again, here you would clear the screen and print what you want to screen to look like when that button2 has been pressed. */

	/* and now for the ready button. I have an extra condition on this one. this code cannot run unless either button1 or button2 have been selected */
	else if(Brain.Screen.xPosition() > readyCoordinates[0] && Brain.Screen.xPosition() < readyCoordinates[1]
	&& Brain.Screen.yPosition() > readyCoordinates[2] && Brain.Screen.yPosition() < readyCoordinates[3]
	&& (button1 == true || button2 == true)) {
	  ready = true; /* this flag will end the while loop as soon as the current iteration finishes */
	  /* again, here you would print what you would like see on the brain screen once ready is selected */

This code goes at the beginning of the pre_auton void function that is built into the competition template. Immediately after this while loop, you would put anything else that you need to run during the pre_auton period (for example, I reset the motor encoders, calibrate my inertial sensor, and check the color of the preload for automatic sorting during driver control).

Keep in mind that because of the while loop, no other code (i.e. autonomous or usercontrol) will execute until “ready” is selected, even if enabled with a competition switch or a field control system!

Hopefully this will help. Let me know if any of this is unclear, or if you have any more questions!


Wow Just Wow, This is my first year and I was by myself as well and I wish I could have done this amazing. I hope if you did make it to worlds that you do amazing.


@ColtTheBolt08: Being a solo team is no easy feat! There’s no way I could have done it my first year. My advice to you would be keep at it and learn from other teams! I can’t tell you how much I learned from talking to other teams in my region, and one of the great things about VEX is that everyone is always super willing to help others. And, hey, let me know if there’s anything I can do to help as well!

By the way, I did qualify for Worlds as a one-person team, and with a LOT of hard work, I bet you can too!


BrainSTEM: “This is my first season building, so the design of my robot is fairly simple”

Also BrainSTEM: Creates bada$$ X-Drive, automated sorting conveyor, insane design notebook.

That is an awesome build and EDN, well done!


Wow! You have a very impressive robot, program, and notebook for just a one person team! I’ll definitely be studying those notebook shots to improve my own notebook haha. Really impressive and congrats on skills champion and excellence at states!


@9181X_Austin: Thank you!

@AliA: Thank you so much! I hope it’s helpful for you; it’s always good to see teams improving their EDNs! Let me know if you have any questions.


I’ll be sure to! Thanks!

1 Like

Wow! neat bot!

what advice would you give for attaching vertical beams to the chassis?

@Hao_16688C: Thanks! As for attaching vertical posts to a chassis, I’d say that it depends on the type of base you have. For VRC, it’s generally a good idea to use c-channels oriented in a way so that the flat sides are together with four holes directly on top of each other in a square. If you have a tank drive, you can probably use the bars you already have on your base as the horizontal. Make sure that both the horizontal and vertical bars are level, straight, and as square as possible, as well as spaced appropriately according to the rest of your design. Using at least two screws is a must! Personally I use two screws, one in each of a diagonal set of holes on the c-channel for stability but minimal weight. I’d recommend using nylocks. For additional stability if needed, triangle braces are good, although I do not have any of these on my robot.

With X-Drives, it’s a bit more challenging. In order for me to have a horizontal bar to attach the vertical posts to (in the same method as described above), I had to connect a c-channel across each side of the X-Drive. However, due to spacing issues, I could only have one screw on each end of the c-channel, and the holes did not line up, so I ended up having to widen the hole with a dremel. If you do this, drill as minimally as possible! This weakens the c-channel, but unfortunately, it was necessary for my design.

On a related note, think about the order in which you are building. Sometimes this requires some trial-and-error, but considering this beforehand can save you a lot of time, grief, and rebuilding. For instance, would your wheels or intakes hinder you from reaching the area needed to attach the vertical bars? This happened to me, and I had to temporarily remove my wheels and drive motors just to be able to get the vertical posts attached.

Here is a close-up of how I've attached the vertical bars to my robot.

vertical attachment close-up

I hope this helps! Let me know if you have any more questions.


@BrainSTEM, as @9181X_Austin said, that’s a

you’ve got there. Do you have any tips on it for those struggling with creating one? Looking closely, it also seems like you use the newer gussets with the larger rectangular holes for your drive. Did you have any problems with those?
A response here about that might be nice.


(@VexTeamZ )
X-Drives are definitely challenging due to all of the angles and precision required. There are a few tips that what I’ve learned this season that I would share with anyone trying to build one for the first time:

  • Be meticulous: Make sure the wheels spin smoothly. Friction causes problems, especially with X-Drives. Use a protractor to measure each angle, and adjust each until it is as close to perfect as you can get. Make sure that all the holes line up as closely as possible.

  • Spacing: Make sure to plan out the spacing of your design. The positioning of the wheels can make it difficult to mount what is needed for other subsystems. Make sure you have room in terms of length, width, and height for your chosen wheel size, and that all of your subsystems fit as needed within the size limit with whatever size of wheel you have.

  • Stability: Make sure to have enough supports so that your X-Drive is not cantilevered and so that once you get all of the angles just right, everything stays in place. Also, add supports across your X-Drive so that there is no bowing or caving in once you have the weight of your other subsystems resting on the base.

  • Weight Distribution: Unless the weight of your robot is well-balanced, you will most likely have to deal with translational drifting when driving and strafing. There are some ways to counter this in programming, but it definitely complicates things, so be prepared.

  • If it is possible with your design, make your X-Drive square. Rectangular X-Drives work, but they turn much slower than ones that are square.


notebook looks great! one of the best ive seen this season


Thanks for the shoutout! It was an honor to fight alongside and against you this season.


Yoooooo, this is so sick, and that journal is rockin’! Nice reveal : )

1 Like

When do we get the full notebook reveal?

Well, I had planned on releasing the full version, complete with LRS Worlds analysis, the beginning of next week, but I’ll go ahead and post this version (@9935E ).

I will mention that while my EDN is by no means a perfect or the best method of documentation, the judges at the tournaments where I’ve competed have seemed impressed by it, so I hope it will help to provide an example of how you could choose to record your design process.

Without further ado, here’s my EDN through 4/19/21, the version I submitted for judging at Worlds:

For anyone who doesn’t feel like scrolling through 230+ pages of notebook, here’s a few tips I would suggest:

  • Follow the rubric. I would recommend using the exact wording from the rubric (such as design/game/robot challenge, decision matrix, solutions, etc.) where possible to make sure that a judge with any level of experience can easily find what he or she is looking for. Include all steps in the design process. Make sure to specify which teammates do what tasks and have everyone present sign and date each page. Remember to date any code, photos, CAD, etc. that you add in as well.
  • Use lots of labeled photos, sketches, etc. Judges don’t have long to look at your EDN. They won’t have time to read every word, and some sort of visual aid is almost always easier to understand anyway.
  • Include goals. It’s best to have specific goals so you can objectively determine if that goal has been achieved. “Score at least 120 points in driver skills” is much better than “Get a good score”.
  • Getting awards is not the only reason to keep a detailed EDN! It’s very useful to be able to look back at previous designs and recall what worked and what didn’t, and what the problems were. Also, I’ve found that in explaining what I’m trying and why, it actually helps me understand what I’m doing more fully.

I hope this will be a beneficial resource for any teams out there looking to improve, and I’d be happy to answer any questions you might have!


Now that Worlds has passed and I’m no longer working on code for Change Up, I’d like to share my programming with anyone who is interested. Here is a link to a video of my programming skills run during LRS Worlds (106 points with a 1 second stop time).

A bit about my code structure

In terms of the structure of my code, I have developed my own index / flagging system (rather than using the built-in functions in VEXcode for tasks or threads) for multitasking to prevent conflicting motor commands and to have complete control over which macros and manual controls (in driver control) or functions (in autonomous) are allowed to execute simultaneously.

Work-arounds for consistency

For consistency in autonomous, I would have preferred to have tracking wheels and to have implemented odometry like we’ve all seen successfully utilized by so many of the highest scoring teams. Due to spatial restrictions and time limitations, I’ve opted to find perhaps unconventional work-arounds for reliable drivetrain movement, as well as to account for factors such as weight distribution and drift, instead of odometry and/or tracking wheels. For instance, I’ve used the inertial sensor’s accelerometer for translational drift correction, and I have added a lot of correction code so that if the robot missed picking up a red ball, it will descore the blue ball(s) in the goal in which the red ball was intended to be scored so that the blue row will be broken.

Brain Screen Autonomous Selector

I’ve gotten a number of comments about my Brain Screen Autonomous Selector. The programming for this can be found in my preauton function. Here is what it looks like with options “Score” and “Ready” selected:
auton selector

Here is my full Skills program (I have pasted the code as a PDF):
10703Z LRS Worlds Skills Program.pdf

Also, in case it is helpful, here is how I’ve configured my motors and sensors:
10703Z robot-config-cpp.pdf

I hope this will be a beneficial resource and perhaps provide some insight into a different way of programming and code organization. I’d be happy to answer any questions you might have!


perhaps consider sending me the project so I can add to this years code repo.