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

Add position feedback to BCC::twist #185

Closed
PeterBowman opened this issue Jan 18, 2020 · 4 comments
Closed

Add position feedback to BCC::twist #185

PeterBowman opened this issue Jan 18, 2020 · 4 comments

Comments

@PeterBowman
Copy link
Member

BasicCartesianControl::twist performs open-loop velocity control, which is unsufficient if a steady, linear path is desired. Any attempts to control TEO's arms via joystick (#173 (comment)) will cause said arm to bend due to gravity.

So, I'd like to add position feedback in the twist command in case it renders beneficial.

@PeterBowman
Copy link
Member Author

PeterBowman commented Jan 18, 2020

Besides, ICartesianControl::pose might no longer make sense, anymore, as movi is now the preferred way to accept position-based targets.

@PeterBowman
Copy link
Member Author

PeterBowman commented Jan 18, 2020

Proposed control scheme:

  • Input 1: desired instantaneous cartesian velocity.
  • Input 2: expected pose (cartesian position) on the previous twist command.
  • Input 3 (feedback): current cartesian pose.

Similarly to movl, we combine inputs 2 and 3 in an integral control scheme (differentiate input2-input3 and apply gain). Then, add input 1 and perform differential IK to obtain joint velocities.

Every step needs to store the expected pose (input 2 of the next iteration) resulting from input 1, expressed in terms of infinitesimal distance, added to input 3.

Tested at 8d8dca0, not working as expected. Alternative solution is even worse: dddd23e.

@jgvictores
Copy link
Member

Tested at 8d8dca0, not working as expected. Alternative solution is even worse: dddd23e.

That's a pity. The proposed control scheme LGTM.

@PeterBowman
Copy link
Member Author

Not doing. This has been superseded by CSV mode (roboticslab-uc3m/yarp-devices#221). Also, the reason why the arm was bending down could've been that the default IVelocityControl implementation (i.e. "velocity profile" at the firmware level instead of CSP/CSV) accelerates/decelerates prior to reaching each velocity reference. It is of course best to apply instantaneous velocities as in CSV mode, which will probably become the new default.

Cf. the ftCompensation app in which CSV is also the preferred method: #191.

@PeterBowman PeterBowman closed this as not planned Won't fix, can't repro, duplicate, stale Feb 15, 2023
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

2 participants