Vex Spin Up Skills World Record | 2775V

World Record as of 12/18/2022


Very, very impressive. Are you using the visual positioning strips along the wall?


Thank you! And no, for right now the only sensors we use are two of the old encoders and a gyro for position tracking.


Incredible, the speed is amazing to watch! Why did you decide to shoot from behind the autonomous line?

1 Like

Our regular shots from midrange weren’t great because our blooper angle was really high and our non-blooper angle was really low. So we just shot from far away :man_shrugging:


how did you guys get your odometry to work i have a functioning driver pid for my H drive but dont know exactly where to get started with odometry i’ve watched some videos but dont know how to incooporate it in my design.


For odometry there are two parts people can grt stuck on: the mechanics and the code.

The mechanics are not too difficult; for this robot we used two tracking wheels with encoders and one gyro. We took some time to tune the alignment and rotation of the tracking wheels to be as close to perfect as possible.

The code can be tricky. If you’re following along in your 5225a document from home, you’ll want a pretty good foundation of basic trig and programming. You can make this algorithm on your own from scratch with the math in 5225a’s paper or use a pre-made odom system like okapi or the half-baked, yet-to-be-released “josh template”.

There are a lot of good public odometry-based robots and codebases out there just waiting to be examined.


So do you need the middle wheel/encoder for Odom if you have IMU?

1 Like

Yes. So for example on this robot we have a foward backward wheel and a sideways wheel, and the IMU takes care of rotations. The sideways wheel is necessary because otherwise our robot could slide sideways and not know.

On our mall bot, we only had one forward/backward wheel, because we had tractions and were confident that the robot would not slide sideways at all. Then the heading was taking care of by the IMU and the forward backward motion by the tracking wheel.


Really great run, congrats on #1.

How long did it take for y’all to make the prog skills?


For clarity, here’s a picture of our drivebase from August. It’s the same base as in the skills video.


This is kind of a nuanced question :rofl: So we’ve been working on prog runs since before Haunted, and we had a 30 disc auto wanted to hit a 250 prog at Haunted but it was just not gonna happen. So we scrapped the match loads and made more simple progs.

Then our prog for WPI was meant to get like a 210 or so. Still didn’t happen for a lot of reasons, mostly the prog was just not tuned well at all.

And then last week on Monday evening we sat down and programmed this one, and had it tuned and ready to go by Tuesday evening.

So basically the answer is somewhere between 3 months and 2 days :laughing:


Is there a specific reason for the old encoders and wheel size? We’ve been using the v5 rotation sensors and 3.25s and it’s been working pretty well. But I’m curious if the old ones are more accurate because I see a lot of people use them


Are y’all using any algorithms for the prog movement? It seems like it’s swerving around the field like a driver :smiley:

1 Like

if i were to guess the are probably using pure pursuit and arc turns

1 Like

By arc turns, do you mean that one side of the drivetrain is powered more than the other (so it turns while it moves)?


Wheel size doesn’t matter, and neither does the encoder type. We just had the pods already built with old encoders, so we kept that. In theory smaller wheels and the new encoders are “more accurate”, but after a certain point it really doesn’t matter anymore.


Yes, we are using algorithms!

The swerving movement is just full powering the motors, so like at the very beginning of the run when the robot swings off the roller to pick up the disc and hit the next roller, that’s just motor voltages to make it nice and fast. And then the actual good algorithm is just a drive to point PID function that always tries to face the point it’s driving to. No pure pursuit, no motion profiles.


How do you calculate distances and the like (if the robot is just always trying to face a heading), do you check how far you are from the point and stop?

1 Like

We just have two pid loops going, a drive pid and a heading correction pid. The drive pid takes in as error the euclidean distance to the point, and the heading pid takes the error between the angle of the robot and the angle to the point (which we just get using atan2). Whenever the robot is within an x-inch radius of the desired point, it exits the pid loop and moves on. (Sometimes we use a radius of 2, sometimes 3.