First set of proposed msgs for setting up Cartesian Impedance parameters #1
Conversation
…eing implemented and tested.
| # [N/m] | ||
| geometry_msgs/Vector3 translational | ||
| # [Nm/rad] | ||
| geometry_msgs/Vector3 rotational |
There was a problem hiding this comment.
In this context, what does rotational damping mean? I assume it's dampening about the fixed frame axes? Is there any confusion/issues like those associated with euler angles (i.e. order of application)?
There was a problem hiding this comment.
Yes you are right Shaun. Is dampening about the fixed frame axes. These values are usually consistent and each value during the motion is constant, so there are no singularities that come with Euler angles actually these are just constants which are used to define the properties of the Spring when the robot is in Cartesian Impedance Mode.
|
General comments:
|
|
|
||
| # Real robot tests are performed on the KUKA IIWA 7 R800: | ||
|
|
||
| The ROS robot model is taken from [iiwa_stack](https://github.com/SalvoVirga/iiwa_stack) |
There was a problem hiding this comment.
Minor (as this pkg is meant to be as generic as possible): it'd be nice if we can use kuka_experimental for this. I know we don't support the 7 R800 at the moment, but that is fixable.
There was a problem hiding this comment.
@gavanderhoorn any good model for the 7 R800 that you know about and satisfies ROS-I conventions or we need to modify some existing ones to meet the naming conventions requirements?
There was a problem hiding this comment.
We could adapt the 14 R820, or we could import the one from iiwa_stack, and then update it. I'm fine with either. Not sure which one is less work (haven't looked at the iiwa_stack one recently).
There was a problem hiding this comment.
I can take a look at this and see which one would be more straightforward to adopt. I'll then can make a pull request to the kuka_experimental
There was a problem hiding this comment.
Whatever you do: make sure to get proper permission / ask the authors. Depending on the license it may not be really required, but I feel it's always a good thing to do.
There was a problem hiding this comment.
Just remembered there is ros-industrial/kuka_experimental#31 open against kuka_experimental which adds the 7 R800. There are some things to fix, but perhaps that could also be a starting point.
|
Thank you so much for your suggestions @shaun-edwards and @gavanderhoorn. Just one general question regarding the definition of the damping parameters. For the KUKA they are unitless ( Lehr’s damping ratio). I suggest to go with this now and explicitly state this in the explanation of the message. If you have better idea how we can handle unitless msg let me know :) |
|
Unit-less damping ratio seems OK with me. Would the damping be limited 0-1 or is it possible to have an over-damped (>1) situation? |
|
Thank you @shaun-edwards . The damping ratio is set to be between the values: 0.1 - 1. In case of the iiwa is not allowed to be 0 nor to be >1 |
|
@rkojcev: do you have any examples of other robots that support setting damping in this way? What units (if any) do they use? What other methods exist, and how do they specify damping parameters? I just want to avoid modelling all of this on the way KUKA does things. |
|
Also: general comment: I'd not put URLs in the comments of the messages, it seems redundant. Locally users can just do a Besides being redundant, it's also adds maintenance overhead: you/we now have to make sure the links keep working. |
|
@gavanderhoorn I only have access to the kuka iiwa and kuka lbr 4+. However in the literature, even though most of the publications are from DLR regarding this topic, there are some publications that use custom-made robots and they use Ns/m. It would be a good idea to reach to other people who use Cartesian Impedance on industrial robots and maybe we could get some input from them on this matter. It might be also good idea to make 2 types of damping messages, one could be called damping_ratio and will use unitless values (same as the ones KUKA is using) and other called just damping which will use Ns/m. |
That would be a very good idea. |
|
Question after an internal review here:
|
|
@gavanderhoorn here things get interesting. Once you set this values for the tool then the robot will know how to adjust its motor torques taking into account the new tool properties. Then when you set all the Cartesian Impedance parameters the new tool is taken into account. From the user perspective the values he is setting for the Impedance Control do not have to be changed if you add a new tool, what is important is to properly define all the parameters of the tool to have desired Cartesian Impedance Motion, otherwise the robot might not behave as desired, and the spring properties of the Cartesian Impedance will not be correct. This leads to bad Force Control for example. In KUKA LBR4+ you are only able to set these parameters directly on the controller. On the iiwa you are able to send this parameters via messages. Usually these robots offer possibility to determine all of these properties via tool calibration steps directly on the controller and this is the desired procedure to do this. In my plan I am also envisioning to have this set of messages for setting the tool properties as well. :) We can offer this possibility to the user to set the tool properties via messages even though I do not recommend it. If it was up to me I would go trough the painful calibration when adding new tool. In my experience the robot has better behavior if the tool is calibrated internally on the controller. At least that was the case for the KUKAs. |
|
@gavanderhoorn and @shaun-edwards I have addressed all of your comments. Should we make a new PR or you can check the changes in this one? |
|
So do I understand you correctly that you say that it doesn't make sense to include any reference frame because it is always relative to the currently defined / calibrated tool? I think the question I relayed was more about "in what frame are these damping parameters defined" (obviously not for null-space). |
|
Yes exactly @gavanderhoorn Sorry for the long answer. I just wanted to elaborate little bit more on the differences when doing Cartesian Impedance Control |
|
Related to @gavanderhoorn's question. The rotational/translational elements are specified with respect to a particular frame. Assuming the tool frame? Should this message set make that assumption, or should we name the frame in which these elements are represented? If we name the frame, can we avoid the "tool setting" message set (i.e. the driver will set the tool if the message it receives specifies a different frame)? |
|
Sorry about my long answers.
Yes that is correct.
In my opinion it has to make this assumption. Every time we set the robot into Cartesian Impedance a set of commands is loaded. The most important one is verifying the tool mass and center of mass. This usually happens before you can call set Cartesian Impedance Parameters and is when the robot is initialized. While the controller allows changing Cartesian Impedance parameters interactively I have never tried changing tool interactively (I am not sure this is feasible) but its worth trying. Let us assume we go with the option where we name the frame in the msgs. Then on the controller side we have to look for all the calibrated frames, that are usually stored on the controller and see if any of them matches the one in the send msgs, once match is found we have to call the robot internal tool verification, and handle errors. As I mentioned I would not recommend setting tool mass properties directly unless I have very good mechanical model of the tool where I have made all the necessary calculations of its properties and still in my experience that one is more prone to failure compared to the one where I calibrate the tool internally on the robot controller. I would like to try this out and see what is practically feasible :) Sending and setting frame directly from the message would be a better idea compared to making new set of messages for loading the tool. |
|
What you describe seems based on your experience with KUKA robots (which is fine!). While it is true that there are not many others that expose impedance controls, I feel it makes more sense to design this set of msgs for an abstract, 'ideal' and yet to be constructed robot. That way we at least try as much as possible to avoid (implicitly) encoding assumptions into the messages based on how KUKA does things. I'd like to see the frame made explicit for two reasons:
|
|
@rkojcev wrote:
While I understand what you're trying to say, I don't think this is something that should influence our decision on whether or not to include something in the messages. It would be the users responsibility to make sure that the messages are used properly. A |
I definitely agree on this one. We should not constrain our design on any particular hardware.
Yes, it needs to update all the necessary parameters. Changing tool interactively under Cartesian Impedance is something that I would like to try it out and see how the robot behaves. Then I can open an issue here where we can think of possible outcome if it supports or does not.
I also agree on this one. Checks need to be performed in any way. I agree with you @gavanderhoorn on your points raised here. I know that for now I am testing everything on the iiwa and I might be biased in some of the arguments I am raising, but definitely having feedback from everyone will help us design a general msgs which could be used in any present or future hardware. In general, I also think we should add frame to the msgs and I also would like to try out interactively changing the frame. I think this feature will be quite useful to have. |
…al info for the null space stiffness.
…ting damping values.
| NullSpace null_space_params | ||
| string tool | ||
| CartesianStiffness stiffness | ||
| #use this if the damping is in Ns/m, Ns/rad |
There was a problem hiding this comment.
How does the receiving node know which type of Cartesian stiffness is used?
There was a problem hiding this comment.
Do you mean Cartesian Damping type?
For now the only difference is in the naming, and is up to the user to decide which one to choose. In fact there is not even difference of the variable definition.
Do you have any suggestions how we can differentiate this better, or we could just leave one msg type called damping and let the user either input ratio or Ns/m for the damping parameters. Having two types of damping msgs can be confusing and prone to errors
There was a problem hiding this comment.
Yes, I meant dampening.
From a usability perspective, any publisher and any subscriber should be able to talk and the semantic intent of the message should be clear. In other words, the messages sent should always mean the same thing regardless of who is producing/consuming it.
I think you should pick convention and then make sure subscribers can translate that convention into whatever is expected by the controller. For example, if you pick Ns/m, then the drive node for the iiwa will require a critical dampening parameter(s) in order to translate into a unit-less dampening. While this may seem like it makes the driver more complex, it does so for the sake of usability and consistent semantics.
There was a problem hiding this comment.
If I may make a suggestion, I think the choice for either ratio or Ns/m is something we should get as much input on as possible.
I've talked to multiple people internally (control engineers, mechanical engineers, ..) and have heard passionate arguments for and against both options. Some find ratios much more intuitive, others dislike the relativeness of them. Ns/m is regarded as difficult, and not as 'platform independent' (ie: 0.5 is always 0.5, but the effect of 1.0 Ns/m isn't immediately clear), even though it is something that actually has a unit (and is not a dimensionless nr, so is less ambiguous / depending on context).
Personally I agree with @shaun-edwards (and I think I've said it before), in that any message should be unambiguously interpretable. Making the semantics of fields dependent on implicit or invisible assumptions / knowledge seems like a bad idea.
There was a problem hiding this comment.
I also agree with @gavanderhoorn that we should definitely find consensus whether we should use ratio's or Ns/m, I think that this should highly depend on the units majority of the robots use as well. I am also looking at how to convert from Ns/m to ratios for example and it seems it is not very straight forward thing to do...
Maybe if we can get input from others who have robots who use Cartesian Impedance and the units they use would be great.
|
closing this and opening new pull request with the changed msg after discussion above. |
No description provided.