Speed Units / Conversion

[lionpeloux]

Hello Vincente,

I understand that the create speed component asks for linear speed in mm/s and angular speed in rad/s (would be better if the proper units were mentioned in the component entries ?).

In the xml cell definition, linear speed limit is expressed in mm/s and angular speed limit in °/s (would be better if the same units were used all over your plugins ? => °/s seems a bit more human readable to me ...).

However, it seems that the Create program component interprets the speed value as if it was m/s for external axis and not mm/s. Thus the component always shows a warning (speed limit reach).

More over, if I play with the angular speed definition, I never get a warning regarding rotational speed limit. Is there something not implemented yet ?

Thanks,
Lionel

[visose]

Hi Lionel, the units are documented in the wiki (https://github.com/visose/Robots/wiki#units), but it will be helpful to include them as well in all input descriptions.
The plugin uses radians because Grasshopper uses radians for angle inputs and outputs. This way its more consistent and shouldn't require the user to convert units. Radians are also intuitive if you write them as a function of PI. In Grasshopper you can create a panel and type "pi*0.5" if you want 90 degrees.

The reason the XML uses degrees for the joint limits and speed is because the manufacturer's specification document will come in degrees so you just have to copy/paste the numbers.
Converting the values from degrees to radians for joint limits not only involves multiplying by (PI/180, but actually varies from one robot manufacturer to another.

I'm making these number up but imagine a KUKA robot might have the limits as 0 to 180 degrees and an ABB might have them as -90 to 90, but both ranges physically look exactly the same, they just decided on a different convention/ start angle/ even direction. The plugin internally will convert these degree ranges that come from the product specification to the internal one used by the plugin which is consistent for all robots models.

The reverse also happens, when you create a joint target using radians, this uses the plugin's internal method, so if you switch between robots of different manufactures in Grasshopper, they will look posed the same way physically (except UR), but when it generates the manufacturer specific robot program, the angles will be converted back to their specific convention. Hope this makes sense.

Regarding the linear external axis speed warning, I'll check, it's probably a bug as you say, thanks for pointing it out. The rotational speed warning was only implemented for a target that is both rotating and moving in space, to warn that the speed bottleneck is the rotation not the linear movement. It's possible I didn't add a warning to indicate that the bottlneck is the external axis speed, I'll check. This would be related to the "joint speed limit" rather than rotation speed limit.

[lionpeloux]

Hi Vicente, It’s more clear for me now. I agree radian is ok when you input a value (as a factor of Pi) but not when you want to read a value (like 0.7564rad). Thank you again for taking time to answer me.