UArm not calibrating position

uArm Swift (Pro) Troubleshooting
19

@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!

20

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

21

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

22

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

23

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.

24

@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.


25

Hi @Tony,
My problem is not that the arm is in the wrong mode. Sending M2400 codes does not do anything to fix this issue. My problem is that the the code which reads and interprets data from the AS5600 rotation sensor thinks that the sensor is in the wrong position. its perception of the sensor data is offset by an small amount (only a few degrees) but this is enough to throw the Z-Axis off by as much as 10mm over the range of the arm. This is obviously not an acceptable level of accuracy, as I can’t use the arm for 3D printing, which is the main reason I bough the arm.

As an engineer I had a look at the firmware to see how the proprioception / reverse kinematic functions were calculated. Here is my understanding of the firmware (with added comments) and how I believe it could be improved to fix my problem. I am referencing the firmware as of commit 43f84e47d9e61aa879c334c4dab22dbbc2ff3eca / v3.1.9 of the dev branch in GitHub - uArm-Developer/SwiftProForArduino: Swift Pro Firmware

Here is the code that gets the X, Y and Z values from the angles of the different motors in marlin/uArmAPI.cpp

  unsigned char getXYZFromAngle(float& x, float& y, float& z, float rot, float left, float right)
  {
  	// stretch is basically radius
  	double stretch = MATH_LOWER_ARM * cos(left / MATH_TRANS) + MATH_UPPER_ARM * cos(right / MATH_TRANS) + MATH_L2 + front_end_offset;
  	double height = MATH_LOWER_ARM * sin(left / MATH_TRANS) - MATH_UPPER_ARM * sin(right / MATH_TRANS) + MATH_L1;
  	y = -stretch * cos(rot / MATH_TRANS);
  	x = stretch * sin(rot / MATH_TRANS);
  	z = height - height_offset;

  	return 0;    
  }

Here’s a diagram of how the stretch trigonometry works:

This function uses the angle values from float get_current_angle(uint8_t index) in marlin/uArmCalibration.cpp which reads the value from the ADC connected to the AS5600 rotation sensor and calculates the angle by comparing those values with a hard-coded reference_angle and reference_angle_value which is stored in EEPROM (non-volatile memory). The reference angle and reference angle value are two values that allow you to map from the rotation sensor output value to a known angle. I can imagine that when the arm is manufactured / calibrated, the arm is placed in a particular reference position, and the raw sensor values for each axis are stored in the reference_angle_value address in the EEPROM, which persists through firmware updates.

What has happened in my case is that the uArm I received was either not calibration correctly or had suffered a fault in transit that caused the value being read from the angle sensor to be offset by a small amount, meaning that the uArm cannot correctly determine its position in space. Perhaps the gear box slipped or the voltage supplied to the angle sensor was different during calibration. This fault means that my device is not usable at the moment.

The evidence of this is that when I position the head of the arm with all attachments removed at points A, B and C on the callibration / positioning sheet, the positions of my the head according to uArm Studio are:

A: [169.9, 0, -27.33]
B: [202.92, 0.93, -19.58]
C: [282.49, 2.16, -16.1]

I expect that after heavy use over the lifetime of the arm, this kind of fault would occur on most devices. I would suggest that a “calibration mode” be added to the uArm Studio software so that this fault can be corrected.

Do you agree that there is a potential for the device to become mis-aligned with it’s own sensors? And that there should be a way for the user to correct for this?

Thanks

26

Hi derwentx, thanks for your details. According to the data of ABC points, I do think the arm is not working well. Did you reset the arm by power which might make it correct? If the problem occurred every time, it must be the caused by calibration issue since we test all the joints one by one during assembling. While calibration is not complex and we would like to offer you the method. Before that, could you upload a video to show your problem clearly so that we could make sure the problem of robot. Thanks

27

Thanks @tony
I’d love to know the calibration process so that I can calibrate my arm from home.
Here are some videos explaining my problems:

To be clear this level of warp is probably fine for drawings but there is too much warp for me to be able to confidently attempt to 3d print something. I think the hardware is extremely well made, and I’m very happy with it, I just hope that the firmware can reach the same quality soon.

My 3 squares json file:

