“The FIRST Robotics Competition (FRC) is an international high school robotics competition. Each year, teams of high school students, coaches, and mentors work during a six-week period to build robots capable of competing in that year’s game that weigh up to 125 pounds (57 kg). Robots complete tasks such as scoring balls into goals, placing inner tubes onto racks, hanging on bars, and balancing robots on balance beams. The game, along with the required set of tasks, changes annually” (“FIRST Robotics Competition.” Wikipedia, Wikimedia Foundation, 14 May. 2020. https://en.wikipedia.org/wiki/FIRST_Robotics_Competition).
As a high school student, I joined my school’s FRC team. We had several months to learn and practice before FRC revealed the tasks that we had to build a robot to complete.
I was assigned a robot from a previous year to practice robot-programming.
Guitar Controller
At that point the team had been using flight sticks to control our robots and I wanted to experiment, so I brought a guitar shaped controller from popular music rhythm game Rock Band into the workshop to experiment with.
By mapping out the inputs and modifying the controls code of the robot, I was able to reference those controls in the code and let the operator control the robot to drive forwards, backwards, and turn using the buttons on the guitar.
Here’s a link to a post made by the FRC team’s media group about the guitar controller.
The Robot
The task for the 2014 year was to build a robot that could pick up and launch a large exercise ball into the air.
The team built a robot that mainly consisted of a 6-wheeled chassis, a large arm , and an impeller-based vacuum system embedded in the arm.
The robot would spin up the impeller and create a vacuum that was piped to a large bowl on the end of the arm. When the ball was pressed against the bowl, it would be held onto the end of the arm. This could be released by halting the impeller and opening the vacuum chamber to allow for a quick pressure change.
The robot would throw the ball by holding onto the ball and swinging it’s arm. During the swing, the robot would release the ball.
I was responsible for controlling the movement of the arm. It was driven by two motors and had a potentiometer sensor for feedback on it’s angular position. The arm had a range of motion of slightly more than 180° and could reach out in front of the robot, directly upwards, and behind the robot.
Detecting the Angle of the Arm
The first step was to reliably detect the current angle of the arm. The potentiometer gave a value back based on the angle of the arm. For this robot I remember the resulting values ranged from about 1.X to 3.X. A linear scaling was applied to the potentiometer value to get an angle in degrees, then that angle was shifted to be more intuitive for an observer.
At the time I chose an angle scheme that was very unintuitive, which I blame on a lack of experience. If I were to make this today I would design this system to be at 0° vertically, +90° horizontally in front of the robot, -90° horizontally behind.
There were enough differences in the physical characteristics between potentiometers that swapping out these sensors would require us to redo some of the math for our angle calculations and re-program the robot. This didn’t happen often, so it was an accepted inefficiency in this robot. If I worked on this project today I would handle this sensor differently to account for this issue.
One solution that avoids this problem would have been to replace the potentiometer with an Inertial Measurement Unit (IMU) mounted on the arm. We would be calculating an angle based on the inertial measurements of angular velocity and force due to gravity. Since we are relying our measurements on external forces, small differences in physical characteristics would not affect the system.
Moving the Arm
At any point in time the robot would have the arm’s current angle and a target angle based on user input or progression through an autonomous routine. From this knowledge I constructed a Proportional-Integral-Derivative (P.I.D.) closed-loop control system to control the movement of the arm based on the difference between the current angle and the target angle.
The problem with the above control system was that external force did not act on the arm in a linear fashion. Due to the movement pattern of the arm, rotating around an axis that is parallel to the ground, gravity would act on the arm at a maximum when the arm was parallel to the ground, and would apply no torque to the arm when pointing upwards.
Because of this, a standard P.I.D. control system optimized for one angle would not be optimal for another.
The solution to this was to have a trigonometric equation to calculate the torque of the arm due to gravity at the current angle, and with that, I could control the motor to have no rotational movement at that angle. By adding the results of the closed-loop system onto that, any error would result in a quick correction despite gravity.
I have another post about the guitar controller I worked with during the time I spent with this robot. Check it out.
