How do I make a auto goal-tracking system? (Spin-up)

So my team and I plan on making a bot that intakes 3 discs, then gets into range and then uses Odometry or some tracking system to basically turn itself around and align itself with the goal. So it would look like, once the bot get’s within range of the goal, the driver then has to hit one button to auto-align/point the bot to the goal (by simply rotating in place), even if the bot is turned completely around. Then hit another button to launch each disc through the flywheel.

My question is what type of sensors would you need to make this “tracking-system” work?

How would I program the entire thing to integrate the sensors with the motor control?

In this scenario imagine the red box is the bot, and the front of the bot is the black oval. The Driver by default lets the bot have 3 discs, and get into range.
Screenshot 2022-10-24 7.47.37 AM

I need the tracking-system to rotate the bot in it’s place so it faces the goal, moving in no x and y position, only turning around, or rotating around in the same x and y position to face the goal. With one press of a button.
Screenshot 2022-10-24 7.46.30 AM

Could this tracking system be made with a 1 vision sensor, and 1 inertial sensor?

There are many different way to track the goal. 2 of the most popular way are odometry and vision sensor. Odometry uses tracking wheels to find the robots position and then you can use trigonometry to point to the goal. Vision tracking uses the vision sensor to identify the goal by it’s color and turn to face it. The easiest way to integrate it is to use PID.


Is it rather straight forward to code the vision sensor and Odometry, or should I outsource the code?

Is it possible that I could track the goal using only Odometry?

Also for Odom do we need 3 V5 Rotation Sensor - VEX Robotics?

If I were planning on doing Odom I would only need 3 rotational sensors ($120) , and then use PID to integrate them, right?

You can use two wheels + IMU.


Inertial, distance, and multiple Vision. Use Vision to auto search for and intake discs (Drive forward while using a vision based turning pid). Use distance to make sure you take in only enough discs and not too many (No PID here, just logic). Use Inertial to turn roughly towards the goal (You can just turn to a direction for budget functionality). Use another vision to track the goal (Vision PID applied to wheels to turn).

Distance is harder. You can use multiple distance sensors in the +x, +y, -x, and -y directions to sense your coordinates, filtering a bit. You can use a well tuned vision and try and process the goal to tell how tall it is. You can put a distance sensor aimed at the goal to tell how far it is. You can use odometry/GPS to know where you are roughly and then Trig to find distance. Whatever you use, you then want to drive until you are at an optimal distance and shoot.

Or just be dumb and drive till you hit the low goal perimeter to know when you are at a known distance.

1 Like

Sorry for being so vague with what I wrote but I forgot to specify that the bot in-taking 3 disc’s and getting into range is all going to be done by the driver, the only thing that I want to be done by the bot (using a tracking-system) is to simply turn around in place to face the goal.

So in this senario imagine that the red box is the bot, and where the black oval is, is where the front of the bot is. This bot, already has 3 discs loaded up by the driver, and it is range by the driver.

I need the tracking-system to just turn the bot around to point at the goal, and turn the bot around in place. So the bot’s not moving in any x or y direction it rotates itself in the same x and y position around to face the goal. In one press of a button.

Updated the original post to include this.

Once you find your x and y coordinates using odometry, you must find the slope from the coordinates of the high goal to the coordinates of your robot, and take the inverse tangent of the slope, and convert it from radians to degrees. This is the heading your robot must face to shoot into the high goal.


This year we have 3 wheel odometery with an inertial sensor. We really do two wheels odometery with the inertial but I put 3 on the bottom just in case we wanted to find direction with wheels(maybe to avoid some gyro noise). However If you track you position and heading with odometery as well as where you started you can do some trig to find out how much you have to turn to point to the goal. If you are wondering if this is feasible for a match and if the odometery will get off, if you implement it right it won’t, or the error will be very small and will get you close and you can correct manually. Beastly in skills. I know you said you just wanted a turn to shoot, but it’s not to hard to do a velocity controller with a function of the distance to get it to lob into the goal if you have a flywheel. If you got any questions on the math/coding/track wheels I can help :+1:

1 Like

GOLD! RoboVlog - Track Wheels and Intakes - Vex Spin-up Ep12 - YouTube This is my rig. V5 rotation with 3.25 omnis. I’ve since added rubber band suspension to hold wheels down

1 Like

As of now, my team and I are simply testing sensors, just trying them out for the first time. We’re starting off with the Vision sensor to aid our aiming. But if we get better funding. We were planning on making a catapult that would be installed on top of a tracking turrent. This turrent would track the goal using a vision sensor. Then as your team was planning, we would use the same Odom configuration with an inertial sensor to redirect the turrent when need be.

Where could we find resources to aid us in programming pid and these sensors?

Here is PID, odometry , and the vision sensor. If you need additional information or help make sure to look for it using the search bar before making a post.


The reason we didn’t go vision sensor is because we tried it a couple years ago and it worked in the shop, but when we got to comp the lighting was different and it threw the whole thing off. However when it did work it was really useful and I’m sure if you spent enough time on it you could get it to work under different environments. Let’s just hope your opponents don’t wear red shirts. The resources I uses is what I picked up from a conglomerate of my high school courses but I mainly thought of the system as adding a bunch of tiny vector components together. We have a task/loop that runs really fast (20 msec) that takes the rotations from the forward facing tracks wheel, multiplies it by the sin of the angle of the gyro, then adds this to a y-value. Take the cos(angle) times distance to add to the x-value. If you have a sideways facing wheel you can do the same thing but plus 90 degrees. I know that’s a rough explanation but it’s not too much code and if you stare at it long enough it will eventually make sense. Also there’s probably a lot more people online that could explain it better than I. Awesome that y’all are going turret!