huggingface
fail on calibration
After carefully calibrate, I run the copy process, and met multiple failures. Now I print the angle, and just found that the main leader arm shows:
print(leader_pos) [ -89.82422 -88.94531 -87.802734 -92.021484 -176.13281 -81.29883 ]
when in the zero pos, and shows:
print(leader_pos) [ -2.9003906 6.9433594 -187.73438 -4.921875 -261.82617 -143.96484 ]
when in the rotated pos. What could possiblly happened? I followed the instruction 7 carefully, and now am helpless and have no idea. pls save me
after sevral times repeating, it works now, but the second motor of the follower always hold to the max value 78.134766:
follower_pos = robot.follower_arms["main"].read("Present_Position") print(follower_pos) [ -2.4609375 78.134766 174.375 -90.17578 -5.2734375 0.7910156]
leader_pos = robot.leader_arms["main"].read("Present_Position") print(leader_pos) [ -2.0214844 32.871094 123.22266 -98.96484 -2.3730469 -0.87890625]
follower_pos = robot.follower_arms["main"].read("Present_Position") print(follower_pos) [ -2.4609375 78.134766 174.28711 -90.17578 -5.2734375 0.7910156] leader_pos = robot.leader_arms["main"].read("Present_Position") print(leader_pos) [ -3.8671875 -7.998047 11.777344 -38.496094 -2.3730469 -0.87890625]
follower_pos = robot.follower_arms["main"].read("Present_Position") print(follower_pos) [ -2.4609375 78.134766 174.28711 -90.17578 -5.2734375 0.7910156] leader_pos = robot.leader_arms["main"].read("Present_Position") print(leader_pos) [ -7.2070312 136.49414 60.46875 102.48047 -2.3730469 -0.9667969]
other joints are all good, so can't find what happened
Hi, it looks like an issue with your follower's 2nd motor (XL430). The blinking light shows up when it's overheating because of too much torque/tension. The motor then blocks itself to prevent further damages. Try to unplug the arm, let it cool down and try again after waiting a bit. Let us know if it continues to happen. cc @Cadene
Sevral times tries have been made, including restarting even restoring by dynamixel wizard 2, but failed. things are strange when after configuring, in the rest position:
leader_pos = robot.leader_arms["main"].read("Present_Position") print(leader_pos) [ 1.8457031 135.35156 179.29688 -9.140625 -7.734375 18.105469 ]
follower_pos = robot.follower_arms["main"].read("Present_Position") print(follower_pos) [ -0.43945312 82.5293 175.95703 -9.228516 -3.1640625 50.44922 ]
look at the 82.5293, which make the motor block at the max position.(the ture value should near 135, at least over 90)
I had similar problem with motor being in wrong position. But for me recalibration worked well. What I found also is that for everything related to motors parameters Dynamixel software is quite useful: https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/ There you can look into state of you motors in more detaiils, do factory reset or firmware update
I had similar problem with motor being in wrong position. But for me recalibration worked well. What I found also is that for everything related to motors parameters Dynamixel software is quite useful: https://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_wizard2/ There you can look into state of you motors in more detaiils, do factory reset or firmware update
factory reset and firmware recovery both tried but still failed
I guess it's because the tolerance when calibrating. Sometimes when I tried, the follower's 2nd motor will start (rest position) at a vertical position immediately, and follow the leader normally (except an angle of nearly 45 dgrees). But I do follow the pictures and instructions! it's wired
ok somehow I successed. I opened the Dynamixel wizard2, and manully set the "homing_offset" value, to let the motors of two arms show same dgree in same position, respectively. But there must be some thing wrong, right?
Could be... the error I had is described in DynamixelMotorBus class:
raise JointOutOfRangeError(
f"Wrong motor position range detected for {name}. "
f"Expected to be in nominal range of [-{HALF_TURN_DEGREE}, {HALF_TURN_DEGREE}] degrees (a full rotation), "
f"with a maximum range of [{LOWER_BOUND_DEGREE}, {UPPER_BOUND_DEGREE}] degrees to account for joints that can rotate a bit more, "
f"but present value is {values[i]} degree. "
"This might be due to a cable connection issue creating an artificial 360 degrees jump in motor values. "
"You need to recalibrate by running: `python lerobot/scripts/control_robot.py calibrate`"
)
But in your case misalignment is not outside of nominal range (just 45 degrees), so you don't receive such an error.
@aliberts I have the same issue, and I don't get the point of the calibration process. If the original design of this set of arm is just have some flaws need to be corrected, the current version is just terrible. The calibration program never get the job done, so no matter how many times you have tried to recalibrate, only causes your robot goes crazy trying to flip its position and being trapped to a locked position. There must be some critial errors in the calibration process. But apart from that, I'm just don't get the idea why there must be a calibration before the robot arm can be teleporated. is it trying to fix some of the mistakes during the assembly process such as accidentally turned the servo, or just to correct the errors between the two arm? If it's the former, the entire calibration can be totally pointless since the servo will just do a harsh flip, when the angle passes 180 degs then turns into -180 degs, and vice versa; It just impossible to be corrected if the servo works under position conrol mode, and factory reset won't help either since you will find the plate do have a slot or key to ensure it's being installed at the right position, if you have took the servo apart. Or the calibration has to be done due to some precision issue, I donl't think that's a must either. since all the parts are being fixed with screws, they should already precise enough to do these block picking job; if you do wants that precise, this set of robots shouldn't being made wih fdms, and these servos aren't capable, too. From my point this calibration program should be deleted. If someone wants to fix their assembly mistakes, they can just teleporate it first, and all the mistaken steps will be clear; currently this feature is unfunctioning, adds more mess, and can't be disabled.
@Lemin2 I understand your frustration. Could you send a video of you doing the calibration procedure of both arms? You might be doing something wrong, and we might be able to unblock you. If the issue persiste, we can have a call on discord.
For the next version of the arms (the pair cost 200$), we don't need a calibration procedure anymore! We are able to achieve this because there is only one way to assemble the robot. Unfortunately, it is not the case for Koch v1 :/ Even worse, the motors of the leader arm are not capable of lifting their own weights, so we can't have an automatic calibration procedure. The only option is the manual calibration and we made a video about it: https://www.youtube.com/watch?v=8drnU9uRY24
We aim to make simple things, but it requires a few iterations.
@littlecay @Cadene @aliberts @JahJajaka I guess i just found where went wrong. Looking the generated calibration file, it's ridiculous to see that some of the servos are set to reversed mode. To fix this just set all the 1 to 0 in the drive_mode array, for both arm.
@littlecay @Cadene @aliberts @JahJajaka I guess i just found where went wrong. Looking the generated calibration file, it's ridiculous to see that some of the servos are set to reversed mode. To fix this just set all the 1 to 0 in the drive_mode array, for both arm.
you mean: {'follower_main': {'shoulder_pan': (2048, 1), 'shoulder_lift': (2048, 1), 'elbow_flex': (2048, 1), 'wrist_flex': (2048, 1), 'wrist_roll': (-3072, 0), 'gripper': (-2048, 0)}, 'leader_main': {'shoulder_pan': (2048, 1), 'shoulder_lift': (2048, 1), 'elbow_flex': (-2048, 0), 'wrist_flex': (2048, 1), 'wrist_roll': (-3072, 0), 'gripper': (-2048, 0)}} change all 1 to 0?
Well, after successfully calibrated and running teleoperate for sometimes, I go on for other ops. And the 2nd motor sometimes go block randomly, strange. coz I went through the dynamixel wizard2 and the 2nd motor seems no fault like the 1st motor. I meet the problem when running this (I dont think it's the reason):
import time from lerobot.scripts.control_robot import busy_wait
record_time_s = 30 fps = 60
states = [] actions = [] for _ in range(record_time_s * fps): ... start_time = time.perf_counter() ... observation, action = robot.teleop_step(record_data=True) ... states.append(observation["observation.state"]) ... actions.append(action["action"]) ... dt_s = time.perf_counter() - start_time ... busy_wait(1 / fps - dt_s)
Could you provide the video of your calibration procedure and the resulting failure?
Thanks!
The calibration procedure was updated and improved a few months ago, closing this issue
