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

Clarifications on admittance controller for possible enhancements #1178

Open
francescodonofrio opened this issue Jun 20, 2024 · 1 comment
Open

Comments

@francescodonofrio
Copy link

Hello to everyone,
I'm opening this ticket because I'd like to contribute to this meta package by adding some features to the implementation of the admittance controller, but to do so I need some clarifications about some design's choices:

  • I'd like to know how the controller has been tested in order to reproduce such tests and I'd like to know if has been implemented a simulation in Gazebo using such controller;
  • Why the admittance rule is computed in the base frame instead of the control frame? The transformations of the stiffness matrix and of the damping matrix would be avoided, as well as the computation of the actual pose of the manipulator in the base frame;
  • Why for the computation of the admittance rule is considered the pose of the manipulator as relative to the force/torque sensor frame? Wouldn't be better to consider the pose relative to the control frame?
  • As it is now, online changes in terms of admittance's parameter like stiffness and damping, wouldn't cause an unpleasant bump in terms of manipulator's behaviour on changes?
  • In case of error from the kinematic interface while computing the admittance rule, the controller sends as command the reference joint state; wouldn't be better to send as command the current manipulator's joints state? In this way there wouldn't be the potential problem of having an uncompliant behaviour while interacting with the environment due to an error of the kinematic interface;
  • Why hasn't been implemented the possibility to send to the controller references expressed in the workspace?
  • Is there a specific reason for not considering also the hardware_interface::HW_IF_ACCELERATION as possible reference interface type?

The features that I'd like to add are:

  • The possibility to send an entire trajectory to the controller via action server;
  • The possibility to save on a bag file the state's history of the admittance controller;
  • The possibility to send to the controller desired references and trajectories expressed in the workspace;
  • Reduce the complexity of the admittance rule module (depending on the clarifications of the above questions);
  • Modify the management of the error situations (depending on the clarifications of the above questions).
@christophfroehlich
Copy link
Contributor

see #1169 for more questions about the controller and missing documentation.

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

No branches or pull requests

2 participants