What and Why?
Back in the day, we built machines to last, think of a Toyota pickup (or any older Toyota, for that matter) or a classic ThinkPad. These companies often traded top-end performance for durability and survivability, and many of their products lasted far beyond their projected lifespans. Modern motorsports, however, take the opposite approach since top-end performance is all that matters.
During a race, track conditions can fluctuate, mechanical parts can fail and require replacement, and in endurance racing the vehicles must be refueled. All of these issues require a pit stop, which not only takes time away from racing but can also be extremely dangerous. Pit crews must be highly skilled, fast, and composed under pressure. While no fatalities have occurred, injuries are not uncommon.
This is where the Pit Stop Robot concept comes in. Certain pit-stop tasks, such as a tire change, are routine and repeatable. The goal of this robot was to simulate a small portion of the tire-change process in a time frame similar to that of a real crew. This project was completed for a robotics controls course during my master’s program. Despite earning an exemplary grade, the project did not meet the personal benchmarks I had set, giving me clear direction for improvement in future work.
Our group focused specifically on replacing the step involving removing the lug nuts, waiting for the tire to be swapped, and then replacing the lug nuts. While this introduces several engineering challenges, the course emphasized robotics controls, so we focused solely on the motion required to reach each lug-nut position and return home. If the robot could reliably reach the correct positions in two dimensions, adding a third axis would be a trivial extension.
How?
For the project, we were provided with several DYNAMIXEL MX-28AR motors and tasked with building a robot within a couple of weeks. The MX-28AR motors are extremely easy to integrate and tune out of the box, but they have an odd mounting interface that is not particularly compatible with 3D printing. We were also warned that the motors had relatively low torque and might not be suitable for a robotic arm. Nonetheless, I wanted to see how far we could push them to achieve our goal.
I was responsible for designing the mechanical system, debugging the controller code, and tuning the controller. In the end, we managed to push the motors to their limits, but we fell short of my aspiration to create a compact robotic arm.
Mechanical Design:
The objectives for the mechanical design were to ensure the structure was strong enough to survive control-system tuning, easy to manufacture on my 3D printer, and simple to mount onto the MX-28AR motors.
The initial design focused on matching the motor interface and visualizing the form of the robot. While this version lacked both strength and range of motion, it provided a starting point for mathematical modeling.
The next step was strengthening the linkages and base. Since the group member working on the control code was using a Windows machine, I decided to abandon the Raspberry Pi controller, which simplified the base substantially.
The final stage involved further increasing the range of motion and reinforcing the linkages. Unfortunately, the MX-28AR motors have a relatively small interface area, which does not provide sufficient support for the linkage and often led to failures. To address this, I created several design variations that added material around the interface to increase structural strength. Moment of area was used as a proxy to estimate the stiffness of each design. I then printed each version and tested them by applying load with a hand scale until failure, recording each test, and repeating the process several times.
To validate the results, I ran several simulations to estimate deflection and maximum stress for each design before ultimately settling on a simple extension to the interface area surrounding the MX-28AR mounting point.
Controller Design:
The original controller was designed to provide centralized control with gravity compensation and robustness. However, we encountered difficulties accurately modeling the unusually shaped linkages, which led to persistent steady-state errors during tuning. Ultimately, we shifted to a simpler PID controller combined with inverse dynamics and an integral gain. This approach allowed us to better handle modeling inaccuracies and significantly reduce steady-state error through the integral term.
Tuning:
The tuning process I followed was fairly straightforward. I began with the closest linkage, iteratively adjusting its parameters until I achieved the desired motion. Then I moved on to the next linkage, tuned it, and circled back to the previous one to refine it further. I repeated this process for all three linkages. Below is the final result of both the end effector location and intended joint angles.
While I met the course requirements, there is still a noticeable jitter in the movements and some steady-state error when the system returns to its rest position. Because we were intentionally pushing the motors to their limits, this outcome was expected, though not ideal. I have since begun developing a new version of this project, which I will share soon.
You can visit the github for this project here.