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 https://github.com/uArm-Developer/SwiftProForArduino/tree/develop
Here is the code that gets the X, Y and Z values from the angles of the different motors in
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;
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_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?