euler angle/relative motion

    I know this has come up before, but though I would ask as we seem to have become confused over here. The question relates to relative motion. If I tell the robot to do the following:

    LIN_REL {B 10} ....

    it will do exactly that, but the orientation in the world will maybe change by {B 8, C 8}[ values not important, just note its changing both]. I have done this for a long time and never cared, or frankly usually used LIN and specified exactly where to go.


    But now, using purely sensor guided motions, this is an issue. We want to perform relative mode corrections with RSI_movecorr. As long as we are only talking XYZA everything is fine. But if we try to correct B and C, we have an issue, due to the above. We have lots of ideas to fix it, but none are working well. Even if B is a small change. Do we need to convert to Quaternion before computing the change, and then convert back(we think this will give the same solution). Do we need to take our desired correction, and convert this to a different solution to pass as relative correction? Similar to the way LIN_REL B produces B and C motion in the world?

    Hm. Maybe I'm missing something about your configuration? I never had issues doing this when I was doing RSI, but I was using Tool-mode motions. Are you doing something different? If I recall correctly, the RSI motion objects have options for whether the corrections take place around Base or Tool axes.

    What's the relationship between your TCP and your sensors? Do you have fixed sensors trying to drive the corrections of a TCP as it rotates?

    We've run into this issue in one of our robot configurations as well. As best as I can tell, it has to do with the robot reporting cartesian orientation in ZYX Euler angles, but RSI giving corrections based on base-frame axes when using RSI in world frame mode (if that makes any sense.) We ended up just using rotation matrices (transform Euler angles to rot. matrix, do stuff, transform rot. Matrix back to Euler angles), and it worked out pretty well.

    Thanks all...;

    @skye:

    We are using base/world mode(IPO_FAST). Incidentally, the manual seems to imply you can only correct in base unless you use IPO mode?

    We are also using relative mode, poscorr(full sensor guided motion)

    We could do them in tool potentially, but are trying base currently

    Yes we have a fixed sensor. This see certain targets, and has calibrated frame to robroot. So when things "start" it tries to drive robot to a position. It does this by calculating the final pos; it then receives the actual pos via rsi. Next computes the trajectory, and using PID control, tries to smoothly drive the robot to that point. Works fine with XYZA. but with BC, werid things happen

    We also tried #ABSOLUTE mode. But this mode is a bit odd. It seems the "origin" for correction is the pos_act from when RSI_MOVECORR was activated. We can probably work with that, but its a little weird. As we already had #RELATIVE working well, we wanted to continue, but the rotation thing is odd.

    @gt
    I think you are right, but can you clarify a little? I get the cartesian ZYX part. But yes, it seems you cant just feed a correction to the ABC in a linear fashion in relative mode(by linear I mean all three interpolating across the angular delta, we are still using PID to control the motion). We had considered to convert the start/end to quaternion, run through PID, and convert back, though honestly this may just give the same result(maybe not though).

    wes_mcgee
    I think we're on the same wavelength. That is essentially what we did, just with rotation matrices instead of quaternions. We transformed the Euler angles into rotation matrices to find the correction that would give the desired orientation, then transformed the correction into Euler angles for RSI. But I imagine you could get any representation to work (well, except Euler angles :icon_smile:)

Advertising from our partners