6 axes support

[gear2nd-droid]

The current control axes of klipper are three degrees of freedom (XYZ). In contrast, I have extended the control axes to 6-DOFs of XYZABC by adding roll, pitch, and yaw rotation.
In fact, with this extension, I am able to control position and posture with 6-axis control.
https://www.youtube.com/watch?v=4UNqXRcZTqw
Having 6 DOF facilitates non-planar printing because of the ability to control position and orientation.

The pull request includes only the extension of klipper to 6 control axes (except for the kinematics in the video above). However, due to the increased number of control axes, there is still a risk of problems with various modules at this stage. Therefore, you may reject the request.

If you would like, would it be possible for you to create a branch of the 6-axis extension on the main line? Or, if there are people on Discourse or Discord who are interested in the 6 axis, would it be possible to direct them to my fork?
https://github.com/gear2nd-droid/klipper
I hope you are considering 6-axis control as a direction for future expansion of klipper.

[dmbutyugin]

Thank you, this is indeed an interesting direction of development! Moreover, there are existing printers that could, in theory, benefit from this, for example ratrig v-core 3. That said, I had high-level some questions and concerns about the implementation (I only went through the code very briefly, though):

1. The 3 coordinates are added in many places as extra Euclidean coordinates, for example into junction deviation calculation. I agree that taking changes in the orientation coordinates during cornering into account somehow is necessary, but since they are not spatial coordinates, it is likely that this may negatively affect cornering velocity computation. Probably we should leave junction deviation calculation be and instead implement some different kinematic limits for corners when orientation is expected to be changing.
2. Right now the 3 orientation coordinates are linearly interpolated for the move. However, such interpolation does not result in a smooth motion of the coordinate system (and therefore the object): for example, constant speed motion will not result in constant rotation speed motion. There are other techniques appropriate for this task, such as quaternions (SLERP) or Euler angles (though they are prone to gimbal lock). Though I don't have much experience in this area, so, for example, how do 5/6-axis CNCs implement this?
3. This change only adds 3 extra coordinates, but there are no kinematic that support that, right? Or maybe because the branch has conflicts the diffs are not appearing for delta kinematics in 'Files changed' tab. Either way, a support on some existing kinematics (e.g. that delta, or ratrig v-core 3 with a kinematic bed) may facilitate experimentation.

As it is, the branch is probably not suitable for integration into the mainline Klipper yet, but having it available for the general audience can attract attention, getting more feedback, and maybe even get some support in slicers (that would certainly be amazing). So, thanks for your efforts to put it together!

[gear2nd-droid]

Thank you for your valuable input. I expect that the appropriate calculation of the ABC axis will change depending on the mechanism (switch in config), but I was not sure what form would be best, so I am implementing it as it is now.

I am planning to develop a kinematics that will bedtilt in coreXY with 3 Z-axes. However, I have not been able to start because I do not yet have a printer for this kinematics.

Translated with www.DeepL.com/Translator (free version)

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[github-actions]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.