I’m currently working on a chess playing robot using an AL5D arm. I implemented x,y,z-coordinate conversion with different inverse kinematic approaches. However, with all of them I have the same problem. The gripper is not holding constant height. Near the base the gripper is higher, further away it is lower than it should be. The difference is more than 5 cm. I plotted the inverse kinematic solutions and in theory they are all correct.
I found a similar post on this forum. The problem there was the non-linearity of the servos. So I mapped the servo pulse widths every 5 degrees which however showed a quite linear dependency between the pulse width and angle (at least without load), so I think this cannot be the problem.
I noticed that there is some variation of the height further away from the base due to the flexibility of the arm and dead band of the servos under load. But it is still smaller than the error I am observing.
If this doesn’t work, I will have to hard code the servo angles for every chess field, which is quite an effort and doesn’t allow any changes in the setup…
Does anyone have an idea what the problem could be?
A drop under load at longer reach is completely normal. Of course, if it is that much (5+ cm), then it would see your inverse kinematics is doing something not entirely right.
As you mentioned in your post, the drop under load (we’ve tried ~150 g) at full reach (horizontal extension) was nowhere near 5 cm.
Therefore, it would seem your code is not providing the position you expect it is.
The best here would be to monitor the positions send to the robotic arm’s controller by your code. Check what values are being sent a various problematic positions and see if they match what you expect to be sent.
Something that may help with your situation is added a calibration process during initialization, where you place the robotic arm’s gripper in various positions that would otherwise be problematic if not accounted for (maybe some or all 4 corners, and extrapolate adjustments required from there?).
Without more information about your setup, code, etc. it is quite difficult to offer anything else than generic advice.
I did all the calculations in MATLAB and sent the respective pulse widths via the Servo Sequencer Utility manually to avoid damage to the arm. Unfortunately, I am not able to post the code here due to some strange internal server error here on the forum. But as I already wrote I tried several different approaches including the Python example from the Lynxmotion Github page with hardly any difference.
Although I haven’t really found the source of the problem, I have worked out a solution. I did a manual correction of the angles on a fixed height every 5 cm step from the base and plotted the errors. With this information I was able to do an error approximation and correction after calculation which seems to be accurate enough.
Please note the basic 2D IK example (in both the C and Python code) does not allow certain angles for the wrist and would therefore have a behavior that matches what you have described.
For something like chess play, we recommend that you use a full 3D IK system with proper position of all motors, including the wrist.
Currently we officially only have these two examples in Python, which one of them includes a (very) basic 2D IK example. That being said, there are many 3D options already available, so it shouldn’t be too difficult to use an existing library (ex: something like this) and use the example code as a starting point on how to send positions to the various joint of the AL5D.
We are planning to release something in the near future as this question keeps coming up regularly more and more. Just “watch” the GitHub repository to see updates.
Sincerely,
Note: You can skip much of the complexity of full 3D IK by simply figuring out the base angle required to reach your target position (straight line from base to position) and then using the 2D IK example to figure out joint positions. This should be more than enough to achieve proper positioning. This is possible since the arm itself is entirely on a 2D plane (ignoring the base rotation).
