Fanuc RTCP mathematics

    Hi,

    I am the developer of the robotic plugin for Rhinoceros 3D: RhinoRobot

    I have been making post processors for major brands for 10 years, including ABB, Comau, Kuka, Kawasaki, Staubli, Fanuc, UR, Motoman, etc. , each one with its own syntax and Euler angles convention.

    Today I am facing an issue on the mathematical logic behind Fanuc's RTCP:
    For almost every other brands remote TCP works in the same way as a normal TCP, the points coordinates and rotations being expressed regarding to a robot mounted frame (usually the A6 flange's frame, but could be another one on the tool itself), along with a specific syntax but with the same mathematical calculations and Euler convention used for a normal TCP of that brand.

    For Fanuc RTCP that logic is not working and the resulting trajectory is very weird.
    I have tested all the combinations of transformations and Euler conventions I can think of without good results.

    I am in contact with Fanuc France but even them don't understand the logic used behind their own RTCP mathematical logic, and they don't want to give me the contact of a Japan colleague who could help.

    If anybody here could give me a lead on the Fanuc RTCP mathematical logic, or have the contact of a Fanuc mathematician in Japan or anywhere else, it would be greatly appreciated !

    Thanks !

  • Nation July 29, 2024 at 10:14 PM

    Approved the thread.

    Hi qlab

    i doubt that Fanuc France you can help you for this specific question.

    You have tried to contact Fanuc Japan to the form on their website : https://www.fanuc.co.jp/en/contact/form/index.html ?

    You can try to contact Fanuc America too (lot of development is done over there)

    i find this : https://doc.rc-visard.com/v21.07/en/pose_format_fanuc.html but i think you have already check this link and is probably insufficient.

    I've never really dived into that math behind it, but I figured it would be an interesting challenge. It has been interesting. I've been doing some experimentation in Roboguide, and here is what I found:

    The way Fanuc represents a remote tool center point in a program is actually the inverse of the transform from the utool it is referenced to. It leads to some pretty counter intuitive behavior of the point. Changes to the XYZ portion of the point move the opposite direction of the defined utool coordinate system, and rotations also reversed, and are preformed first, with the Cartesian move applied after. This is counter to how all other local points are defined in traditional Fanuc programs.

    The RTCP point is defined like so (Matrix math notation):

    PFaceplate = PRTCP-1 * Utool

    PRTCP = PFaceplate-1 * Utool

    I've attached an excel workbook showing the math. It uses a macro to extract Euler angels out of the matrices, so you will have to enable macros to play with it. Also, the macro is not password protected, so you can look at the math.

    Thanks Nation , I will check this out.

    I think I already tested the inverse of the normal transform with good result in one direction but not so good in another, but if you have good results with your Excel calculation in Roboguide I will check that again.

    I tested so many different ways that I lost count... :wallbash:

    If you have time could you check with different orientations to see if it still behave correctly? I don't have access to Roboguide.

    Thanks for your time already :folded_hands:

    Sorry for my late reply, I am in a bit of holidays, what I meant was: did you check that the calculation you made in Excel ends up to the correct position/orientation also in Roboguide, and that for different pose with different orientations?

    Thanks

Advertising from our partners