Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Joint angles from point follow project not smooth

#1
Hello,

I have the problem that my calculated joint angles from RoboDK are not very smooth, causing the robot to shake and vibrate (with a high frequency) a lot while  moving. You can see the planned joint angles in the plot:
   
On the right side you see the excat problem, the joint angles are not like a spline but more like measurement data. What is the problem with that? I was using PyhtonAPI and the point follow project to create my kuka program. Thanks in advance! Michael
#2
Hi Michael,

Can you provide your .rdk file?
And the generated .src file?

Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel


#3
Hi Jeremy,

sure, here is what I got. What do you mean with src file btw? I feed the robot with the joint angle list. Since I couldn't upload csv file I changed the file to txt.

Thanks, Michael


Attached Files
.rdk   20201023simulationKuka.rdk (Size: 347.32 KB / Downloads: 341)
.txt   data_downsampled_rollcomp.txt (Size: 5.59 KB / Downloads: 408)
.txt   data_downsampled_rollcomp_from_robodk.txt (Size: 14.65 KB / Downloads: 380)
#4
Hi Michael,

Are you monitoring the joints from the real robot or from RoboDK?

Make sure to use a rounding radius on the robot. With KUKA controllers this will generate a C_DIS flag for every LIN movement.

You can right click the first instruction in your program and select Add Instruction, then, Set rounding instruction and enter 5 mm (or try values from 1 mm to 20 mm).
   

If you want to automatically generate this using the API you can use the setRounding function. Example:

Code:
program.setPoseFrame(frame)
program.setPoseTool(robot.PoseTool())
program.setRounding(5)
program.setSpeed(speed)

Albert
#5
Dear Albert,

these joint angles are the output from the RoboDK simulation. For my first tests I used a moving average filter which I applied on the data after the simulation with RoboDK to get a smoother trajectory. Nevertheless, it would be practical to use RoboDk for that :) I tried your approach with the rounding value but it had no effect for me neither with 5 or 50. The joint angles keep completely identical (especially joint angle 4 within the region 10-40 makes problems):

   

I tried using the rounding with the API and adding manually, but no difference. What's the problem here?
#6
Dear Albert and Jeremy,

since I planned the next measurement next week on monday it would be great if you could share your ideas on my problem with the singal as I used your hints on the rounding but did not see any effect so far! Thanks in advance!!! Michael
#7
Hi Michael,

We, unfortunately, didn't have the time to look into it.
That's still on the list. I think your smoothing algorithm is your best bet for Monday.

Jeremy
Find useful information about RoboDK and its features by visiting our Online Documentation and by watching tutorials on our Youtube Channel


#8
(11-20-2020, 05:26 PM)Jeremy Wrote: Hi Michael,

We, unfortunately, didn't have the time to look into it.
That's still on the list. I think your smoothing algorithm is your best bet for Monday.

Jeremy


Hi Jeremy,

okay thanks for your replay anyways. I'm still waiting desperately for your help ;)

Here is my signal filtered with a lowpass 10Hz. Of course this filtering gives me inaccuracy in the cartesian end effektor position. I'm curious how the signal would look like if the rounding works:

         

Cheers, Michael
#9
Dear Albert and Jeremy,

I was wondering if one of you guys could help me with this issue, its still a problem with our robot. Or at least I would like to know whether there is a better fix than my filter algorithm since I think this behaviour is not normal.

Thanks, Michael
#10
Hi Michael,

I'm sorry we took so long to get back to you. You are getting these results because you are looking at the joint values of each targets in the order they appear in your program. You can't assume the time to move from one target to the next is constant. Among other things, you can have targets that are closer than others. RoboDK also has a filters when generating programs that will prevent generating targets that are closer than a certain tolerance (default tolerance is 0.02 mm, you can change this in Tools-Options-Program).

There is a script that allows you to create your own joint slider based on a program. You can select Tools-Run script-ProgramSlider. This will show a program slider that you can customize (you can find this script in C:/RoboDK/Library/Scripts/ProgramSlider.py). Dropping this file to your project allows you to run it from RoboDK. I added this file in your project attached and customized it to export the joint listing of your program with respect to time as a CSV file. You'll get time increments and you can create your own column to calculate the time for each step.

I extracted the excel sheet and chart with these manipulations.
   

RoboDK's timing is not 100% accurate though. With point to point moves, RoboDK assumes you'll have a uniformly accelerated motion until you reach a constant speed. Among other things, if you allow rounding/smoothing, RoboDK assumes the robot will follow a constant speed (which may not be the case) and the robot may have to go through non realistic accelerations.

Albert


Attached Files
.xlsx   Program-Joints-vs-Time.xlsx (Size: 494.28 KB / Downloads: 318)
.rdk   20201023simulationKuka.rdk (Size: 350.37 KB / Downloads: 362)
  




Users browsing this thread:
1 Guest(s)