Posts by Nation

    That sounds horrible. It should be a lot easier that that. You should be able to do tracking and teaching of a tracking path in roboguide's not sim mode. I've done dozens of tracking simulations, and never had to resort to that.

    If you package up the cell, I can take a look at it and see if there is something messed up with it.

    HI Nation,

    Do you have a code example for this?

    regard Bjarke

    Sure. UTOOL1 is the master tool, and UTOOL2 is the shifted tool, from master.

    UFRAME5 is a frame taught in the center of the switch.

    The speed you do the search at will impact how accurate the shifted tool is.

    The code is slightly different than what I described, as it does 5 searchs, as in roboguide the collision input tends to fliker. Got around it by searching for rising edges only.


    Animation of it working:

    If you don't want to spend the money on Leoni's solution, you can do this with a through beam sensor, and 3 search moves. I did this 6 years ago. Turned out to be very repeatable, and it has been running production since then.

    What you would do is set a frame to the laser, then search for the rising and falling edges while moving through the beam in X, Y, and then just the rising edge for the Z search. I would then take a 'master' TCP, and then shift it by the found deltas.

    The PR is based on whatever user and tool frame is active at the time your run to it. Not sure what the F stands for. Floating? Free?

    This doesn't apply of course if the PR is in joint rep.

    Here is my configuration for connecting to the first simulated robot in roboguide:

    I'm not in control of the touch up of the path, so when the people responsible for the the touchup finish, I want to verify if my chosen CVWAIT positions are still valid.

    Also, the robot is overloaded in terms of its path. I need every mm of upstream real estate I can grab in order to not fall behind.

    In addition to all that, the entire path is shifted by a vision system. One point that may be reachable at a certain conveyor position may be reachable in one offset, and not another.

    Since I got it working I was able to make a graph of the upstream reachability of one of the paths:

    I got it to work.

    Inrange does function as a reachability test, but with how Kawasakis do their line tracking point teaching, it is pretty counter intuitive. From my testing, INRANGE checks reachability of the XYZOAT position of the pose, and then just checks to see if the ext axis is within the motion limits.

    Since how I was originally using INRANGE was effectively testing taught points, so of course every point was reachable. The key is to shift the XYZOAT of the along the conveyor tracking vector by the delta of where the point was taught, and where the conveyor currently is, then run the inrange test.

    What is it you are actually looking at being reachable and at what point in the process?

    When you start tracking, at what point are you looking whether it is reachable or not?

    It all depends on how fast the algorithm for reachability checks ends up being. Ideally I would like do to the check repeatably while the conveyor is moving before moving to a point, and then releasing the robot to move when the point becomes reachable. Maybe with some padding so the robot doesn't get into an elbow lock position.

    If I can't do it real time, I would like to develop an offline check that would output a range on conveyor for when a specific point is reachable.

    Is this for outside of the robot envelope (error), or within a certain zone to cancel the tracking of it?

    For outside of robot envelope.

    Have you looked at CVPOS command?

    Yes, I will need to use that command to pull out the current conveyor value for in range testing.

    Have you looked at ULIMIT and LLIMIT commands?

    Haven't looked at these, but after looking at them in the AS manual, I'm not sure they will help that much. I'd like to keep the joint limits of the robots as open as possible.

    Have you looked at DISTANCE and DEST commands?

    DISTANCE will be used if I have to go with the IK solver idea. I don't plan on using DEST as I only want to do the check before moving to the next point.

    Maybe I can use distance to check the current position vs where the next point is. I would like to check orientation though.

    Anyone have any advice testing to see if a point is reachable? I want to test to see if a point is reachable before attempting to run to it.

    The kicker is that this is on a line tracking cell. The INRANGE function seems to not work on this type of robot, and after discussing with Kawi tech support, it only checks if the passed in point is within joint bounds, and not if it is reachable or not. It was returning a 64 everytime, but once I opened up the bounds on J7 (the conv tracking axis), it just returned 0 for every point tested, even for points obviously unreachable.

    My next attempt was to attempt to convert a pose to joint, and use the error catch of ONE if the conversion failed. Either I didn't setup right, as the controller faults the moment I attempt the conversion. The ONE program is never entered/called.

    My next idea is to write an IK solver in AS, but I would prefer not to do that.

    I reverse engineered what the sFc section does a while ago.

    My comments: