Open mtrossen opened 5 years ago
Hi @mtrossen :) I tested reboot with XL-430-W250. But, I can't find problem. Cloud you tell me more detail your situation? Then, did you supply to power from only USB cable? DXL need to stable supplying power.
Thanks, Gilbert.
HI Gilbert,
We are purposely making the power error so we can write reboot code into our software. (Because customers plug in the USB cable first sometimes)
1) We plug in the USB cable (This causes a power error on all servos) 2) We plug in the power cable 3) We run the program and the servos will not communicate because they are holding the power error in memory. 4) we run the reboot code for each servo as mentioned in the original post 5) The XL-430-W250 returns error, but the XM430-W350 do not return the error.
Even though the XL430-W250 returns the error, the reboot does work. But the error being reported causes a problem in the software.
It looks like the error code being returned is 128, not -3001 as I had originally stated. I don't see error code 128 listed anywhere in the documentation.
Attached is a picture of the hardware setup.
Regards,
Matt
Actually, there are not 128 error code in our code. The -3001 error code is TxRxtimeout error. I want to give advice, but I can not help you exactly. Because I don't know your code. Did you make a reboot code for arduino?
I'm also confused by the 128 being returned because you don't have that error code. Here is the function that I wrote. It get's called for each servo in the arm.
` int fncSWResetServo(int intServoIDToReset) {
dxl_comm_result = packetHandler->reboot(portHandler, intServoIDToReset, &dxl_error);
// Send reply Packet if there is an error
if (dxl_comm_result != 0) { //there was a COMM error
SendPacketDATA(PacketReceivedInstruction_Type + 200, PacketReceivedInstruction_Use, intServoIDToReset, PacketReceivedInstDetail_2, PacketReceivedInstDetail_3, PacketReceivedInstDetail_4, dxl_comm_result);
return -1;
}
else if (dxl_error != 0) { //there was a packet error
SendPacketDATA(PacketReceivedInstruction_Type + 200, PacketReceivedInstruction_Use, intServoIDToReset, PacketReceivedInstDetail_2, PacketReceivedInstDetail_3, PacketReceivedInstDetail_4, dxl_error);
return -1;
}
else { // everything okay return the read value
return dxl_comm_result;
}
} `
As mentioned, The code works for XM430 servos, but I get the strange error on XL430 servos. If you look at the attached picture when I run a debug on the firmware and the error happens. The debugger is stopped on line 4216 because dxl_comm_result is a non zero value. But the value shown in red is some strange string of numbers and colons? And they keep changing, they are steadily incrementing upwards. 1:2:774956:573420:6 1:2:799302:597766:6 1:2:817432:615896:6
I've never seen a variable reported back like this before. It should be an integer. I think this strange string is being converted to 128 when being sent back over serial bytes.
Do you see anything in the code that may be wrong that would cause an error for XL430 servos but not an XM430?
I'm sorry for late reply. I don't know strange string of numbers and colons. It is difficult to help because it can not be reproduced.
Hi Gilbert,
I understand. I am very confused by the error being reported also. I will try to reproduce the error in a small arduino file that I can share. If I can reproduce the error in that file I will upload it here for you to test. Please allow me some time to make the file.
regards,
Matt
This issue will be closed since there were no actions for a while. You can reopen this issue to show this issue to the users whenever. Thanks.
We were able to replicate this error using the attached SDK example sketch.
If you follow the following steps you should be able to also replicate the error. Please let us know if you are able to.
Hardware setup: OpenCM9.04 / powered hub / XL430
Plug the OpenCM9.04 into a powered hub: http://www.robotis.us/u2d2-power-hub-board/
Plug in an XL430 servo with the BAUD rate set to 1meg and the ID to 1.
Load the sketch attached through the Arduino IDE and open the serial monitor. Download link: http://support.interbotix.com/downloads/Interbotix_DynamixelSDK_Example.zip Interbotix_DynamixelSDK_Example.zip
Type "menu" to see the full menu
Unplug the power cable and re-plug it in. This wall cause the servo to have a low voltage/amp error and stop working.
Type "reboot" into the serial monitor.
This will return a code of 128 which is where the bug is. The servo will have successfully reset, but also sends that code.
If you type "reboot" again then you will not see the 128 response. It will reboot successfully. The error only happens once.
If you repeat this whole test using an XM430 servo you will not get the 128 error/bug.
The "error" of 128 being sent causes problems for us in our firmware. We need to have the bug resolved in order to finish the reboot code in our firmware.
Thanks.
Hello, This is tagged with question. Is someone waiting on a question. My last post from over 2 months ago shows how to repeat the bug. Has anyone tried to repeat the bug yet?
DynamixelSDK
on OpenCM9.04 with the Arduino package (I don't know how to check which version is being loaded)Hello, I'm working on our arm firmware using the DynamixelSDK. I am creating a software reset function as described here: http://emanual.robotis.com/docs/en/software/dynamixel/dynamixel_sdk/sample_code/cpp_reboot_protocol_2_0/#cpp-reboot-protocol-20
When calling this line: dxl_comm_result = packetHandler->reboot(portHandler, intServoIDToReset, &dxl_error);
XL430-W250 servos will blink their LED, but then return a dxl_comm_result error of -3001.
If I call the line again after the error it will return a 0 indicating success.
When I call the same line to an XM430-W350 servo on the first call it will return a 0 indicating success.
For XL430-W250 servos, even though it is returning an error on the first SW reboot call, it does reboot. The servo communicates fine even though it has returned an error. I do not have to send the second call with the no-error response. So, I think this may be a bug. The bug causes a problem because it is returning an error to our firmware even though the SW reboot is working.
More information:
Thanks!
Matt