Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |
| ece4560:lynx6:06resratefull [2023/12/03 12:19] – classes | ece4560:lynx6:06resratefull [2023/12/03 12:19] (current) – classes |
|---|
| You will also need to write a function called ''Jacobian'' that computes the (linear and angular) body velocity of the end effector as a function of the $\alpha$ coordinates. For completeness, you should include all $\alpha$ coordinates in it (the last one will just have a zero column since it doesn't contribute to movement, it just opens/closes the gripper). For sure you will also reuse the ''followJointTrajectory'' function to make it happen. The script you wrote for the last homework can be recycled and modified to work for this problem. | You will also need to write a function called ''Jacobian'' that computes the (linear and angular) body velocity of the end effector as a function of the $\alpha$ coordinates. For completeness, you should include all $\alpha$ coordinates in it (the last one will just have a zero column since it doesn't contribute to movement, it just opens/closes the gripper). For sure you will also reuse the ''followJointTrajectory'' function to make it happen. The script you wrote for the last homework can be recycled and modified to work for this problem. |
| |
| //Note:// Probably you will notice we are in the kinematically insufficient case, for which I said one should never try to do the psuedo-inverse since it will be wrong always. That is the case here, regarding being wrong. Probably I should just be doing resolved rate trajectory generation with the end-effect position and ignoring the orientation as for the [[ece4560:lynx6:05resratepos | previous implementation]] , or making sure that my desired trajectory is legit. For the sake of this problem, let's just ignore this untidy fact and pretend it's all good. | //Note:// Probably you will notice we are in the kinematically insufficient case, for which I said one should never try to do the psuedo-inverse since it will be wrong always. That is the case here, regarding being wrong. Probably I should just be doing resolved rate trajectory generation with the end-effect position and ignoring the orientation as for the [[ece4560:lynx6:05resratepos | previous resolved rate implementation]], or making sure that my desired trajectory is legit. For the sake of this problem, let's just ignore this untidy fact and pretend it's all good. |
| |
| === Deliverables === | === Deliverables === |
