# Robotic Arm Inverse Kinematic Algorithm

I have currently built a large 6 axis Robotic arm that uses a bunch of potentiometers to control the angles. I would like to move into Autonomous control of the robotic arm. I would like to tell the arm "Hey, move to this position" and it figures out the angles of all the joints (or the "pose") needed to reach that position. Here is my current plan:

I would like to generate a table of data. This table will essentially contain every position that the robot arm can take in a sphere. It will also contain a matrix which holds the angles each joint needs to have to reach this position. I would like to generate this table using forward kinematics. Essentially, I will input a matrix of angles, see which position the robot arm ends up in, and then store that result. Once data has been gathered for every possible position, my dataset is complete.

With this dataset, all the robot arm has to do is look up the end position given to it, and then read the angles off of it. This makes it very easy to solve the inverse kinematics problems. All the angles were already generated through forward kinematics, and now the robot arm is just reading off the values form the table.

My question now is: How do I generate this dataset? My robot arm has custom arm lengths, and custom angle constraint for each of the joints. I'm assuming MATLAB would be a useful tool for this? I want to generate the dataset autonomously, and just have it in a .CSV file if possible.

I have the idea, but not sure about how to implement. Any guiding lights would be appreciated. The dataset generation would require so much computational power, so not sure if it is even possible to generate this file.

• I have done kinematics (optimising four bar link motions such as James Watt's and Chebyshev's, admittedly steam era rather than robotics) in a spreadsheet! Principle would be the same, use whatever tool you prefer.
– user_1818839
Nov 14, 2021 at 20:27

You've got six axes, and you're using potentiometers, so analog outputs there, but let's assume you're reading them with an 8-bit encoder, which is really not enough resolution to do anything precisely. If a joint has 360 degrees of motion, you're reading that into an encoder that can do 255 increments, and you get about 1.41 degrees per count.

Anyways, as unreasonably low-resolution as that is, going your proposed route you would:

1. Set the first five axes to zero,
2. Run the sixth joint through 256 positions, then
3. Increment the fifth joint by one, then
4. Run the sixth joint through 256 positions, then
5. Keep going until the fifth joint has run through 256 positions, then
6. Increment the fourth joint by one, etc.

You wind up with the sixth joint doing 256 positions for each of the 256 positions in the fifth, etc.

Assuming each joint is using 8-bit encoders, then you want:

(first)*(second)*(third)*(fourth)*(fifth)*(sixth)
(256)  *(256)   *(256)  *(256)   *(256)  *(256)
= (2^8)*(2^8)   *(2^8)  *(2^8)   *(2^8)  *(2^8)
= (2^(8*6)) = 2^48


You're saying you want 2^(48) individual combinations, which is 281,474,976,710,656 possible combinations. That's just the number of combinations, too, not the actual amount of data you'd need.

You could use something like a uint64_t to index into that data, and just use each byte as a new axis and ignore the upper two bytes, but now you need six arrays, one each for x/y/z and roll/pitch/yaw. If your output positions for a particular pose were also given as byte resolutions, then you'd need at a minimum 6*(2^48) or over a petabyte of storage for all your possible output poses.

Now, because you can't hold a petabyte of data in memory at once, you'll need to scan (stream) through your file until you get a match.

Can it be done? Yeah technically I guess, but it's going to be super impractical. This is also assuming that you're only going for 8-bit resolution on the joints; anything higher will have a tremendous impact on the space requirements. 10-bit encoders would have 2^60 combinations, which is more than 1,000,000,000,000,000,000.

• Chuck answered the specifically asked question, "How do I generate this dataset?" I detected no hint of sarcasm or snark, yet the conclusion is clear: "It can't work to do it that way." I hope Marko will read the Inverse Kinematics article on Wikipedia, and also check other postings on Robotics SE at robotics.stackexchange.com/questions/tagged/inverse-kinematics. Other methods of doing IK, although harder to understand than table lookup, actually work well enough to use. Nov 16, 2021 at 19:17
• @r-bryan - yeah thanks. Not intending to be snarky or sarcastic at all, just trying to work out what it would actually mean to implement the concept described in the question as OP asked how to start it, so my answer here is intended to help walk OP through how to get things setup. It's totally doable, too, just really impractical.
– Chuck
Nov 16, 2021 at 20:27