Calibrating the Arm

In the previous posts we talked about how we applied Inverse Kinematics and kinematic analysis of the mentor arm. As mentioned the arm consists with Potentiometers and DC motors and with the POTs we get a feedback on the angle and movement direction. In this post we will be talking on calibrating the arm. 

Indeed the reading from the POTs are consistent. And we don't have a control circuit to receive accurate readings. We are passing each POT readings through a digital low pass filter so it filters out the high frequency noise. Also there is a threshold value for pot readings (+/- 10) to avoid the overshoot. 

In the mentor arm there are physical limits to avoid gears getting damaged physically. In the code we will limiting the movement of each arm respect to the limits of the leap motion and including these physical limits. Also in the using the IK formulae calculated angles, will go to infinity if the distance of the palm and the leap origin is greater than the total length of Top arm and bot arm which is 31.5cm. So if the function "jointangles"outputs "NaN" (Not a Number - infinity) we ignore them.

Inverse Kinematics on MENTOR Arm - Part 2

As mentioned in the previous post we are using IK only for 2dof (on x and y plane). By that we calculated the joint angles on the Top and Bottom arm for the given x,y,z coordinates. 

Using the conversion from cartesian coordinate system (x,y,z) to cylindrical coordinates (ρ,theta2,r) the joint angle for base arm (theta2) was calculated.

Angle - Base arm

To calculate the joint angles the function "jointAngles" is used. The x,y,z coordinates of the palm that we get from the leap motion data are passed as an array "v" into the function and theta2 - base angle, angle2 - Bottom angle and angle3 - Top angle are returned as the output. 

A Wrist-y exercise

In this post I'll be detailing the problems that we had with the wrist and integrating it with both the hardware and software.

Without a doubt, this has been one of the most time-consuming problems we've had. Let's get into some of the gory details.

In essential terms, the way that we get the arm moving is to read the potentiometer values from each joint, calculate where the arm should be based on the Leap Motion data, and continue towards that value until we get there. The potentiometers, as we found out, were continuous rotation potentiometers - this is opposed to more typical potentiometers which have maximum and minimum values that you can go. Continuous rotation potentiometers are ones where, as the name states, you can continually rotate them. These potentiometers also have a maximum and minimum point, but instead of stopping you from moving past it, it lets you!

So instead of reading from, say, 0 to 1023 and have the potentiometer physically stop it from continuing on, it just continues on and wraps around back to 0. This is problematic, because if we're at a value of 900, and need to go to 1000, there is a chance that the pot will overshoot (covered in a later post), and will go back to 0. The program will try to  correct for this by continuing the motion until it gets back to a value of 1000. However, this may mean that as it continues to move, it tries to move through itself!

This problem only occurred with the wrists. Other potentiometer values were not affected as we limited the motion so that it was in between 0 and 1023.

However, when the wrist moved up or down (roll), or twisted left or right (pitch), it was possible that it would go through 0 to 1023 or vice versa. So firstly, we had a problem of it moving through the maximum/minimum value of the pot.

Furthermore, we initially used these pots to determine our position.We could map the value of the hand position from the Leap Motion to a potentiometer value. We wanted to use this same idea with the wrists, but we hit upon another problem! When you roll or pitch your hand, the potentiometer values will change differently. What this means is that it is possible for two or more different positions to have the SAME potentiometer values!

Through a graveyard of many possibilities, we hit upon a solution. Our solution for this problem was to instead define certain regions and wrist movements that our robot arm could go to, and use the pitch and roll functions that came with the SDK/API to determine how the hand had moved. A gesture of the hand will determine whether the wrist should move as the pitch and roll characteristics (which I detailed in an earlier post) will change.

It is unfortunate that we could not get the robotic Arm to move in real-time and mirror our wrist movements exacly. It is a limitation of the Arm that we have and the set-up that we were given. However, further work may be able to work around the problem that the wrist creates for us, and an even more functional arm may result!

Inverse Kinematics on MENTOR Arm

In this article we will talk about using inverse kinematics on the Mentor arm. The purpose of this is to position the wrist position of the Mentor Arm according to the x,y,z coordinates that we get from leap motion (will be discussed in a future post). 

Figure 1: Overview of Palm position and the wrist position