Yeah, that's where I went first. The concept is straightforward enough, even if the math is a bit rarified for me. It's how the theory relates specifically to Spline motion that I need to get a handle on.
Approximating/branching Spline motions
- SkyeFire
- Thread is marked as Resolved.
-
Basically rising slope is positive, falling slope is negative. If there is a cusp, curve is not differentiable at that point...
-
Quote
Mmm... let me rephrase that: do velocity and acceleration each need to be twice continuously differentiable also, or is that that position needs to be TCD, velocity needs to be just continuously differentiable, and acceleration just needs to be continuous?
Only position needs to be TCD. Velocity then is only once and acceleration is continuous.
Changed my Robot type to yours and still no drop in cartesian velocity. Rereading your previous posts I assume that the velocity drop only happened if you are connecting two 90° SCIRCs and this no longer happens if you use a single 180° SCIRC like I had in the program and you had later on also. I have also seen the kink message and still believe it is the SPL -> SCIRC (or SCIRC-> SPL resp.) that is causing this, because as stated earlier the transistion is not smooth enough if it is done only tangentially. The kink message already went away by setting CONST VEL START = 1 and CONST VEL END = -1, but still the velocities where very slow.
Try to think of TCD in "jumps": If Position is not continous a position jump happens. If velocity is not continous a velocity jump happens. If accelaration no longer is continous an acceleration jump happens. Tangent and Curvature are basically different words for velocity and accelaration in a geometric context. Maybe also think about running a car: You can not jump from Augsburg to Munich at an instant. You can not reach 100 km/h in an instant. You can not accelerate discontinous.
Also rechecked my traces and yes cartvel_cmdipo and cartvel_cmdspl are the same. Please look at the attachment (now already for the foundry #KR2210_2 S C4 FLR ZH210 XCL version).
So still my advice allow the robot more time to pick up the SCIRC curvature by moving the const_vel area a bit or lengthtning the SPLs and start/finish rotating in the spl segments before and after the scircs.
You might also check into setting $ORI_TYPE = #IGNORE at the SCIRC start and end point which basically lets the system distribute orientation control more evenly and therefore often leads to faster velocities.
Fubini
-
Very absorbing tale ! How the story ends with the spline motion approximation and force-torque control in the spline?
-
Very absorbing tale! How does the story end with the spline motion approximation and force-torque control in the spline?
No one knows ...
-
That project ended up not moving forward, so I didn't get the chance to experiment with FTC-over-Spline.
But given how KUKA is pushing to make the Spline motion planner the default on KSS 8.5+, I'd imagine the "regular" Spline motions should work with FTC much the same as "classic" LIN/PTP motions.
Spline blocks, OTOH, remain unexplored territory (for me, at least).
Thank you SkyFire!
-
Differences in Approximation execution compared to old motion are:
- If Approximation is not possible the robot stops at approximation start (in old motion it was at the teached in position).
Is there any way to stop at the taught position?
-
No there is not. Why would you want to do this? This is a position that in normal execution should never be reached. Spline geometry is always the same with blending even when approximation is not possible. This is collision safe.
Fubini
-
that is correct. and if you want to stop at the point, do not use approximation.
-
I would like to stap just before dropping position. We have a function that checks input from HMI, it is like a breakpoint in debugging. We always use old PTP but for the current project, we use SPTP which makes only issues. Customer choice.
-
Maybe you use it wrong. What are these problems? Just complainig does not help. I am not sure I have understood your explanation correctly but If you want to stop on path on a defined position if a certain input is in desired state use stop when path feature aka conditional stop.
Fubini
-
It's too difficult to stop at the position for Kuka with SPTP. Now I know why we still use PTP on many other projects. Basically, if the approximation is not possible we should not approximate.
-
I would like to stap just before dropping position. We have a function that checks input from HMI, it is like a breakpoint in debugging. We always use old PTP but for the current project, we use SPTP which makes only issues. Customer choice.
Do you want to always stop, or stop conditionally based on a signal or variable status?
How are you trying to stop "just before the dropping position"? Show the program code. When you try this, what exactly is the robot doing that you dislike?
Do you have a point programmed at that "before" position?
Are you using "single-line" SPTP motions, or Spline Blocks?
-
What do you mean by difficult? I am eager to help but you need to be more specific. This sounds to me like you already speak Italian and wonder now why it does not help you in France. You should at least be willing to learn French.
Spline can solve pretty much any problem you could also solve with traditional motions but you have to learn its tricks and tweaks just as you learned them for traditional programming style and now apply automatically without even thinking about them anymore. But remember when you started out this was probably not the case. In my experince you can achieve most of the times better results in performance, accuracy, ... with spline than with tradional programming and usually if you learn and become a spline expert this better results can be reached in less amount of time you have to invest.
Fubini
-
If the stopping function returns TRUE we should stop in SLIN 1. In that function, we read input and compare it with the argument of that function and if the result is true then stop.
-
new and old motion planners are not the same thing. there is a lot of positives in favor of the new planner. in fact it wins almost every time. and stop condition is one of them.
taking KUKA training is highly recommended but if one wants to do things on their own and ask for help in forum, that is ok. just make sure to post the actual code sample that replicates the problem...
-
Have you ever programmed something in automotive standard?
It is impossible to use something that is not in that standard like spline blocks and stop conds.
-
Have you ever programmed something in automotive standard?
yes, over past few decades i have completed several hundreds of automotive projects from scratch and modified few dozens. so yeah, pretty sure i may have an idea...
It is impossible to use something that is not in that standard like spline blocks and stop conds.
i am sorry to disagree but - that is just not true.
yes there are standards and limitations but they are there for a reason - to make things better, simpler and easier to maintain/troubleshoot. that is the bottom line and not the standard. and while working for many automotive companies, and following their respective standards, i was also able to convince them that change can be good and the standards have been adapted - more than once. so it may be hard or rare but - it is not impossible... and i am speaking from personal experience.
not everything was accepted of course, and it is not quick thing but when one is capable of accomplishing something in different ways and present the advantages of doing something one way vs. another, you may be surprised how many are keen to listen. and some that listen may really like the idea and be in position to make change happen.
also, for each such change, there was few more cases where exception was made - something was accepted even though it deviated from standards in some way because - people like good things.
btw your example is also not well chosen. your own posts suggest that you are already using new motion planner and stop condition, and there is no indication that you are using spline block.
and this debate is going off topic because still, we have not seed your actual code (a working example that demonstrates the problem). for someone who tries to follow prescribed format you could do better by following forum guidelines. it is is likely to yield better results and faster.
Advertising from our partners
