Add support for more axes - i.e.: X, Y, Z, A, B, C axes #120

Closed
ghost opened this Issue Feb 16, 2013 · 11 comments

Projects

None yet

7 participants

@ghost
ghost commented Feb 16, 2013

It would be great if Smoothie would allow for configuring the number of axes, i.e. allow for more than three axes and the axis names i.e. "XYZABC".

Don't know how much effort needs to be put in on the coding side.

A use-case would be @koppi 's six-axes Mitsubishi RM501 MoveMaster robot -- it's an oldtimer robot with a new diy servo controller unit, see here - http://www.youtube.com/watch?v=RJ7PFPT9ocw

What do you think?

@logxen
Contributor
logxen commented Feb 17, 2013

It's on the todo list... upgrading grbl to a 6-axis virtual tool with proper acceleration on the rotary axes is not going to be trivial though. we have been discussing different paths in #smoothieware on irc... I have a 5dof arm with dc servos that I want to get running eventually too. I think we need to get the actuator abstraction in place and then move the actuators out of robot into the arm_solution so that the number of actuators or 'dofs' in hardware can be arbitrary.

@triffid
Contributor
triffid commented Feb 17, 2013

It sounds like you're trying to skip the arm solution.

At the moment we pass in XYZ (position) and theoretically ABC(rotation) and the arm solution performs inverse kinematics and tells the planner where any number of actuators need to be. See the recent RotatedCartesian and Rostock solutions for examples.

The only usage case I can think of is when the arm solution is too complex for the cortex-m3 core, or where the specific actuator positions must be planned with the model in mind, eg http://youtu.be/RnIvhlKT7SY and I think we're not quite there yet!

At best I think some mechanism to suggest positions for specific actuators to the arm solution might be useful in the future.

@triffid
Contributor
triffid commented Feb 17, 2013

In terms of implementation I think we can change Robot to an actuator pool for best results, with two types of actuators- linear and rotary.

The grbl code will need some thorough pondering but my instinct is that we can have limits on jerk, accel, etc for each actuator, then find each actuator's jerk limit proportional to the vector delta for that axis and apply the minimum to each junction. The same can be done for accelerations along each segment.

A method for hinting would be really useful; eg Soupcup allows the slicer to provide a D word which is the length of the segment in XYZ so we don't have to do a sqrt in firmware.

@ghost
ghost commented Feb 18, 2013

For me a temporary solution could be to add axes ABC as cartesian/linear axes in Smoothie and do the hard math on the host computer side, i.e. generate gcode.

In this way, we can test complex behaviour with kinematics really fast, and maybe later on add the functionality to the Smoothie code base.

What do you think?

@mohag
mohag commented Nov 11, 2014

Another use case is a foam cutter...

Two two axis setups...

Being able to use XY + AB would be a good start, having a possibility to have the normal arm_solution type logic on each can be interesting... An extreme solution would be CoreXY for X and Y and a Morgan-style SCARA for A and B...

@mohag
mohag commented Nov 12, 2014

Thinking about it, it would be interesting if you can map G-code variables to axises via the arm-solution type transforms...

One way would be that each motion type takes certain configurable G-code axises as input and output to steppers (possibly with the option to chain them) (outputs can likely then also be defined as say linear / rotational (say with steps per degree?)...) (Different types with different endstops type configurations...) (Not sure if that would be necessary...)

For the current robot code, they have these fundamental relationships:

  • Cartesian - 1 axis in, 1 linear output
  • Delta - 3 axis in, 3 linear outputs
  • Morgan SCARA - 2 axis in, 2 rotary outputs
  • H-bot - 2 axis in, 2 linear? outputs
  • Rotatable cartesian - 3 axis in, 3 out (linear?)

So to control a Morgan, you would have X and Y go through the robot code and output to alpha and beta and Z defined as a direct linear axis.

Extruders can likely also run on top of this type of setup (possibly with a special output to allow for auto-retraction, etc...)

This is more an idea for a future major version than an easy quick goal...

So for the foam cutter, the definition would look something like this: (Using X and Y for one end and A and B for the other) (Settings for each driver keeps current setup)

gcode_axis A B X Y
linear_axis_enable 4
linear_axis_1_input A
linear_axis_1_ouptut gamma
linear_axis_2_input B
linear_axis_2_ouptut delta
linear_axis_3_source X
linear_axis_3_ouptut alpha
linear_axis_4_input Y
linear_axis_4_ouptut beta

