You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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:
The features that I'd like to add are:
The text was updated successfully, but these errors were encountered: