add rounding to 5 decimal places to command sending to prevent H0117 …

[wolfv]

…error

As the comment indicates, and as mentioned in a private message to @7675t we've encountered a H0117 on hardware CR800-D with RV-4FRL-D

The cause seem to have been small oscillations around 0 in joints 4, 5, and 6.

Rounding the command that is sent to the robot to 5 decimal places fixes this issue for us.

Are you fine with this fix?

Best,

Wolf

[7675t]

Good move, but I'm not quite sure why this could happen. The controller node just send constant command value so no oscillation should be there.
Could you check the following points?

• When you get error, can you observe the commanded joint angles are oscillating on the pendant?
• Have you experienced same error when you move to exactly same posture by the teaching pendant?

I slightly doubted the problem came from PID control gain of the joints, which could make oscillation at particular posture.

[7675t]

Or, it just comes to my mind, the angle range of J3 is from zero to 160 deg.
Even very small, negative J3 command angle might cause some failures.
But you mentioned it is on J4,J5,J6 so it might be not related.
Anyway I want to know the reason of this issue.

[7675t]

Could you make this adding r3 driver as an independent PR?

[wolfv]

yes definitely! I just pushed to the wrong branch, sorry.

[wolfv]

I've reverted adding the R3 stuff here.

[wolfv]

Regarding the issue:

I could reproduce it doing the following:
given that some joint values are zero, do

• restart control
• do nothing
• it will appear after some time (and printing joint states shows some movement)

I don't know the exact cause but I believe that maybe somewhere is a division by zero or some number becomes NaN because the movement is too small...

[7675t]

Yesterday's our investigation shows:

• The command angle are not oscillating
• The joint state angles are oscillating with very small amplitude
• Your patch, rounding the command angle, make the joint state angles stable (never oscillating)

My latest guess is, the command angle smaller than the resolution of the encoder may cause this problem. As you know, the encoder represent the joint angle with discrete value (i.e. pulse), so the commanded joint angle under the resolution is never realized by servo system. Usually the servo controller should convert the command value (angle in rad.) into encoder pulse before compute the motor current reference, but somehow this controller seems not to do so. I have no idea why this oscillation cause the brake error though.

In case my guess is right, your patch is reasonable, because it makes the command angle larger than the encoder resolution.

I will check my hypothesis with RT Toolbox, and inquire the vendor if possible. Please wait for a while.

[wolfv]

Hi, thanks for looking into this. Hopefully you can find more informations.

It's not very urgent for us + we have the patch.

[7675t]

Unfortunately I was not able to reproduce the oscillation with RT Toolbox (simulator) 😞
I posted a question via MELFA support website, so let's see the answer.

@wolfv
If you can make the code in this PR as controlled by rosparam (parameter something like round_commnad_angle as boolean and default can be true), I think I can merge this before we know the mechanism of the problem.

[7675t]

I asked MELFA's support about this problem. Their answer is

• H0117 error should be nothing with external control
• They can't find the reason of this error
• They doubted it is hardware problem
• Please check if same error happens without external control
• If you can send then the log data which cause the error, they can investigate on it

I'm not sure you are still involved this, so I think I should merge this feature with rosparam 'round_command_angle' and setting default false.

[wolfv]

Hi Ryosuke-san,
yes, feel free to merge. Your changes look good to me!

Sorry to keep you waiting for so long, I was busy finishing this project and then immediately another one.