Added postprocessor for Fanuc robots (LS Format)

[AngelLM]

This pull request adds a postprocessor for Fanuc robots.

I tried to follow the same code structure as the rest of the existing robots, but Fanuc robots have their peculiarities and I had to do some free styling on this:

• How joints angles are calculated: Fanuc robots measure the angle of the third joint with respect to the ground and not with respect to the second joint.
• The declaration and calling of variables. Fanuc directly uses memory registers. For the sake of simplicity I have avoided their use and instead have chosen to enter the value directly into functions such as SetAO and Wait.
• Joint type motions of Fanuc robots use a % of the maximum speed at which they can move instead of a value expressed in mm/s. Although it doesn't seem quite right to me, I have used the value of the Target component's speed input as a percentage. I don't think this is the best way to do it because in the component description it says that the units are in "mm/s" but I couldn't think of a better way to do it.
• The robot configurations are also somewhat problematic. I think I've found a way to relate them correctly, but I'm not 100% sure about it.
• Finally, Fanuc robots don't have the World coordinate frame at the bottom of the robot. Instead they have it positioned on the rotation axis of the first joint at the height of the rotation axis of the second joint (see image) . This means that when working with Fanuc robots you have to create a Base Plane for the Load Robot component and position it at the height of the axis of the second joint.

The generated LS code has been tested on a real robot (M-20iB/35S with R-30iB Plus controller) to check that it works correctly.

[AngelLM]

I haven't said anything about the World coordinate base. Reviewing the Fanuc XML file before making the Pull Request to the libraries branch I have seen that you can define the World base there, so it isn't necessary to add it in grasshopper.

[visose]

Hola Angel,

Nice work, it must have been a bit of a pain to understand the spaghetti code required to add a new manufacturer.

This plugin tries to stick to the same conventions regardless of robot manufacturer and I think some of the peculiarities you mention can be addressed. I'd like to request if you could make these changes before merging:

• The base of the robot should be placed at the origin instead of the 3rd axis. You could do this by a combination of changing the DH parameters in the XML (adding the distance to the 3rd axis) and transforming the targets in the post-processor to counteract this. Staubli had the same issue, you can check how it was handled.

• The speed for joint motions should be mm/s rather than percent. You can check how this was handled in KUKA. The plugin calculates for you the time it takes for a particular motion at the programmed speed in mm/s (excluding accel) and also calculates the minimum time it could take given the joint speed limits. If you divide these you get the percentage value that you need. The plugin calculates the time as if it was a linear motion, so it's an approximation for joint motions, since the the TCP would not move in a straight line and world speed would vary along the path (this is based on what ABB does).

• The Rhino file is 35MB, you can get it to ~1.7MB by purging the document (_purge command in Rhino), it contains some block definitions that are not used. You can also merge vertices using the _weld in places with no sharp angles.

[AngelLM]

Hello!

The truth is that at first I was a bit overwhelmed because it had been a long time since I worked with C#, but the way you have everything structured has helped me a lot to understand how the addon works!

Back to the changes:

• Regarding the robot base issue, I saw that in the .3dm model of the Staubli, they are offset on the Z axis to compensate for the height of the base, so I did the same with the Fanuc models and changed in the XML the distance values. I tested it and it works, so I guess that's what you were telling me to do.
• I changed the way the velocity of the joint movements is calculated. I did it based on the KRL and UR postprocessing code. But I have a doubt regarding this. When the DeltaTime is 0, there is a constant variable called maxTranslationSpeed with a value of 1000, which is used to calculate the percentage of the maximum articular speed of the robot. Why this value is 1000? Should I adapt it to the maximum speed of each robot? I am afraid I have not done it correctly at this point.
• Finally, I applied the purge and weld operations you told me about and I have reduced the file to 1.82MB. I didn't know about those operations (I have been using Rhino for a short time to be honest), thank you very much for pointing them out!

[visose]

When the DeltaTime is 0, there is a constant variable called maxTranslationSpeed with a value of 1000, which is used to calculate the percentage of the maximum articular speed of the robot. Why this value is 1000?

This is an arbitrary value, there could be a better way to handle this. DeltaTime 0 can happen in two instances:

1. Two consecutive targets in the same position. If you set the speed to 0 because deltaTime is 0, it could make the robot not move to the next target, any speed higher than 0 would do (the logic in this case could also be to use the speed of the previous target, for example).
2. The first target. This is more tricky because when you start a program, the robot it will move from wherever it is in real life to the first target, but the plugin doesn't know where the robot is in real life, so it cannot calculate a delta time. In this case it uses 1000 mm/s as 100% speed, so if you set the speed of the first target to 250 mm/s it will move at 25% speed.

[visose]

I did the same with the Fanuc models and changed in the XML the distance values. I tested it and it works

Can you confirm the robot in real life adopts the same position as in the simulation? By changing only the XML and not the post processor, I would assume the simulation now looks like it's moving to targets that are at a lower position relative to the robot than in real life.

[AngelLM]

I have double checked it, because I had the same concern, but the points are placed where they should be.

[Calbaterra]

Hi @AngelLM,

I'm in the process of acquiring a FANUC LR10iA/10 robot. I attempted to use the solution you've implemented, but encountered the following message While I understand that you haven't implemented support for the specific FANUC robot I'll be using, I still wanted to give it a try to see if it would work with FANUC (TPE).

[AngelLM]

Hello @Calbaterra,

Which version of Robots plugin are you using? If you are using the released version it may not contain the support for Fanuc robots (lastest release was 1.6.7 on Jan 8). So I think that you can build yourself the plugin or wait until @visose releases a new version that contains the Fanuc support.

However, I think this topic should be addressed in an issue.