Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use MoveIt! instead of NaoQi for motion control #1

Open
dhood opened this issue Sep 9, 2014 · 0 comments
Open

Use MoveIt! instead of NaoQi for motion control #1

dhood opened this issue Sep 9, 2014 · 0 comments

Comments

@dhood
Copy link
Contributor

dhood commented Sep 9, 2014

NaoQi is being used for the motion control of the robot, which offers the benefit of easy whole body motion control. It also allows you to free specific degrees of freedom in the motion planning, although MoveIt! can in theory do this as well, although using both "position_only_ik" and approximate IK didn't work the last time it was attempted. The disadvantages of using NaoQi, however, are that the motion planning is with respect to the wrist of the robot instead of its fingertip as required, and the degrees of freedom are only able to be specified with respect to three robot frames, but to be truly useful it should be with respect to the wrist frame. As such, use of MoveIt! should be further investigated if better accuracy for the position of the fingertip is required.

Some other NaoQi behaviour that it would be nice to get rid of is that the positionInterpolation command doesn't seem to respect the requested timings reliably (the more points requested the less accurate it is), and sometimes behaves strangely: if you give it 3 seconds to reach the first point, it seems to wait until the time is almost elapsed and then try to get to the point, arriving late... Perhaps adding some intermediate points for the robot to lift its arm smoothly is necessary, or maybe not using positionInterpolation. Also, the motion planning sometimes has visible 'overshoot' - between two letters in the centre of the tablet, for example, the robot might point at the bottom of the tablet rather than remaining at roughly centre-height the whole time as expected. It's possible that this overshoot is also sometimes responsible for making the robot fall while executing its trajectories.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant