Below are key principles to help you create stronger, lighter, and more reliable 3D printed parts for robotics applications.

Start with a Good Design

A strong print starts long before you hit the “Print” button. Good design habits can dramatically improve part strength and reliability.

• Avoid sharp corners whenever possible. Fillets and chamfers reduce stress concentrations and make parts more durable.
• Design for thickness, not just shape. Thin walls may look fine on screen but can crack under load.
• Reinforce high-stress areas like bolt holes, shafts, and mounting points with extra material.
• Use standard hardware sizes so your parts integrate cleanly with existing robotics components.

Designing with real-world forces in mind—torque, vibration, impact—will save time and filament later.

Picking the Right Filament

Not all filament is created equal, especially when it comes to robotics.

• PLA is easy to print and great for prototypes, but it can deform under heat and stress.
• PETG offers better flexibility and durability while remaining beginner-friendly.
• ABS is tougher and heat-resistant but requires careful printing conditions.
• Nylon and carbon-fiber blends provide excellent strength-to-weight ratios for competition robots but require more advanced printers.

Choosing the right filament depends on how the part will be used—structural load, temperature exposure, or repeated movement.

Slicer Settings – Strength vs. Weight

Your slicer settings play a huge role in determining how a part performs.

• Infill percentage controls internal strength. Higher infill adds strength but also weight and print time.
• Infill patterns like gyroid or cubic often provide better strength than simple grid patterns.
• Wall thickness is often more important than infill. Extra perimeters can significantly increase durability.
• Layer height affects bonding; slightly thicker layers can sometimes improve layer adhesion for functional parts.

Balancing strength and weight is especially important in robotics, where excess mass can reduce performance.

Print Orientation Matters

One of the most overlooked factors in 3D printing is orientation.

• Parts are strongest along the layer lines, not across them.
• Load-bearing forces should be aligned with the strongest print direction whenever possible.
• Bolt holes printed vertically are usually stronger than those printed horizontally.
• Reorienting a part can dramatically improve durability without changing material or settings.

Always think about how forces will travel through the printed layers once the part is installed.

Testing Your Part

Testing is where theory meets reality.

• Test fit parts before final assembly to catch tolerance issues.
• Apply real-world stress—pull, twist, or load the part as it would be used on the robot.
• Iterate quickly by adjusting design, orientation, or settings based on failures.
• Encourage students to learn from breakage, not fear it. A broken part often teaches more than a perfect one.

3D printing allows rapid iteration, making it ideal for learning engineering principles through experimentation.

Final Thoughts

3D printing functional parts for robotics is a blend of design, material science, and hands-on testing. When done correctly, it empowers students and teams to solve problems creatively and build custom solutions that simply aren’t possible with off-the-shelf components.

With thoughtful design choices and a willingness to test and improve, 3D printing becomes more than a tool—it becomes a core engineering skill.

Some teams chose to aim manually, but this approach was often slow, inconsistent, and highly dependent on driver skill. Other teams implemented automatic aiming using either AprilTag vision tracking or odometry. In this article, we’ll explore how to build an auto-aiming system using odometry, with a focus on reliability, speed, and repeatability during TeleOp.

Why Use Odometry?

Odometry uses sensors to track a robot’s precise location on the field, including both position and heading. A common FTC implementation uses dead wheels—non-powered omni or mecanum wheels that remain in constant contact with the field and rotate as the robot moves. Encoders attached to these wheels measure rotation, which can be converted into distance traveled and direction.

By continuously tracking these movements, the software estimates the robot’s current pose, defined as its x-position, y-position, and heading (orientation).

When properly tuned, odometry can be extremely accurate—even over the course of an entire 2½-minute match. Dedicated odometry processors can be even more precise, as they sample encoder and IMU data at a higher frequency than the main robot controller. One FTC-legal example is the goBILDA Pinpoint Odometry Computer, which uses two dead wheels combined with an internal IMU to provide accurate pose estimates.

Pathing Libraries

