Yes, I think I got side tracked, for now limits of vel acc should be enough.
Jerk comes later, and position later still, it's just that as you go trough
things, you know have a problems here and there, but I have to restrain myself
to stay in scope.
Regarding that will refactor what has been done so far, and try to reuse the
current kinematics files, but run them in uspace,
Tending towards
Dynamic Loading with dlopen
For uspace/simulator builds where RT modules are actually shared libraries:
// Load the existing kinematics module
void *handle = dlopen("trivkins.so", RTLD_NOW);
kinematicsInverse_t kins_inverse = dlsym(handle, "kinematicsInverse");
// Call it directly
kins_inverse(&world, joints, ...);
Pros: Uses exact same binary
Cons: Only works in uspace builds, needs careful handling of HAL context
Thoughts?
On January 27, 2026 4:48:07 PM GMT+08:00, "Robert Schöftner" <[email protected]>
wrote:
>On Di, 2026-01-27 at 07:49 +0800, Luca Toniolo wrote:
>> Thank you for all the input guys, will be looking in detail when
>> Beziers
>> time come, but arcs will remain arcs, beziers are to smooth out point
>> clouds and sharp corners which are not arcs to begin with.
>>
>
>it might make sense to also use C² continuous geometry on a tangential
>transition from line to arc or arc to arc, didn't think about that too
>much though.
>
>the discussion around the beziers also had in mind how to represent the
>path to be machined. but as said bezier splines are not suitable as the
>only datastructure representing the machine path. lines are
>representable but if you follow the links I posted yesterday, arc
>segments are only an approximation, even for higher order bezier
>polynomials. which is to be expected, circles and arcs are not
>polynomials (of a parmeter).
>
>> For phase 1.2 Joint limit pre-calculation, the joint limits, I
>> already
>> did a small component that can predict if the executing gcode will
>> reach
>> joint limits at gcode load time, I was thinking, this can be used to
>> remove the need to set AXIS limits, axis limits IMO should be
>> inherited
>> from joint limits + IK, you set joint limits (they are the hardware
>> reality), and axis limits become derived from that through inverse
>> kinematics. For trivkins it's trivial, for non-trivkins the "axis
>> limits" concept doesn't even make sense in Cartesian terms anyway -
>> the
>> reachable workspace is a complex volume depending on the pose.
>>
>
>that makes sense. it could be argued that the order of trajectory
>planning / feedrate planning and kinematics should be exchanged, that
>regularly comes up in informal discussions ;-).
>
>> I also want to implement something in the gcode, to check if a
>> position
>> is reachable before actually going there. Thinking of G1.1 G2.1 G3.1
>> etc
>> as "dry run" variants of motion commands - same syntax, same path
>> planning through the TP and IK, but instead of commanding motion, it
>> returns what would happen.
>>
>
>here I must admit I don't understand what you mean or what that would
>accomplish.
>
>in exact stop mode, every position is supposed to be reachable, else
>the program won't run in any case. in path blending mode with
>tolerance, you have some leeway, but if push comes to shove, you can
>always reduce feedrate or come to a full stop.
>
>also this sounds a bit like simulation? if you want to use this as a
>debug tool, you can easily run the interpreter out of band and have it
>call your own supplied canonical motion etc... routines.
>
>creating programs like this would be tedious and error-prone and would
>be way too complicated to just check a program for machine limits.
>
>>
>> For 5-axis non-trivkins you'd get which actual joint would fail, not
>> some meaningless "axis" number, because the IK ran and found joint 4
>> would hit +175° for example.
>>
>
>that also should not need any special new command set. it sounds
>strange to me that an error of an exceeded joint limit would not be
>reported but get translated back to an axis number.
>
>
>> Not sure if this fits in the TP2 scope or should be a separate PR,
>> wanted to get your thoughts before going further
>>
>
>in this case i think it is better to err on the side of more pull
>requests that are self-contained than one "big beautiful bestest patch
>of the world".
>
>--
>Robert Schöftner <[email protected]>
>
>
>_______________________________________________
>Emc-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/emc-developers
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
