Transforming an animation from Cinema4D to a robot program (KR C4 for a KR 1000)

    Hello there,
    There's a project coming up for us, where I have to transform an animation from Cinema4D (maybe 3ds Max if the former doesn't work) to a robot motion. The robot type is KUKA's heavy duty Titan KR 1000 with a KR C4 Controller !


    I don't have access to the two robots for now, until few weeks before delivery. so I want to try my solution in a safe and reliable way. Here are my questions:
    - Did anyone of you do something similar for a KRC4 robot?
    - I know there is a bunch of simulators in the open, what's the one I could use for now (at least a trial version) just to get started?


    What I want to do is generate paths from that animation, to be able to execute them on the robot (.src and .dat?), preferably without much KRL coding (It has been a year, so my KRL is a bit rusty). Is there a powerful tool for this, even if is not free.


    Any idea, suggestion or details answer would be appreciated.

    For free(ish) robot simulators, the only one I'm familiar with is RoboDK, which is pretty nice in some ways, but I've never tried importing a series of motion commands. It looks like the "approved" way to do this is to create a Python program that uses the RoboDK objects to control the robot.


    For the actual KRL program, well, there's more than one way to do this -- it really depends on what kind of program you're trying to create. I suppose the first questions to ask are:
    1. Can you create a common Base frame and Tool frame between the real-world robot and Cinema4D?
    2. Can you get Cinema4D to export a continuous, ordered list of all these positions in a simple easily-parseable format?


    If you can get a positive answer to both questions, the rest should be fairly straightforward. My usual tactic for attacking this kind of program is to create a large .DAT file array of type POS or E6POS, and use a tool to transcribe the point list into said array. Then my SRC file simply iterates through the array one motion at a time.
    Of course, the tricky bit comes when you want to insert logic or branching....

    Thanks Skyfire.


    I played with RoboDK, yesterday, and I'm still figuring it out. But, it doesn't seem what I need.


    Quote

    1. Can you create a common Base frame and Tool frame between the real-world robot and Cinema4D?


    I don't know much about Cinema4D, the clients animators are the ones designing the motions there. I'm responsible to replicate them on the robots. I'll check with them again.


    Quote

    2. Can you get Cinema4D to export a continuous, ordered list of all these positions in a simple easily-parseable format?


    That's what I thought about first (and what I usually do with LBR iiwa). They used a scripting language called "Xpresso" (It's a graphic one with nodes), but I don't know if it can generate such data or file.


    Quote

    Then my SRC file simply iterates through the array one motion at a time.


    The animation contains movement and some stops. If read through the frames one by one and execute basic motions (LIN or PTP), I think it would make jerking movements (had this with the iiwa when frames are too close), did you encounter such issue? If yes, how could you get around it?
    A quick idea, is to create a tool that creates from batches of frames of the same motion block to an SPL or Async motion, and if the differences are too small (It means a stop), I just hold position. Then in KRL I gotta interpret this file.

    Well, in the end, if it's not possible to get an ordered list of either Cartesian positions or Joint poses from the animation, then this entire project is pretty much a dead end.


    Assuming you can get this data... just iterating through a list of positions is easy. Pauses are harder, and branches harder yet. You'll need to have some sort of common format agreed upon with the animators.


    Let's say, for the sake or argument, that you and the animators agree on a common format for each motion step. You can create a STRUC type variable similar to this: STRUC AnimationStep E6POS Position, BOOL Continuous, PauseForInput, INT NextMotion


    Fill in an array of this type of variable, then do something like:


    That's just very bare-bones conceptual, but something like that would allow the animators to indicate in the data they provide to you where each point should be, if it should be continuous or not, if it should pause for an input, and which motion in the list it should jump to next. Obviously, you can make this much more complex.


    As for jerky motions from the points being too close together -- usually you can handle this with C_PTP or C_DIS, and careful handling of your approximtion radii. However, if the points are too close together (a problem usually seen in CNC programs converted naively to robot code), then the problem may be unavoidable. You may have to work with the animators to get sequencing/spacing that the robot can work with. Conversely, you might try using Spline motion, which is a bit harder to work with, but can handle closely-spaced motion points better.

    Thanks for the answer. I'll built on that.


    Quote from SkyeFire


    Well, in the end, if it's not possible to get an ordered list of either Cartesian positions or Joint poses from the animation, then this entire project is pretty much a dead end.


    That's what I told them. In the extreme case, I'll do the robot motions programming, then they create the 3D animation from that.

Advertising from our partners