Six axis robots

I built the THOR robot arm. I also work at nScrypt, Inc. and we have a trunnion 5 axis and gantry 6 axis machine and we develop 6 axis software for these machines. Is it possible to run klipper on the fysetc spider or two SKR boards and control a 5 or 6 axis machine? 7 with an extruder or manipulator like a grabber.

The idea would be to use 6 axis CAM or other processors (such as nScrypt’s) to generate gcode like:

G1 X10 Y20 Z30 RS1 RT45 RR97 F100

That would move through the 6 axis movements in the same manner than norma klipper moves from one xyz to another xyz, just with more axes being simultaniously controlled.

1 Like

I’m not aware of anyone currently working on this.

At a high-level there are a couple of different ways to handle additional axes - the simplest is to alter the orientation of the toolhead in commands and movements separate from normal XY moves (so called “3+3” control) - the more advanced mechanism provides simultaneous XY and tilt in a single move (so called “full 6 axis” control).

The former (“3+3”) may be possible to implement today with manual_stepper config sections (see docs/Config_Reference.md for details) and/or minor kinematic updates.

The latter (“full 6 axis”) would require significant work. Off the top of my head, it would involve obtaining a 6 axis slicer, modifying Klipper’s g-code move parser to support the additional axes, updating the toolhead look-ahead code to track and handle the additional axes, updating the trapq code to track the additional axes, and adding the kinematic math functions for the additional steppers.

Cheers,
-Kevin

Hi Kevin, I can’t express how honored I am that you replied. Yes, these are good ideas. nScrypt where I work is doing similar work. I am looking to get my THOR robot arm going on a platform less expensive than what nScrypt runs on. Klipper is obviously the best 3DP software and runs our 12 vorons. I will definitely create a gcode adapter to do the manual_stepper route. Full 6 axis will be the dream.

Hi @koconnor ,
Thanks for the insight that you’ve provided above.
I’m trying to do as you describe for ‘full 6 axis’.
How would you approach debugging?
I’m using VScode with the remote extension and would like to use the built in debugger.
I would like to break the code up and test in sections:

  1. gcode.py and gcode_move.py
  2. toolhead.py
  3. trapq.c
  4. forward kinematics + reverse kinematics in chelper

Do you agree with the approach of testing in sections?
If so, how would you make sure that all the inputs/imports are available for each section?
If you think appropriate to testing the whole code together, how do we force G-code moves?

I will run the regression test code, after the code has been debugged.
Or, instead, could the regression test code be used to debug?

As you can probably tell, I don’t have a lot of experience with this stuff but I’m eager to learn and try it to make it work if I can get a little bit of coaching from the experts.

Thank you,
Adam

Thanks Kevin. This does give me somewhere to start lookng in to the klipper code.

Did you make any progress on this? I’m trying to do the same thing