{"objects":[{"type":"path-group","originX":"left","originY":"top","left":352,"top":72,"width":34,"height":34,"fill":"","stroke":"black","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":2.94,"scaleY":2.94,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"nonzero","globalCompositeOperation":"source-over","transformMatrix":null,"paths":[{"type":"rect","originX":"left","originY":"top","left":26,"top":56,"width":32,"height":32,"fill":"","stroke":"#000","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":1,"scaleY":1,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"evenodd","globalCompositeOperation":"source-over","transformMatrix":[1,0,0,1,-25,-55],"rx":0,"ry":0}]},{"type":"path-group","originX":"left","originY":"top","left":452,"top":72,"width":34,"height":34,"fill":"","stroke":"black","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":2.94,"scaleY":2.94,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"nonzero","globalCompositeOperation":"source-over","transformMatrix":null,"paths":[{"type":"rect","originX":"left","originY":"top","left":26,"top":56,"width":32,"height":32,"fill":"","stroke":"#000","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":1,"scaleY":1,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"evenodd","globalCompositeOperation":"source-over","transformMatrix":[1,0,0,1,-25,-55],"rx":0,"ry":0}]},{"type":"path-group","originX":"left","originY":"top","left":251,"top":73,"width":34,"height":34,"fill":"","stroke":"black","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":2.94,"scaleY":2.94,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"nonzero","globalCompositeOperation":"source-over","transformMatrix":null,"paths":[{"type":"rect","originX":"left","originY":"top","left":26,"top":56,"width":32,"height":32,"fill":"","stroke":"#000","strokeWidth":1,"strokeDashArray":null,"strokeLineCap":"butt","strokeLineJoin":"miter","strokeMiterLimit":10,"scaleX":1,"scaleY":1,"angle":0,"flipX":false,"flipY":false,"opacity":1,"shadow":null,"visible":true,"clipTo":null,"backgroundColor":"","fillRule":"evenodd","globalCompositeOperation":"source-over","transformMatrix":[1,0,0,1,-25,-55],"rx":0,"ry":0}]}],"background":""}

Thanks

28

I have the same problem with the Z axis. I opened a new thread that links to this one, because I only found it after posting.

Sorry about that.

I hope this is isn’t another crowdfunded project where the hardware is awesome and the software is a letdown that makes it of limited use, in the end. It would be the third for me after the ZCam E1 and the FOVE VR headset. :frowning:

.mm

29

More testing required, but my uArm is working much, much better. Smooth motions, repeatable, and predictable. Precision and repeatability to be determine, but much less aggravated now. Thanks @tony and @poppy.

1 Like
30

Same here looks very promising now! Big thanks @tony!

31

Here’s what I get:

It makes a mess on the thin side as the print head is pushed into the bed surface. On the other side the plastic is dropped from a height of several mm. There is a 3mm difference across a 4cm bed.

I wonder if a raised bed would fix the problem? Anyone?

Michael

32

Hi @derwentx @Michael50 , We just finish the instruction of re-calibration. And we also find out that during the factory calibration there might be some situation which affect the accuracy of calibration. Please try to calibrate it again as the following instructions. THANKS
https://drive.google.com/drive/folders/0B-L-tCvknXU9ZXBweVlYRXd5VHM

33

Thanks @tony ,
I’ve followed the calibration instructions, and it has improved the accuracy of my uArm. Now instead of being out by 10mm on the Z-axis, it’s only out by 2mm, and my pen doesn’t lift off the paper as much. Thanks for improving the firmware.
I’m still having issue with long straight lines being warped as you can see from this video: uArm Swift Calibration progress #3 - YouTube
I’m also starting to have issues with my power supply where my arm is randomly resetting even when not connected to data. I believe this is an independent issue though. uArm Swift Pro issue #4 - power supply - YouTube
Thanks.

34

One thing I have found is that the power cord leading in to the transformer is significant regarding the power issue. Changing to one which has has thicker cords or is shorter may help (assuming you are oh using the one that came with the arm).

35

Thanks for the suggestion @Hjelt
The mains cable that came with mine did not fit my Australian socket so I used a different mains cable.
I tried a second mains cable, and although it did last longer before randomly dying, I’m still having the issue.

36

Hey @Tony
I’ve written a python script that can do the the B Angle Calibration for the user ( and display other callibration data ) let me know if you think this is useful and I can submit a pull request for pyuf.

37

Hi @derwentx, the pen holder seems on the left side of servo. It should be in the middle. Are you still dealing with the random resetting? It might be caused by the adapter, if so we would send you a new one, thanks

38

Hi, I’ve used your calibration script - mine seems better now.

There are two calibration options - “reference angle” and “reference angle B”. I assume I place the head on point “B” using the positioning sheet for “reference angle B”, but where for the first one?

Thanks so much
Ben