Posts by NullReference

    You could run the socket listener in the main application (the one that is started from the smart pad) and when new commands are received you start different programs/classes. Remember that your application class that extends the RoboticsAPIApplication is just a Java class, all methods available in the context of the RoboticsAPIApplication can be imported manually in any other class.


    So the best way to do this is to create a class for each of your advanced sequence of motions and then simply pick whatever class you want when you receive a new command.


    The question actually is, if I program a movement with 250mm/s...what happens if the robot cannot reach the 250mm/s for the specific part of the path; an example, it reaches 230mm/s. And if I have a gluing application, I want to know the exact speed of the TCP so I can apply the glue correctly.


    On KRL, it is possible to read the real-time TCP speed (analog input).


    Thank you all for your ideas!


    You could create a thread/background task that polls the TCP position x number of times per x time unit and compare it to the last polled position. You could simply calculate the distance between these 2 points, now you have delta distance and delta time. Should be fairly accurate if you are doing mostly lin, for circ or other motions the accuracy might not be as good.


    @NulReference yes but I can only add AMFs for 3 different axes, when I try to add the fourth it is automatically linked to the instance of one of the already 3 configured axes. I dont see how I can create a new instance with a different axis


    Just checked my workbench 1.14. It is the same for me, only 3 instances can be created for axis range monitoring.


    But if the object is not grabbed form its center of mass, shouldn't I consider the torque instead of the force?. Let's say the robot grabs a bottle from one of its ends and then it grabs it from its center, the readings in Fz should be different right?
    Thx for your reply NullReference


    The gravitational pull should still be the same. The LBR iiwa calculates the directional force on the TCP from the torque values of all seven joints. The calculated values might not be as accurate as a direct measurement i.e. a scale. In my experience the iiwa is accurate for most applications.


    If you are measuring liquid containers make sure that the liquid inside is not being stirred, this will produce inaccurate sensor readings.

    Orient your TCP so that when you are grabbing the object one of the vectors is pointing straight to the ground/roof. You could then get the force in that direction. That would be the force of gravity pulling this object to the ground. With the force you now can calculate mass.


    I think you might want to enter an impedance mode with high resistance before polling the sensors just to make sure that all the mechanical brakes are open. I don't if the torque sensors can produce meaningful data with the brakes shut.


    Might be good to filter the values by polling the sensors x number of times during 1-5 seconds and then calculating the average of that, just to remove the jitter from the sensors.


    Make sure to identify your tools load data before doing any of this.

    For this purpose it is sufficient to use the collision detection AMF. If the robot is to be used in a production enviroment the you need to do risk assessment and probably use more safety functions.

    That's way too many spline points. Try to keep atleast 2-3 mm between each point. For circular motions you dont need many points you could reduce this number by a factor of 10 and the path wouldn't change much.


    The robot stops because .move() blocks the thread untill the motion is finished. For the controller to interpolate 2 motions with corner path you must send the new motion before the last one finishes. Normally this is done with .moveAsync() or a motionbatch. Using .moveAsync() in the while loop would probably cause an error in the controller.


    You could create a big motion batch with the same spline motion repeated many times. Might take some time to start the motion but then it will keep running for a while. You could alternatively use a MotionPathCondition in combination with .moveAsync(), your loop would then look like this:


    async spline motion that triggers a condition when it is almost finished.
    Wait for condition
    let the loop start again


    The above would allow the controller to generate a smooth transition between the 2 motions. Don't forget to set the blending for the spline motion, if no blending is set then the robot always stops between motions.

Advertising from our partners