A theoretical setup for a Morgan + H-bot foam cutter would be something like:

gcode_axis A B X Y
h_bot_enable 1  # number of processors of type
morgan_scara_enable 1
h_bot_1_input_x A
h_bot_1_input_y B
h_bot_1_input_a gamma
h_bot_1_input_b delta
h_bot_1_setting_a reasonalbe_value
morgan_scara_1_input_x X
morgan_scara_1_input_y Y
morgan_scara_1_output_theta alpha
morgan_scara_1_output_psi beta
@arthurwolf
Contributor

Hey.

Yep. That's kind of what we are aiming at ultimately.

Lots of work to be done before we get there though.

Cheers :)

On Wed, Nov 12, 2014 at 7:01 PM, mohag notifications@github.com wrote:

Thinking about it, it would be interesting if you can map G-code variables
to axises via the arm-solution type transforms...

One way would be that each motion type takes certain configurable G-code
axises as input and output to steppers (possibly with the option to chain
them) (outputs can likely then also be defined as say linear / rotational
(say with steps per degree?)...) (Different types with different endstops
type configurations...) (Not sure if that would be necessary...)

For the current robot code, they have these fundamental relationships:

  • Cartesian - 1 axis in, 1 linear output
  • Delta - 3 axis in, 3 linear outputs
  • Morgan SCARA - 2 axis in, 2 rotary outputs
  • H-bot - 2 axis in, 2 linear? outputs
  • Rotatable cartesian - 3 axis in, 3 out (linear?)

So to control a Morgan, you would have X and Y go through the robot code
and output to alpha and beta and Z defined as a direct linear axis.

Extruders can likely also run on top of this type of setup (possibly with
a special output to allow for auto-retraction, etc...)

This is more an idea for a future major version than an easy quick goal...

So for the foam cutter, the definition would look something like this:
(Using X and Y for one end and A and B for the other) (Settings for each
driver keeps current setup)

gcode_axis A B X Y
linear_axis_enable 4
linear_axis_1_input A
linear_axis_1_ouptut gamma
linear_axis_2_input B
linear_axis_2_ouptut delta
linear_axis_3_source X
linear_axis_3_ouptut alpha
linear_axis_4_input Y
linear_axis_4_ouptut beta

A theoretical setup for a Morgan + H-bot foam cutter would be something
like:

gcode_axis A B X Y
h_bot_enable 1 # number of processors of type
morgan_scara_enable 1
h_bot_1_input_x A
h_bot_1_input_y B
h_bot_1_input_a gamma
h_bot_1_input_b delta
h_bot_1_setting_a reasonalbe_value
morgan_scara_1_input_x X
morgan_scara_1_input_y Y
morgan_scara_1_output_theta alpha
morgan_scara_1_output_psi beta


Reply to this email directly or view it on GitHub
#120 (comment)
.

Courage et bonne humeur.

@koppi
koppi commented Jun 18, 2015

Hi, I did not have a look into Smoothieware's source code for the last two years. Is support for six axes already in the source code? I implemented the 5-DOF kinematics of my Mitsubishi Movemaster RM-501 II robot in a small program, see: https://github.com/koppi/rm501 I'd like to integrate the 5-DOF kinematics into Smoothieware.

@arthurwolf
Contributor

Hey !

On Thu, Jun 18, 2015 at 7:12 PM, Jakob Flierl notifications@github.com
wrote:

Hi, I did not have a look into Smoothieware's source code for the last two
years. I support for six axes already there?

No.
It's quite a bit of work to add, but if you are interrested in doing so,
I'll gladly assist you.

I implemented the kinematics of my Mitsubishi Movemaster RM-501 II robot in

a small program, see: https://github.com/koppi/rm501 I'd like to
integrate the 5-DOF kinematics into Smoothieware.

Awesome :)

Cheers.


Reply to this email directly or view it on GitHub
#120 (comment)
.

Courage et bonne humeur.

@wolfmanjm
Contributor

This is potentially fixed with PR #989

@openhardwarecoza

Awesome awesome awesome! Guys, please help test! #989

@wolfmanjm wolfmanjm closed this Sep 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment