smoothing focus of camera mounted robot

    Robot: Kuka Agilus KR 10 R1100 sixx
    KSS 8.3.8

    I've got a video camera mounted on to my robot but can't figure out how to program the movement to get a smooth video feed.

    Did some preliminary tests earlier in the year and found that, in between LIN or PTP commands the focus of the camera wouldn't keep still. We assumed this was because the robot was not aware of the focus point and so it doesn't take care of that.

    Is there a way, using other commands like SPL etc., or changing the mode, to make the camera always focused on a fixed (or moving) point?

    Thanks,

    ...well, how is the robot supposed to know where that moving point is?

    It sounds like you are trying to implement a real-time tracking solution, which would probably require RSI to carry out effectively, although the Function Generator might be sufficient. How are you processing the video data into positional data corrections for the robot to use, and how are you getting them to the robot?

    While we do have RSI, we don't really need a real-time solution I think. Just a way to transform a set of planes in to a smooth movement for the mounted camera. Will only have a short time to actually test coming up before I need to implement it, so was wondering if other people had already found a solution. small jerking movements in between movement commands would be preeetty bad for the camera >_>

    panic mode I wish! :icon_smile:

    No feedback loop. Set of positions/planes pointed towards a fixed point (or moving if possible)
    Problem is that in between the positions/planes that I program, the robot seems to slightly point in other directions before centering back on the object (this was from tests done last year, won't have access to robot til about Thursday to do more tests)

    Ah, when I said 'focus', I really meant 'centered'. The camera is not synced up to the robot or computer in any way at this point. More concerned about how the camera won't stay centered on the target in-between positions/commands.

    I think I had figured out an ad-hoc solution eventually, but it didn't fit all my needs and regardless I've gone and forgotten it :angry_face: (been over a year and that project got scrapped early)

    As a very basic example, I'm trying to move the camera in a curved path, with the camera always pointed towards an arbitrarily selected point.

    LIN doesn't work as it breaks up the curve and, in between the LIN commands the point is no longer centered
    PTP in between commands points in random directions due to PTP

    My question is if there are ways to, in between the commands, keep the camera targetted at the selected point (or as close as possible?..) using SPL or other commands or enabling some modes that I may not be aware of? to atleast have a smooth transition between commands (from the perspective of the camera)
    For a fixed focus point, if I set the TCP to the focus point it might work, but if its dynamic I'm kinda lost..

    Curves are usually broken into set on LIN CONT motions (the shorter the more accurate)
    Spline will not do anything better here.

    If you set TCP at a focal point of a camera than it should be no problem.
    If focal point change you will have to track it somehow and dynamically modify current TCP data (my best guess)

    if the focus is dynamic, then it needs to be a controlled axis. Then you can solve the path/tcp problem via offline programming(or online via RSI I suppose). Also a possibility would be if you could compute the dynamic TCP externally, and then read it via submit interpreter. We have implemented this for modifying the BASE. But changing the TOOL this way will stop the advance run pointer. Also you mentioned smoothness, of course the approximation parameters and TCP accelerations need to be adjusted.

    Hm... I wonder if a "fixed TCP" configuration might help?

    Regardless, a calculated set of relatively short LIN motions using C_DIS or C_VEL should be sufficient to keep the camera centered and relatively well-focused on the target. I have a "GeneralEllipse" module at http://kuka.skyefire.org/ that sketches out the general idea of doing this mathematically. Although in this case, you need a rather different type of motion.

    Here's a very bare-bones example of what I'm talking about. Let's assume that you create a Base whose origin point is centered on (or beneath) the object you want to keep the camera pointed at. Program your starting position in that base, then compute your arc programatically. This is a simple single-axis arc, rotating around the Z axis of the Base:

    What this should do is create an arc of motion that keeps the camera pointed at whatever your (hand-programmed) StartPosition was pointing at, following an arc around the target at a fixed distance.
    The trick I used to make this simple was to put the Base origin at the location of the target, and then virtually rotate the Base frame while generating the array of motion points. The robot's built-in tools make it simple to rotate Base or Tool frames. By setting the Base origin at the point I want to rotate around, it becomes easy to do this.
    The key is the calculation RotFrame : StartPosition. You can look up the "Geometric Operator" in the manuals and in the Forum archives, but briefly, it's a 6DOF vector cross-multiplication. You can think of it as treating the FRAME/POS/E6POS variable on the left side of the colon as the "frame of reference", and the variable on the right side of the colon as a transform to apply starting from that frame of reference. So by arranging the operator this way, the code virtually rotates the Base and calculates the StartPosition equivalent to counteract the rotation. To put it another way, the robot thinks that the object at the Base origin is rotating, and is trying to keep the TCP at the same position/orientation relative to that object.

Advertising from our partners