UArm not calibrating position

I am having issues as well. It looks like it is trying to go beyond its limits… It will recreate the saved program, just not from a repeatable starting point… HELP

I can get it to print with difficulty. It is very challenging to find the place the printer thinks it is, and this has to be readjusted when starting EACH print; it doesn’t even try to start in the same place, even when the power remains on. It isn’t just important to get the print head on the bed, but to get it to travel level and also for it to correctly control the x axis with it’s two arm servos; if it is incorrect, I end up with inequal X:Y such that circles are not circular.

Still waiting on some input from the manufacturer…?

Same - any help please?

@smence, Please send the command “G0 X200 Y0 Z100 F5000” to the arm without plugging the 4th axis, so that we could make sure if the main body of uarm is good. If the arm is not working well, please power off(the orange button) the arm to reset the system, then try again. Because sometimes, when arm moves to the limiting position, the steppers will lose the steps and it makes the angle completely incorrect. The best way to solve it is reset the system by power button. Then try the command above again.

I will also try this. Is using blockly adequate for the test?

Updated firmware, removed suction. It moves more smoothly but it looks a lot like the steppers are not wired properly. Drawing a square in the drawing program results in lots of movement in the Z axis.

Hi Tony,
thanks for the reply. Please answer:

  1. A Blockly “RESET” command is not possible out-of-the-box, as it tries to reach an impossible position. Are you going to fix that soon?
  2. Does the uArm Pro have absolute encoders? If so, why it does not sense when the stepper motors are loosing steps? Will this be improved in a future firmware release?

Besides of that, I am very pleased with build quality and packaging.

Best regards,
Marco

Overall build quality seems excellent. In addition to the reset issue, my machine moves in the Z axis even when asked to move at a single height.

What is the plan for servicing apparently broken hardware?

Hi MarcoWue,
1, Our engineer are working on it, it’s a bug of the blockly. Sorry for that.
2, Pro has the 12bit magnetic absolutely encoders in each joint, while now it works only after power on to detect the original position of each joint, it won’t work during the movement. And as you said we are working on it to make the encoder much more helpful during the movement.
Thanks for your suggestion, and feel free to ask any question!
Tony

Hi Sean,
Sorry for the issue you are getting.

Basically, if the robot lose the step, the best way to make it back to work is power off the robot by power button and then power on it again. Since reset will make the encoder work once and get the correct joint data.

@all
If anyone get some weird issues, would you please try to build a blockly demo and take video for us so that it would be helpful for us to find the problem.


or if you have tried to engrave something by laser, it helps a lot as well.
Thanks!
Tony

1 Like

Here’s a video of the arm in a mild case of misbehavior this morning. This running the blockly program listed above.

Arm motions are inconsistent from run to run, but in this one you can hear the arm hitting the limits to upward motiion.

@tony @Poppy

I’ve been working in this space for a while (ported a gcode interpreter to Arduino with serial drip feed for a home made CNC, am on my 3rd CNC router, and have a python software stack for generating and manipulating gcode). I have high hopes for the uArm, but am increasingly frustrated. :frowning:

@Sean_True, @tony

I tried the blockly demo provided above and made it loop twice, and ran two tests - here’s how it came out: calibrating Swift pro

I didn’t get the clack-clack sound, but did come across it on a different blockly program.

Tony, i made some suggestions for ufactory to consider on collecting diagnostic information and faster troubleshooting.

BR
ebto

Hi Sean, really sorry for the trouble you are getting! One more thing we want to confirm, did you rest the arm before the blockly demo? If so we would send you a replacement since we are sure the arm got some hardware issue. Very sorry for the inconvenient!

Thanks a lot for your demo, your arm works perfectly, we would like to show the video to more backers. Thanks a lot!

@tony

I did both power-off resets, as well as adding a reset to the beginning of the blockly code. I also tried changing the location of the arm at power up. I could detect no pattern in the resulting failures – they just seemed inconsistent. The video I posted above was picked because you could hear the limit of motion failure in what should have been a safe program.

Thanks for your offer for the replacement, and I will be very excited to get it. You may still be the first 3d printing capable machine I’ve gotten from kickstarter, after participating in two others that have failed to deliver anything!

Got it. Don’t worry about the issue, we will handle it. Sorry for the trouble you are getting.

I’ve done startups my whole life, though I only did hardware once. I’m sympathetic to the problems, if (as a customer) impatient.

Hi @tony
[let me know if I should post in a new thread]
I’ve just recieved my uArm Swift Pro and I’ve been having similar problems with my Z-axis.
When I am drawing with a pen, at the points with greater radius the pen sticks in to the paper, and at points with smaller radius the pen lifts off the paper.
I turned the device on and off and gave the blockly demo code a go, but this did not fix my problem.

Is there any way to re-callibrate my arm?
Here is my device info from pyuf:
[‘SwiftPro’, ‘3.3.0’, ‘3.1.9’, ‘3.1.9’, ‘D43639DF6537’]
I am using uArm Studio v1.1.12 with firmware v3.1.9
Thanks

Same problem here. Z-axis is not “straight”. Moreover, for any position on X lower than 100, robot reach physical minimum and crazy noise and gear lose happens.

@Lalex @derwentx
Since the inverse kinematics are based on the front joint of arm (the red circle below), while when we run the arm the point we are concerning about is the white one. And for different function the distance between red and white is not the same and it needs adjusting or it will make the line not straight enough. What’s more, you could find a command which is designed for the different mode (the picture is from the quick start guide). And by the way, for the current uarm studio, it do not support switching mode yet. We would add it later. Thanks and hope my answer could help you.