Closed osrf-migration closed 9 years ago
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
I was able to reproduce this using your sample code. I have tested @hsu 's changes in pull request #85 and pull request #98, and it resolves this specific issue. We will make a new release as soon as those pull requests are merged.
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
This will be fixed by pull request #101
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Original comment by Jackie K (Bitbucket: jacquelinekay).
Original report (archived issue) by David Kluger (Bitbucket: DKluger).
Only changing one motor position using the hx_update() command causes the ring finger to hyperextend. Some sample code:
This code was adapted from the included hx_matlab_controller.m file.
After the code I provided above finishes, the API thinks the ring finger is hyperextended as well:
Note that -0.7982 is outside of the actuator minimum range of -0.7850.
While the target motor, A_wristy (the first indexed motor), works fine, the ring finger hyperextends for the entire time the code is running, and it stays in position after the code finishes. This hyperextension does not occur on any other motor. If I specifically edit the motor_pos hx_update() command structure for the 11th motor, the motor controlling ring finger flex/extension, the problem does not occur. It occurs every time I call hx_update(cmd) where the cmd.ref_pos struct does not specifically define a motor position for A_ring1.