Fastest Automated Color Sorting Mechanism

Speed in robotics isn't just a single decision but rather a chain of multiple choices, each optimized to create a mechanism that is fast and efficient. The result is an automated trapdoor that color-sorts red and blue blocks - either keeping or ejecting a chosen color. The same principles behind this build show up in industrial sorting lines, agricultural processing, and factory automation. This Instructable goes through the different stages of building and optimizing for its speed.

But first, what are you even seeing?

What you are witnessing is the color sorting trapdoor mechanism on my VEX V5RC Robot in play. VEX is a robotics competition for middle and high schoolers, and for the 2025-2026 season, our game is Push Back.

Objective:

The objective is to score your alliance color blocks into different goals to score the most points. The problem is that there are over 80 blocks on a field, and it is difficult to pinpoint your own color while driving. If you score the opponent's block, they get points. Which is why I developed a trapdoor mechanism that color-sorts opponent blocks so that while driving, you never have to worry about which color you are intaking. In the end, you will be left with yours! Not only that, but any sorting mechanism won't do. It has to be speedy and precise so you can score as many points as possible.

The following materials are specifically related to the color sorting mechanism. All items can be found through VEX or Robosource:

Materials:

1. Aluminum Channels: 1x1x15, 1x1x8, 1x5x1x7
2. Nuts: 10 #8-32 Nylock Nuts, 1 #8-32 Keps Nut
3. Screws (All #8-32): 4 3/8" with .12" Shoulder, 7 7/8" screws, 1 1.75" screw
4. Spacers/Washers: 4 0.5" spacer, 1 0.25" spacer, 3 1/32" washer
5. Additional: 1 pillow bearing, 2 shaft collars, 50mm Stroke Pneumatic Cylinder with Fittings, Optical Sensor, Hinge

Tools:

1. Star Screwdriver
2. Wrench

Needed For Testing:

1. VEX V5RC Brain, Battery, Wires, Controller
2. Tubing, Air Tank, Double-Acting Solenoid

Software:

1. VSCode with PROS C++ Framework Installed
2. Fusion360

Code discussed in this Instrucables: https://sharepad.io/p/bJOTBze

Before any building or optimization can happen, you need a clear picture of the physical path a block travels through the robot, because every optimization in this Instructable is motivated by something specific that happens along that path.

Blocks enter through the front-facing intake rollers powered by the intake_motor (the name of the motor in code). This is the first stage, the three rollers that grab blocks off the field and pull them into the robot's body. Towards the end of the first stage, the decision point for the trapdoor (the color-sorting mechanism) occurs. Before the blocks even start to go up through the rest of the robot, the blocks have already been sorted. Since color sort is no longer an issue after the first stage, we will not focus beyond the first stage rollers and trapdoor.

This step is important because choosing the right hinge type for the mechanism leads to the fastest, smoothest path out for the block. The wrong pivot direction introduces jams, and jams are the most catastrophic failure mode for a high-speed sorting system. A single jam during Driver Control can cost five to ten seconds and several scoring opportunities.

Deciding Configuration:

After evaluating four configurations in the image, three were eliminated. A top-right pivot creates a protruding lip that catches incoming blocks mid-stroke. A bottom-left pivot sweeps across the path in a scooping motion that gives fast-moving blocks the opportunity to wedge against the gate face. A top-left pivot deflects blocks upward rather than downward. This is important as we want gravity in our favor to allow for maximum speed and ejection of the blocks.

The correct choice is a bottom-right pivot, folding downward. The pivot sits at the base of the gate, and the piston connects above it, creating a lever arm that sweeps the gate face downward into the block path.

Benefits:

This geometry achieves two things simultaneously.

1. The deflection angle sends blocks downward and back toward the ejection exit, so the block's own momentum assists the redirect rather than fighting it.
2. The gate's upper edge enters the block path first, meaning ejection begins before the piston has even completed its full stroke. Both effects compound to make each sort faster and cleaner.

Now that the type of hinge is decided, we should now CAD the trapdoor.

I will be using Fusion360. Why? Because Fusion 360 handles mechanical design, motion simulation, and more in a single environment. This means the same model used to design the trapdoor geometry can be animated, visualized, and tweaked for perfection without ever leaving the software. For mechanisms where the relationship between moving parts is critical (the trapdoor's hinge and pneumatics), the wide variety of different joints and motion tools available allows for accurate measurements and spacing without waste. Lastly, it is free for students!

To allow for the fastest actuations, we must keep the range of motion for the trapdoor minimal.

Sketch:

To start, we should sketch out the different points the trapdoor will have to be at.

The sketch shown represents a block on a tangent path relative to how it would exit the first stage. There is a highlighted blue line with two points representing approximate points where the end of the trapdoor could be. The length of this line is 3.1 inches ~ 78.8 mm.

This is why I will choose a 50mm piston, as I can push from a point under the backing of the actual trapdoor.

Creating the Mechanism In CAD:

1. I start by measuring different points where the block starts to go up the bot's path. Fusion helps me visualize this so that I can create a protruding structure the right size to mount my hinge upon.
2. I attach a backing of aluminum channels to the hinge that the block rides up on.
3. I use Fusion's revolute joint to motion the movement that the backing makes.
4. The location of the piston is nowhere close to the backing, so I attach a channel across the backing far enough to reach roughly where the piston is.
5. My sketch determined I would not have an exact point of mounting, so I took advantage of Fusion's cylindrical joint to join the piston to the extended channel and find the correct amount of spacing for a robust fit.
6. I confirm the trapdoor's motion by running the block through different scenarios and paths through Fusion.

Our goal was to have a minimal range of motion for a short window time. The picture attached shows we accomplished this goal as there is no unnecessary waste in the motion.

This video shows the trapdoor motion in Fusion360.

Below are two interactive embeds of the F360 models. One is the trapdoor itself, while the other is the full robot assembly. This is why Fusion was the perfect choice, as it allows you to easily work on different parts that can seamlessly join together for you to visualize the assembly. Use the embeds below to visualize the relation of the trapdoor to the block's path in the robot.

TRAPDOOR:

ROBOT ASSEMBLY:

Loading for the embed takes a long time, so click here to go to Online Fusion to check it out. Below is a video showcasing the Robot with the trapdoor.

Using the CAD, I built the trapdoor mechanism.

1. Attach the Piston
2. Use 2 7/8" screws and 2 nylock nuts to secure the bearing
3. Then use a 7/8" screw and a keps nut to create a screw joint for the piston. Creating a screw joint is important, rather than a regular one, to prevent friction and therefore increase speed.
4. Add a washer and attach your piston.
5. Add a nylock nut to keep things in place. Don't tighten too much - make sure the piston can freely rotate.
6. Attach the Trapdoor
7. Prepare the backing by taking a 1x5x1x7 and screw in the 1x1x8 to it using a 7/8" screw and a .5 inch spacer. Additionally, attach the standoff stoppers with screws.
8. Attach the 1x1x15 channel to the main frame of the robot using standoffs and screws.
9. Attach the hinge to the center of the 1x1x15 channel and the 1x5x1x7 using the shoulder screws and nylock nut.
10. Put it together
11. Using the CAD, follow the spacing needed to properly align the 50mm piston to the 1x1x8 channel.

Now you have a trapdoor that can pass blocks through.

It is always good to go back to the CAD (shown in previous step) to visualize the mechanism to aid in the building process.

I attached the piston to a simple switch mechanism for testing.

You can see this in action:

Although hand-powered, the concept of a hinge and a trapdoor motion shown in Fusion is the same here in real life - a success.

So far we optimized for speed by:

1. Choosing a gravity-assisted hinge mechanism
2. Found a minimal range path
3. Screw Joints

But this is all to the hinge itself. One thing to consider is the parts of the robot before the trapdoor. This means to make the first stage faster.

At first glance, this optimization seems counterintuitive. Making blocks move faster through the system seems like it would shrink the trapdoor's reaction window, not expand it.

But this also means the blocks eject out faster. If the block does not have enough momentum to fly out, then it will get stuck in the path of the trapdoor, leading to jams. A fast first stage allows for the color sorting mechanism to act faster and more accurately.

Solution:

Gear Ratio. The intake system uses an 11-watt VEX V5 Smart Motor with a 600 RPM cartridge - allowing for speed rather than torque. At 600 RPM, the motor is already spinning quickly, but the first roller in the three-roller intake stage is geared up further through a 1:2 gear ratio, bringing it to an effective 1,200 RPM. The second and third rollers run at the motor's 600 RPM.

This video shows the intake in action:

With this, the number of blocks color sorter per second will be significantly faster!

Previously, I only had a switch controlling the air flow to extend the piston and relied on the rubber band to pull the piston back. Although this works, to reach the objective for a speedy color-sorting mechanism, I decided to control the retraction as well.

I had to use a double-acting solenoid and attach a fitting to the other hole of the piston for it to work.

The following is the video of it working:

As you can see, the extension and retraction are almost instant, and this will allow for the color sorting process to be instant.

The last step is to automate the process by placing the sensor and writing code.

I use a PROS framework that supports VEX sensors in C++.

See the code in the Supplies Section.

Sensor Placement:

The sensor is placed approximately one block's length away from the trapdoor. This is intentional. There's always a small delay between detection and actuation. The code has to run, the solenoid has to fire, the piston has to move. By the time all of that happens, the block has already traveled that one-block distance and is sitting right at the trapdoor. Place the sensor too close, and the trapdoor opens too late. Place it too far, and it opens too early for the next block. The image above is the result of trial and error in finding this position.

Detection:

The optical sensor reads two things: color (as a hue value from 0-359°) and proximity (how close an object is, from 0-255). Using both together is what makes this reliable. Color alone would trigger on any red or blue object in view - a gear, a wire, anything off in the distance.

The above is the code for checking proximity. 255 is the closest to the sensor, but 50 works. The path of the block basically rides on top of the sensor so any number from 50-200 could work.

Picking these narrow values to detect color allows for the best results and prevents malfunctions.

Paired with this, we set the white LED lighting on the sensor to max for best color detection

I also continuously print proximity values for testing.

The code then does a double confirmation. It checks the color once when it first detects the block, then checks again 10ms later before committing to opening or closing the trapdoor. This eliminates the brief, random misreads you get when a block is right on the edge of the sensor's field of view. Yes, it adds 10ms of delay. But that 10ms runs in parallel while the block is still traveling toward the trapdoor, so the delay doesn't really add up.

Benefits:

1. Fewer false triggers
2. Faster reliable sorting
3. Mechanism that doesn't second-guess itself mid-match.

Because the trapdoor is more reliable without added delay, we can rely on shorter actuation windows allowing for a faster color sort.

The video below shows the proximity and the color detection working together:

You can see from the printed text on the brain that once the proximity hits 50, there is a sudden movement - that's the trapdoor activating.

Some videos of the color sorting:

Here is a video of the trapdoor working in a tournament (robot on the left)!

After hundreds of blocks tested, there has obviously been some jamming here and there, but I found around a 98% success rate. It hasn't failed in tournaments and in autonomous when it is really needed. Most importantly, it was the speed of the trapdoor that allowed for won matches and high scores, preventing accidentally scoring opponent blocks.

Although a speedy mechanism, there are always more things you can do. For example, in some of the videos, I had a 1x5x1x8 instead of x7. I changed to a slightly shorter 5 wide because it allowed for the trapdoor to close when the block has been ejected a shorter distance, allowing for an even shorter window and fewer jams. With an 8-hole-long channel, I would have never been able to do what is shown in the photo. An x6 and maybe an x5 is possible, but it comes with risks of leaving too big a gap for blocks to get stuck on.

Of course, adding things like grease can also significantly improve the hinge friction and allow for rapid sorting!

Imagine instead of blue and red blocks, it was a conveyor belt of fruit. Apples rolling past a sensor, some ripe and ready, but others are rotten and spoiled. Or a grain processing line where rocks and debris are mixed in with crops. Every second wasted is money down the drain, less food to people, and reliance on a slow, inefficient system. The specific mechanism on this robot cannot sort apples or grain, but every engineering decision here applies directly to systems that do.

Although the scale, stakes and materials are all different, the core problem remains the same: you need a machine to accurately and quickly make decisions to systems humans can barely keep up with. Keep or Reject?

That singular problem is what every optimization, every step here, is based on.

From hinges to intake speeds to sensor detection, a color sorting mechanism has been built, which is able to sort game elements for an objective and can be applied in many real-world scenarios.