New arm control issues

[ipa-nhg]

There are just some issues with the base limits we should fix, i.e., enforceLimits() for now removes all base commands as they apparently are not within the limits specified in the URDF - this could also be caused by the base only accepting velocities and no positions which is why this information probably is not inside the URDF? We can have a chat if you want!

[ipa-nhg]

@lokalmatador The limits are defined on the URDF, please feel free to update the values: https://github.com/squirrel-project/squirrel_common/blob/indigo_dev/robotino_description/urdf/base.urdf.xacro#L41-L43

Apart from the definition of joints and links you have also the transmission file as part of the urdf where you define the hardware interfaces. I think we have to add also there the position interfaces https://github.com/squirrel-project/squirrel_common/blob/indigo_dev/robotino_description/urdf/base.transmission.xacro#L21 , I will update it to support both of them

[ghost]

What do the limits say: Is it meters or mm? If those are the valid position limits, it is strange that the position cmds where removed with only being 0.2 or 0.3. Could this be related to effort and velocity limit set to 0?

Thanks for updating the rest.

[ipa-nhg]

the ROS conventions is for linear movement meters and for rotations radians (m/s and rad/s in case of velocities)

First of all I am not sure if ros_control uses all the parameters defined on the URDF or not and theoretically these parameters are provided by the hardware, as we don't have motors for the base joints honestly I don't know how to set them. Make more sense test the control with different values and choose the combination that better works, or what do you think? Find under this link the documentation: http://wiki.ros.org/urdf/XML/joint

[ghost]

I was hoping that we can provide sth like -1 implying there is no limit at all. We will try with different values as soon as we find the time. For now however, the controller does not check any limits. Let's discuss this today in case there is a hangout and immediately fix it.

[ipa-nhg]

If I understood correctly this will not be any more a problem for the arm control driver, the motion planner will take care of the base limits, is this right? @mzillich

[mzillich]

Both will take care of it actually. The motion planner should not plan beyond limits. But also when using the ros controll rqt gui, those limits should be met, which is what ros control does directly with enforce limits or so (right @lokalmatador ?)

[ghost]

Exactly. We need this definitely as there may be use cases where one actuates the arm by directly publishing joint values without planning in advance (e.g., Senka's handovers - which for sure a within limits but this must not always be the case...).

[ipa-nhg]

was this solved?

[ghost]

All fixed! The URDF was missing valid limits (other than zero) for the velocity and effort. Setting these to 0 most likely caused the controller to fail. Limits are now taken care of, ros_control does so by calling enforce_limits() and the controller itself by checking against the HW limits of the motors (+/-PI). Also, we found out that FESTO reporgrammed to limits on one motor (each motor has fields for min and max position limits where the limits can be changed by the Dynamixel Wizard or programmatically). What remains to be checked is whether the new arm limits we need for folding the arm inside the shell do not cause any problems for the planner (@philkark is aware of that as I personally talked to him on that - right Philipp? - and also I remember it being mentioned in another pull request/issue).

[ipa-nhg]

Perfect! :smile: