[BUG] SCARA axis homing #27575
Comments
|
This part of the code doesn't get enough attention. When I was last working on a SCARA style robot it had a single free arm, so it had to home both its first and second joints. I've never seen the Morgan and MP SCARA robots do their homing, but the provided code is supposed to have done the right thing at one time. Anyway, it sounds like you'll need to dig into the homing code and debug it to work for your machine, or recruit some help to figure it out. The Marlin Discord server is a pretty good place to find help. Once you have it sorted out it would be great if you could submit the fix to the main project. SCARA is a rare thing, but we do want it to work! |
|
MP_SCARA is quite broken in bugfix 2.1.x I Enabled debugging All the following G28 test where done on a freshly reset board. G28 gives me this log on a standard G28, Z axis moves up and then it errors.. G28 G28 Z works as expected G28 Z G28 Y moves Z up 5mm as expected, but then does nothing. G28 Y G28 X moves Z up 5mm as expected, but then does nothing. G28 X 19:18:41.893 > >>> G28 X0.00 Y199.07 Z0.00 Im not sure that G28 X or Y should actually do anything since there isn't really a X or a Y endstop. |
|
disabling #define VALIDATE_HOMING_ENDSTOPS does allow G28 to complete, but does not move X or Y steppers G28 |
|
This answer that question, only G28 Z will fuction void homeaxis(const AxisEnum axis) {
#if ANY(MORGAN_SCARA, MP_SCARA)
// Only Z homing (with probe) is permitted
if (axis != Z_AXIS) { BUZZ(100, 880); return; } |
|
I want back to 2.0.5 to find one that can home, and I notice that is_scara is not set for the mp_scara, ie 2.0.5 does not limit homeaxis to Z_AXIS So I regressed bugfix 2.1.x to just the following and allowed it to home X and Y And the large arm actually homed, but very very slowly. then after homing it flung itself wild to the other end of travel. no solution yet. |
But there has to be soome way to do it, i look at the video from "How To Mechatronics" he build SCARA and for him MARLIN worked, but his MARLIN not working for me.. |
|
I commented out the return code for SCARA And in my case, the x axis can home in normal speed but it's not guaranteed to back to home position every time, sometimes it just stops before it even hit the endstop. And the y axis is going wild in an unnormal speed. Looking into the homing code, this should be causing the problem: This commands the head to move 1.5f * max_length of each axis And in
The problem of the above code is that this homing target position calculated from 1.5 * max_length of axis is not guaranteed to get a valid arm angles after being sent into MP_SCARA's That's why in my case, the x axis can do homing normally and the y axis can not, because this homing position for x axis happens to be in the reach of the arms but the y axis is not so lucky. Also this homing position for x axis just rotate my arm for under 90 degrees in my case, so when the arm is too far away from the endstop, it just stops before hits the endstop. I think for SCARA, homing should be just keep rotating the arm until the endstops are hit instead of trying to use a far away position and do IK to that position for homing. Not sure my ideas are right, correct me if I'm wrong. :-) |
|
Ascii art of the mp_scara (shoulder joint)<==upper arm==>(elbow joint)<== forearm with a fixed hand==> I have this homing but the arm must be positioned so the upper arm hits its endstop first, ie the forearm should point away from the endstops. (I can see no way around this as the upper arm must be in correct location before the forearm can get near its endstop) diff --git a/Marlin/src/module/motion.cpp b/Marlin/src/module/motion.cpp
index 820089d7ee..4e9cec1003 100644
--- a/Marlin/src/module/motion.cpp
+++ b/Marlin/src/module/motion.cpp
@@ -2467,7 +2467,7 @@ void prepare_line_to_destination() {
#endif
}
- #if ANY(MORGAN_SCARA, MP_SCARA)
+ #if ENABLED(MORGAN_SCARA)
// Tell the planner the axis is at 0
current_position[axis] = 0;
sync_plan_position();
@@ -2665,7 +2665,7 @@ void prepare_line_to_destination() {
void homeaxis(const AxisEnum axis) {
- #if ANY(MORGAN_SCARA, MP_SCARA)
+ #if ENABLED(MORGAN_SCARA)
// Only Z homing (with probe) is permitted
if (axis != Z_AXIS) { BUZZ(100, 880); return; }
#else
@@ -3054,7 +3054,7 @@ void set_axis_is_at_home(const AxisEnum axis) {
}
#endif
- #if ANY(MORGAN_SCARA, AXEL_TPARA)
+ #if IS_SCARA
scara_set_axis_is_at_home(axis);
#elif ENABLED(DELTA)
current_position[axis] = (axis == Z_AXIS) ? DIFF_TERN(HAS_BED_PROBE, delta_height, probe.offset.z) : base_home_pos(axis);Config files needs this added #define FEEDRATE_SCALING (without this the homing feed rate are all over the place) The XY homing procedure is it does a quick home on X and Y ie both move at once (this is required to keep the forearm pointing in the same direction during moving home) Then the upper arm is re-homed, then the forarm is homed. finally scara_set_axis_is_at_home is called to set home position to homeposition = { SCARA_OFFSET_THETA1, SCARA_OFFSET_THETA2} from Configuration.h The homes reliably for me, but I have not tested anything else, especially not the sacra kinematics. |
|
This is my scara |
|
This is the MP_SCARA https://www.thingiverse.com/thing:2487048 which is also what I tested on |
|
Technically they are the same. |
|
MP_SCARA has endstops in a weird location ie.
Yours is much more like https://howtomechatronics.com/projects/laser-engraving-with-diy-arduino-scara-robot-complete-guide/ The video https://www.youtube.com/watch?v=1QHJksTrk8s shows the endstops are independent. So a little different from the MP_SCARA |
|
Yes, i took inspo from video, do you think i need to move endstops? |
|
If I understand correctly, I need to achieve that the first and second axis are homed at the same time? |
|
The patch I provided should make it work for you also. It will still quick home until either the upper arm or forearm endstop is triggered, then it will re home upper arm then forearm |
Great, I'll try it as soon as I get to work. |
Which version of MARLIN do you use? |
I cant find this piece of code, do i need too add it? |
|
After some testing, I found that I need to force the X motor, or X axis, or as Marlin calls it, the A axis, to rotate in the opposite direction. But only when homing. I tried switching the homing direction and also reversing the motor's operation. I think there must be a mistake somewhere or rather a problem in the homing process. I will try more experiments tomorrow. Do you think you could provide me with your config file? |
|
development work is done on bugfix 2.1.x |
Can you send me please your configuratio or full marlin? |
|
Im using a different controller, and no hotend.. |
|
In Marlin is https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/Marlin/src/inc/Conditionals-5-post.h#L288-L295 #if IS_SCARA
#if ENABLED(AXEL_TPARA)
#define PRINTABLE_RADIUS (TPARA_LINKAGE_1 + TPARA_LINKAGE_2)
#else
#define QUICK_HOME // <<------------------------ disable this line
#define PRINTABLE_RADIUS (SCARA_LINKAGE_1 + SCARA_LINKAGE_2)
#endif
#endifthat forces quick home, I would disable this line for your thing. |
|
How did you calcu
how did you get THETA1 and THETA2? |
|
Homing is working, thank you so much, but next problem is here, when i type G0 X0 Y0 scara moves oposite direction, its moving towards switch |
|
so i randomlly fixed problem with moving, but now its laggy, its moving very slowly |
Here is a great article explaining how to get THETA1 and THETA2 in step 12 |
so should I download it and modify it according to my configuration? yeah, at least try and put your config there. For me it works. Marlin 2.1-bugfix seems to be broken (?) |
@Ovaday its locked |
|
@Sejkorka can you write me an email at [email protected], I'll send you it directly. Idk what's not wrong |
Oh, i downloaded it, right now i upload it, we will see |
I uploaded it and not a single movement, the scara doesn't move at all, as if the engines are still off |
|
@Ovaday I have incredibly slow movement |
|
@Sejkorka please adjust configs, you have used my stepper settigns + speeds. I use 5mm/s and true, that's slow af - I modify the speed after the upload with G commands |
i adjusted microstepping, steps and accel |
|
@Sejkorka + feedrate |
|
@Ovaday no succes, speed is great, but first motor doesnt move and second arm is hitting steel rod |
I have one of the axis inverted... You have to invert it yourself in configs back |
|
i thik problem isnt in direction of X motor, because its not moving, Y is moving on right side, but it wont stop |
How do I work: I put manipulator in specific position with full arm length, with a center in the work field. Then send G1 X0 Y250 F1000 And start to work relative from there. |
|
This is in my case Weird "squares" are from marlin 2.1-bugfix |
theoretically i can replicate this, but with smaller Y |
|
G92 sets relative position |
|
No succes, only version which was working littel was 2.1, if its because kinematics, will it be possible replace it with kinematics from 2.1.2.2? |
|
now i uploaded my 2.1 and its working but with wrong moves |
2.1 works for me, but it draws the same squares as the ones that you have shown on photoes. E.g. I got same results with wrong moves. 2.1 is broken in general. I'd try pure 2.1.2.2 on your place + fix kinematics calculation step-by-step |
how do you mean fix the kinematics calculation step by step |
|
Use my excel, calculate some angles and a table how your manipulator should turn to align with this table. You can even use mine, as we have the same config:
Put manipulator at this position, move an arm, check which angles were calculated by Marlin and in which your arm should be and go further:
I'm just robotics engineer + software developer, I know that it's might be easy for me. You can write me on my email and we can schedule some call, I can assist you in config in couple of days, for free. |
This would be perfect. |
|
So close to me! I am from Dresden + speak russian / english / german (no Chech knowledge, sorry :D) |
English will be good for me too. |
|
Note that having the tool somewhere other than the center of the arm adds some extra maths to get the tool position, so for simplicity it is best to keep the tool mount at the arm center, just modifying the length of the second arm as required. // Turning Base SCARA inverse kinematics - similar to MORGAN SCARA
void inverse_kinematics(const float cart[XYZ]) {
// Translate the Cartesian position to SCARA space
const float sx = cart[X_AXIS] - SCARA_OFFSET_X,
sy = cart[Y_AXIS] - SCARA_OFFSET_Y;
// Square of the distance from center to target
const float D2 = HYPOT2(sx, sy);
// Calculate angles. Use simplified equations for equal length arms
float angA, angB;
if (L1 != L2) {
angA = acos((D2 + L2_2 - L1_2) / (2 * L2 * SQRT(D2)));
angB = acos((D2 - L2_2 - L1_2) / (2 * L1 * L2));
}
else {
angA = acos(D2 / (2 * L1 * SQRT(D2)));
angB = acos((D2 - L1_2_2) / L1_2_2);
}
delta[A_AXIS] = DEGREES(ATAN2(sy, sx) + (arm_orientation ? angA - angB : angB - angA));
delta[B_AXIS] = DEGREES(arm_orientation ? angB : -angB);
// Only allow A angles from -90 to +270
if (delta[A_AXIS] < 0) delta[A_AXIS] += 360.0;
if (delta[A_AXIS] > 270) delta[A_AXIS] -= 360.0;
// Return the cartesian Z as-is
delta[C_AXIS] = cart[Z_AXIS];
} |
// Turning Base SCARA forward kinematics - similar to MORGAN SCARA
void forward_kinematics_SCARA(const float &a, const float &b) {
float sin_a = sin(RADIANS(a)), cos_a = cos(RADIANS(a)),
sin_ab = sin(RADIANS(a+b)), cos_ab = cos(RADIANS(a+b));
if (L1 == L2) {
cartes[X_AXIS] = L1 * (cos_a + cos_ab) + SCARA_OFFSET_X;
cartes[Y_AXIS] = L1 * (sin_a + sin_ab) + SCARA_OFFSET_Y;
}
else {
cartes[X_AXIS] = L1 * cos_a + L2 * cos_ab + SCARA_OFFSET_X;
cartes[Y_AXIS] = L1 * sin_a + L2 * sin_ab + SCARA_OFFSET_Y;
}
cartes[Z_AXIS] = current_position[Z_AXIS];
} |
SCARA-Motion.mov |
@thinkyhead |
|
Yes, it looks mathematically equivalent to your code from Jan 24 after adding SCARA_CROSSTALK_FACTOR, just written by someone who gets paid per line of code :p |
Did you test the latest
bugfix-2.1.xcode?Yes, and the problem still exists.
Bug Description
Hi, I have a problem with marlin and its SCARA function, it's my graduation paper, I have already printed the complete scara, most things work, if not at least half.
But what doesn't work is the homing of the "X" axis, the limit switches work normally and M119 shows them as triggers when they should be.
The "X" axis does not homing, it seems to me that once the "Y" axis is homed so is the "X" axis.
Bug Timeline
No response
Expected behavior
No response
Actual behavior
No response
Steps to Reproduce
No response
Version of Marlin Firmware
2.0.9
Printer model
MP_SCARA
Electronics
BOARD_RAMPS_14_EFB
LCD/Controller
No response
Other add-ons
No response
Bed Leveling
None
Your Slicer
None
Host Software
Repetier Host
Don't forget to include
Configuration.handConfiguration_adv.h.Additional information & file uploads
Config adv.txt
Config.txt
The text was updated successfully, but these errors were encountered: