songjunyi
commented
8 years ago Hi, Dave, Thanks for finding this problem. This is because we did not set a real-time inverse kinematics calculation for uarm. So it will calculate the trajectory in the beginning and some solutions may not be right (for solution selection)- especially in the boundary.. We are trying to make it right ASAP.
dcorboy
Based on some testing of the positions resulting from the calculations, movement is somewhat rough and uneven, sometimes moving several centimeters within only 1-2 frames: https://s3.amazonaws.com/corboy-images/result6.png https://s3.amazonaws.com/corboy-images/result7.png
I imagine this is likely due to some issues with the float conversions to integer and unrelated to the constraints or offsets?
However, I want to bring to your attention an extreme case of position error that I have found in using the uArm. In the test below moving from (5, -17, 10) to (0, -24, 10), you can see a very pronounced "snap" effect where the arm moves >8cm in a single frame: https://s3.amazonaws.com/corboy-images/result9.png
When this happens, the effect is very startling, causing the uArm to jump on the table and the resulting position is quite incorrect. :)
The cause of this appears to be in the calAngles function:
While the result of calAngles(0, -24, 10) is Rot: 90 Left: 43.7 Right: 45.82
The result of calAngles(0.1, -23.99, 10) is Rot: 90.1 Left: 136.57 Right: 45.55
Then, the result of calAngles(0.2, -23.97, 10) is Rot: 90.6 Left: 43.71 Right: 45.83
I am not a very good algorithms guy so I hope you fellows can find the source of these results. :)
Dave