Programming Kuka Robot to take photos

  • I want the robot to use 1 camera and move to different locations. Right now it waits for the cameras to take the photo and then resumes. Below I describe the current method which is taking photos with 9 cameras attached to the wall instead of the rob.


    We have 3 Kuka robots with Occubot Seat program to test seats.

    We need to take photos after N cycles and Kuka provided a method described below:

    The method involves 3 files

    1. The main file controls the motion and sends keeps count to when is photo time.

    2. the main program calls the the second program called Photo_Stop which moves the robot out of the way and waits for photos to finish

    3. The 3rd file is tied to the second file. It's the serial communmmgr.scr which reads the information from the RS232 port and writes back when the photo stop is finished.


    I'll attach the code below and I have to explain that most of the code comes from one of the manuals. It all depends on the robot being put on a frozen state while taking pictures with one or both of these commands


    CREAD(HANDLE_, SR_T, MR_T, TIMEOUT_, OFFSET_, "%S", Str[])

    CWRITE(HANDLE_, SW_T, MW_T, "%S", Str[] )


    If the robot doesn't get the correct info from the RS232 port then it just stops and waits for a human to take photos.


    Since the robot is frozen, I wonder if there's any way to change the code for the the robot to move to different locations (instead of having 3 cameras per seat = 3 * 3 =9) to take the photos with a camera attached to the robot. I still need to send the robot the same data (the number of cycles) and for the robot to send back the same data (everything OK, ).


    This is the Photo_Stop.src

    The following is the Serialcommmgr.src and it's pretty much exactly what's in the communcations manual.

    And I won't post the controlling program and file because it's too long, but the important thing is only this. When a photo is needed it sends this command:



    photo_stop(2, #CONTINUE_, totalCycles2, totalCycles2, stopAtEndTest)

    My question: Can I change the program so that instead of the robot being frozen, it actually moves around the seat to take the necessary photos? The photo program is controlled by a second independent computer which just recieves the command to take photos and the number of cycles to label the photos.

  • please read pinned topic READ FIRST and make sure to post in correct forum section.

    what do you mean by "frozen"? this means program is running but not responsive? i think your problem is that program is NOT running. it seem to pause when reaching HALT command so "R" icon for robot programs turns from green to red, then you need to start it again.

    if so then issue can be solved by modifying code of your PHOTO_STOP()

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • I certainly want to be a good citizen. I read the pinned section and I'm not sure where I went wrong. Is it that I didn't include version number? Should I remove code? Is it unclear language?


    Anyway, let me clarify the frozen statement: when the SerialCommmmgr.src program arrives to this command:


    CREAD(HANDLE_, SR_T, MR_T, TIMEOUT_, OFFSET_, "%S", Str[])


    I believe that the robot is not in a Halt state, but it's waiting to read data. If the robot sends the command and the photos are taken and receives a command that everything in OK then the program continues. I'm not sure how it works because it's so fast; I don't understand the logic of this exactly but I do know that it's in the communication section that the robot gets the go ahead to continue or halt

    If there is a communication problem and the TIMEOUT_ time runs out then the program goes to a HALT statement and a human has to re-start

    If there is any other problem with the camera the Robot will receive the Abort command and it goes to a HALT command and a human has to re-start

    If the pictures are taken within the TIMEOUT_ time and there is no error then the robot will not go to a HALT statement and will continue running normally.


    This does seem to be an unusual feature and possibly not meant to be changed without totally changing the code. If that's the case then I won't be asking for that because it's too much.

    What I am wondering is that during this wait period the robot can actually move if it had a camera. This waiting period seems to be wait for a command or error command and it seems that the robot cannot do anything else other than wait. It is running but without any motion as it waits for the commands.


    Now I know that I'm not clear and I'm not clear because I don't quite understand if it's the CREAD, the CWrite or even the "For i = 1 to numTries" loop that is holding the robot. I do know that when it's working normally it is NOT held by a HALT command.

  • I see now that you moved my thread... Believe me I spend 20 minutes searching for the right forums and locations to post. I'll do better next time.

  • we still have NOT confirmed if this is due HALT command and which one


    1. can you not look at HMI and see:

    a) program status (background color of "R" in SIR)

    b) instruction pointer location


    2. can you not take a photo of HMI when failure occurs?




    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Sorry I haven't answered. I needed to find an opportunity to sneak into the robot between tests.

    So here's the pictures. I show on the bottom right that there's a minute (3:49 to 3:50) where the robot is sitting there waiting for a response from my computer connected to the RS232 port. If it gets no response then a timeout happens and it goes to a halt statement. If it gets an everything is OK response then it continues running. I think that this process is rarely used so don't worry about it if it's not obvious, but I have thought of a workaround and I will post my idea later, because I'm not sure how to implemented.

  • Well, the HALTs are at lines 53 and 56 of your posted code for Photo_Stop(). You can do anything you like in place of those HALTs, it simply takes programming. Those HALTs are obviously just placeholders for "insert your application-specific error handling code here."


    It depends on what you want to do. You could loop back and keep re-sending the photo command until a good response comes back, or the world ends, whichever comes first. Or you could have the robot skip to the next photo position. Anything you like, really.

  • So to tackle this I have to do a brief explanation.

    The program we are given by Kuka is Pretty much a turnkey program that does many hidden calculations that are invisible to me and we have no control over. We were only taught how to change the path dependent on what kind of seat we are testing.

    We did take a class about 5 years ago but we could never use anything learned because it had little to do with this special program which I showed you.


    Saying that the solution to what I need to do needs that I do something that may be considered fairly simple.

    I don't know how to do the following. The problem is I don't know how to move it depending on the base. Most of the examples I see show only motion depending on base (0) or the robot, so I need help doing the following. I tried to move the robot which defaults to base(0) and I changed it to base(1) and the robot acted the same. Now I've never used the PTP program before so I fully expect it to be my fault but I don't know enough to understand why it didn't work


    How do I move the robot in base(1) to location (x = 0 y=0 z = -200 a=0 b=0 c=0) so 200 up in relation to seat 1


    and similarly


    How do I move the robot in base(2) to location (x = 0 y=0 z = -200 a=0 b=0 c=0) so 200 up in relation to seat2

  • "How do I move the robot in base(1) to location (x = 0 y=0 z = -200 a=0 b=0 c=0) so 200 up in relation to seat 1"


    do you understand how base, tool and point coordinates are related to each other?


    if you want to use base, first you need to create one.

    then you can teach points that use that base rather than world.


    and if you want to move to a point that is relative to one you have, you can apply offset programmatically - look up geometric operator.


    example:


    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • I just about gave up because of the many issues. I still haven't been able to update the program, but I believe I can.


    However something else, that should have been obvious, came up. I can't just connect a camera and it's long communication data/power wire; It's going to drag and possibly damage something. Any wiring that I see goes inside the robot and then comes out to the outside world. I see nothing dragging that may be damaged.


    My question: Is there a special connection inside the robot that makes this possible? There's many other questions that follow depending on yes or no. If no then is it OK to have a wire dragging outside the robot? If yes, then does that prevent me from connecting anything else, or perhaps there is a way to access the system inside the robot?

  • That depends entirely on what dressing options the robot was ordered with. It also depends on what connections your camera needs.


    For example, if your current end effector already has 24VDC power and Ethernet, you can probably tap off of those for a camera like a Cognex or Keyence. OTOH, if your camera requires a coax cable back to a frame-grabber card, you're probably stuck.


    I don't know what model of robot you have, but most KRs, if you open up the skirt around Axis 1, have two corrugated hoses wrapped around the axis. Usually, one of these carries the cabling for A2-A6, and the other is either empty, or occupied with optional cable sets. These hoses both exit through the hole in the center of the A1/A2 casting. Then the A3-A6 cables usually travel up the inside of the A2/A3 link arm -- optional cables may also, or there may be a corrugated hose going up the outside of the link arm.


    Then, up atop the "elbow" assembly for A3, the optional cables are broken out to travel down the A3/A4 link arm, and across the wrist. The link arm section may be passed through a spring-loaded management system of some type, but going over the wrist, most cables are loose.


    If there is spare space in these various corrugated hoses, you may be able to fish the additional cables you need through them.

Advertising from our partners