Image

Introduction:

This week we were tasked with using our already constructed robotic arm to demonstrate inverse kinematics. More specifically, we had the following three objectives. First, we had to modify our code from the week prior so that it could generate both the expected end effector positions and the corresponding motor positions for that point, allowing us to compare actual motor positions to calculated motor positions. Second, we needed to develop code that could pass an end effector position to the robot and have the robot move the arm to that position. Finally, our bonus challenge was to use an alternative input method to pass the position array to the robot.

The Robot:

This week’s assignment lends itself perfectly to last week’s robot (intentionally, we assume), thus we made no changes to our robot.

Part 1:

Part 1 was fairly simple given the equations needed were given to us. With just a few tweaks to last week’s code, we were able to get our robot to record various motor positions (moved through manual manipulation), calculate the corresponding end effector positions, and then use the inverse kinematics equation to calculate motor positions. We then compared those calculated motor positions to the recorded motor positions to assess our error.

We found in part 1 that the calculated motor positions were accurate to +/- 0.5, which is likely attributable to wiggle room in the motors.

Part 2:

Part 2 did not involve too much additional code, simply adding in a command to run the motors to the positions specified by the code. The robot was constrained to run in only the right two quadrants of the coordinate plane, with the positive x-axis defined as the arm’s starting position. We found that the robot was only able to achieve certain positions within its range of motion. In some cases, the robot could not move to a specified position, but changing that position by 1cm would fix the problem. In other cases, we were able to compensate for a seemingly unattainable position by hard coding a change in the sign of the alpha/beta angles, however in these cases this change had no affect. We are still unsure what caused this problem.

Ultimately, we were able to make our robotic arm play back a series of input positions with 1-2cm error, which is easily attributed to wiggle room in the motors.

Part 3:

Part 3 was a bonus challenge that stipulated an alternate method of input must be used to generate an array of end effector positions with which to drive the robotic arm. To accomplish this, we created a simple interactive grid in Matlab, the limits of which matched the numerical limits on our physical axes. To add a point to the array, we simply clicked somewhere on the grid, and the new point was automatically appended to a set of arrays, which we transferred into the robot code through copy/paste.

Conclusion:

Overall, this project was relatively successful. When the arm worked, it worked beautifully, exhibiting minimal error. However, the few positions we attempted that the robot was incapable of achieving were quite frustrating, and we remain perplexed as to what caused this error.

Video