Teams using odometry are strongly encouraged to pair it with a pathing library such as Road Runner or Pedro Pathing. While these libraries are commonly associated with autonomous routines, they are equally powerful during TeleOp for:

• Tracking real-time robot position
• Automating short paths
• Enabling features like auto-aim and auto-alignment

Both libraries require programming in Java, typically using Android Studio.

For TeleOp auto-aiming, it’s important to preserve your robot’s pose between Autonomous and TeleOp. Otherwise, TeleOp will start without knowing the robot’s actual location on the field. This is commonly handled using static variables to store the final Autonomous pose and reinitialize it at the start of TeleOp.

// Example pose storage between Auton and TeleOp
public class PoseStorage {
   public static Pose2d currentPose = new Pose2d(0, 0, 0);
}

Using Trigonometry to Find Distance and Angle

Once we know the robot’s current pose from our pathing library, we can use basic trigonometry to calculate both the angle and distance to the goal. The following example will use the game from the 2025-26 FTC season, titled “Decode”, the field coordinates from Pedro Pathing, and assumes that your team is on the Blue Alliance.

Understanding the Coordinate System

Pedro Pathing uses a right-hand coordinate system, which differs from the FTC SDK’s standard coordinate layout. All units are measured in inches:

• (0, 0) represents the front-left corner of the field
• (144, 144) represents the back-right corner

For a detailed explanation, refer to the Pedro Pathing coordinate system documentation.

Defining the Target

For the Blue Alliance, we can represent the target as some point within the triangular goal. For this example, we’ll use (x:10, y:138). From odometry, we’ll know the x and y position of our robot, so we can easily determine our robot’s x-offset and y-offset from the goal. As seen in the diagram below, this can be represented as a simple triangle.

From odometry, we already know the robot’s current x and y position. This allows us to calculate the horizontal and vertical offsets between the robot and the target, forming a right triangle as seen in the diagram below.

Diagram 1: Decode game field showing distance and angle to goal. Credit to Pedro Pathing Visualizer

Calculating Angle

As you may remember from Trigonometry, the “tan” function can be used to relate the angles of a right triangle to the ratio of its opposite and adjacent sides.

tan(angle) = opposite / adjacent

We can find the required angle using the inverse tangent function:

angleToTarget = atan2(yOffset, xOffset)

The atan2 function is preferred because it automatically handles quadrant corrections.

Calculating Distance

To calculate the distance to the goal, we use the Pythagorean Theorem:

distance = sqrt(xOffset² + yOffset²)

This distance can later be used to adjust shooter velocity, flywheel RPM, or launch angle.

Code Example

While auto-aiming can be implemented using Blocks, most teams pursuing odometry-based solutions will be using Java with Android Studio, as this is required for both Pedro Pathing and Road Runner.

The code snippet below uses Java and Pedro Pathing to compute distance and angle from the robot to the goal.

//Get the robot's current pose from odometry
Pose2d robotPose = drive.getPose();

//Define goal's position
double targetX = 10;
double targetY = 138;

//Calculate x/y offsets from goal
double xOffset = targetX - robotPose.getX();
double yOffset = targetY - robotPose.getY();

//Determine angle/distance to goal
double angleToTarget = Math.atan2(yOffset, xOffset);
double distanceToTarget = Math.hypot(xOffset, yOffset);

Final Thoughts

The next step in developing a complete auto-aiming system is using these calculated values to rotate your robot or turret toward the target and launch the game element with the correct speed and loft. Since shooter designs vary widely, those implementation details are beyond the scope of this article.

Vision-based auto-aiming is also a viable approach. Many teams successfully used cameras such as the Limelight 3A to track the AprilTag mounted on the goal, allowing the robot to aim and estimate distance simultaneously. Our team began the season using vision but ultimately found that odometry-based auto-aiming was faster, more responsive, and more consistent, especially during high-speed TeleOp gameplay.

Used correctly, odometry can be a powerful tool—not just for autonomous routines, but for advanced TeleOp features that give your team a competitive edge.