Help>>Dynamixel Broadcast Instruction :(
Help>>Dynamixel Broadcast Instruction :(
by YoKzy
Sun May 08, 2011 4:35 pm
Hi. Eventhough I just joined this forum, I've been reading and searching on this thread for quite a long time (and found ton of information that I needed here 
) but I think I didn't found any of the similar thread. (Pardon me if I missed it).
So I'm building a 6DOF Dynamixel AX-12 robotic arm using a microcontroller ATMega32 which has a GUI interface using C#.
For a quick explanation, here's what I've done:
ex:
Now the problem is, if I use broadcast ID for Action instruction
Sometimes there's just 1 servo that's moving.
Sometimes both servos isn't moving.
And the servo's which not moving is blinking the LED once, eventhought I have set the ALARM LED register to 0.
Any idea what's the problem?
FYI I didn't use CM5, nor USB2Dynamixel. I made my own supply using Switching Voltage Regulator LM2576 (9.6V/3A).
) but I think I didn't found any of the similar thread. (Pardon me if I missed it).
So I'm building a 6DOF Dynamixel AX-12 robotic arm using a microcontroller ATMega32 which has a GUI interface using C#.
For a quick explanation, here's what I've done:
- Building AX12 library on microcontroller.
- Building serial communication (handshaking Half Duplex (AX-12) with Full Duplex (PC using MAX232))
- Moving a Dynamixel using WRITE instruction
- Get a status packet returned from AX-12
- Moving a Dynamixel using REGWRITE~Action(individual ID)
ex:
- Code: Select all
RegWrite(1,100); //Reg write servo ID=1 to 100 Degree
RegWrite(2,100); //Reg write servo ID=2 to 100 Degree
Action(1);
Action(2);
Now the problem is, if I use broadcast ID for Action instruction
- Code: Select all
RegWrite(1,100); //Reg write servo ID=1 to 100 Degree
RegWrite(2,100); //Reg write servo ID=2 to 100 Degree
Action(254);
Sometimes there's just 1 servo that's moving.
Sometimes both servos isn't moving.
And the servo's which not moving is blinking the LED once, eventhought I have set the ALARM LED register to 0.
Any idea what's the problem?
FYI I didn't use CM5, nor USB2Dynamixel. I made my own supply using Switching Voltage Regulator LM2576 (9.6V/3A).
Status Response and Registered write register (0x2C)
by YoKzy
Mon May 09, 2011 10:20 am
Actually at first I've tried the SyncWrite too, but the problem is just the same. Then I tried the RegWrite instruction to test with individual broadcast. Somehow there's something wrong with the broadcast ID...
So here's the copied text from terminal window:
As you can see the 0x2C register is doing fine, and the status respons on each instruction is correct too. But still the problem persist on Broadcasted Action. ..
Oh and the first number on Data readed and on Sync write is my own variable to notify the packet length when printing to terminal, it's not included on dynamixel communication.
So here's the copied text from terminal window:
- Code: Select all
Serial OK
/*****Write ID 0x11 and ID 0x0f to 150 degree.*****/
Write:(ffff,11,5,3,1e,ff,1,c8)
Data Readed: 6,ff,ff,11,2,0,ec NO ERROR
Write:(ffff,f,5,3,1e,ff,1,ca)
Data Readed: 6,ff,ff,f,2,0,ee NO ERROR
/*****Read register 0x2C from ID 0x11 and ID 0x0f. It should be 0*****/
Read:(ffff,11,4,2,2c,1,bb)
Data Readed: 7,ff,ff,11,3,0,0,eb NO ERROR
Read:(ffff,f,4,2,2c,1,bd)
Data Readed: 7,ff,ff,f,3,0,0,ed NO ERROR
/*****Regwrite ID 0x11 and ID 0x0f to 300 degree*****/
Write:(ffff,11,5,4,1e,ff,3,c5)
Data Readed: 6,ff,ff,11,2,0,ec NO ERROR
Write:(ffff,f,5,4,1e,ff,3,c7)
Data Readed: 6,ff,ff,f,2,0,ee NO ERROR
/*****Read register 0x2C from ID 0x11 and ID 0x0f. It should be 1*****/
Read:(ffff,11,4,2,2c,1,bb)
Data Readed: 7,ff,ff,11,3,0,1,ea NO ERROR
Read:(ffff,f,4,2,2c,1,bd)
Data Readed: 7,ff,ff,f,3,0,1,ec NO ERROR
/*****Broadcast action command. No respons status for broadcasted ID.*****/
Action:(ffff, fe, 2, 5, fa) NO ERROR
/*****Read register 0x2C from ID 0x11 and ID 0x0f. It should be 0*****/
Read:(ffff,11,4,2,2c,1,bb)
Data Readed: 7,ff,ff,11,0,0,eb NO ERROR
Read:(ffff,f,4,2,2c,1,bd)
Data Readed: 7,ff,ff,f,3,0,0,ed NO ERROR
/*****Regwrite ID 0x11 and ID 0x0f to 0 degree*****/
Write:(ffff,11,5,4,1e,0,0,c7)
Data Readed: 6,ff,ff,11,2,0,ec NO ERROR
Write:(ffff,f,5,4,1e,0,0,c9)
Data Readed: 6,ff,ff,f,2,0,ee NO ERROR
/*****Action to individual ID*****/
Action:(ffff, 11, 2, 5, e7)
Data Readed: 6,ff,ff,11,2,0,ec NO ERROR
Action:(ffff, f, 2, 5, e9)
Data Readed: 6,ff,ff,f,2,0,ee NO ERROR
/*****Sync write ID 0x11 and 0x0f to 300 degree*****/
Sync:e,ff,ff,fe,a,83,1e,2,11,ff,3,f,ff,3,30
//Sync write ID 0x11 and 0x0f to 0 degree
Sync:e,ff,ff,fe,a,83,1e,2,11,0,0,f,0,0,34
Done
As you can see the 0x2C register is doing fine, and the status respons on each instruction is correct too. But still the problem persist on Broadcasted Action. ..
Oh and the first number on Data readed and on Sync write is my own variable to notify the packet length when printing to terminal, it's not included on dynamixel communication.
by Fritzoid
Mon May 09, 2011 12:14 pm
Hi YoKzy,
A single LED flash can be generated in under various conditions. The first and most likely is due to a system reset. A system reset can be caused by either a RESET (0x06) or DIGITAL RESET (0x07) command in software. It can also occur if the voltage to the servo momentarily drops too low. Given the nature of your setup it's impossible to rule either of these possibilities out.
A voltage problem should be apparent if you monitor the down-stream servo's supply line with an oscilloscope or other fast reacting device.
A misinterpreted command on the other hand would indicate a serial speed problem. At 1 Mbs. small clocking differences between sender and receiver can cause misreads. This can sometimes be ameliorated by using extra stop bits.
A successful SYSTEM_WRITE (0x0D) command can also generate a single LED flash but I find it extremely unlikely that you've inadvertently sent one of these.
A single LED flash can be generated in under various conditions. The first and most likely is due to a system reset. A system reset can be caused by either a RESET (0x06) or DIGITAL RESET (0x07) command in software. It can also occur if the voltage to the servo momentarily drops too low. Given the nature of your setup it's impossible to rule either of these possibilities out.
A voltage problem should be apparent if you monitor the down-stream servo's supply line with an oscilloscope or other fast reacting device.
A misinterpreted command on the other hand would indicate a serial speed problem. At 1 Mbs. small clocking differences between sender and receiver can cause misreads. This can sometimes be ameliorated by using extra stop bits.
A successful SYSTEM_WRITE (0x0D) command can also generate a single LED flash but I find it extremely unlikely that you've inadvertently sent one of these.
by YoKzy
Mon May 09, 2011 3:08 pm
@Fritzoid
I'm using 16MHz Xtal, which have a 0% error on 1Mbps baudrate IIRC. And other command is working fine, including reading other dynamixel data, so I think that's not the problem.
About the reset on voltage drops too low, what is the voltage limit that will make it reset? And how much the current that each servo draw when starting to move? Is it from the Punch register? (I didn't know what's punch for
).
From the datasheet the maximum current of each servo draw is 900mA. And I've just use 2 servos, using 3A supply, isn't it should be enough?
FYI the microcontroller is not reseted so I can assume that the voltage drop is not below 5V isn't it?
I've try to read the voltage on oscilloscope a few days before but having a hard time to monitor it since it's need several reg write instruction before the action command is sent
But maybe tomorrow I'll try it again using sync write. (I don't have oscilloscope at home)
I'm using 16MHz Xtal, which have a 0% error on 1Mbps baudrate IIRC. And other command is working fine, including reading other dynamixel data, so I think that's not the problem.
About the reset on voltage drops too low, what is the voltage limit that will make it reset? And how much the current that each servo draw when starting to move? Is it from the Punch register? (I didn't know what's punch for
).
From the datasheet the maximum current of each servo draw is 900mA. And I've just use 2 servos, using 3A supply, isn't it should be enough?
FYI the microcontroller is not reseted so I can assume that the voltage drop is not below 5V isn't it?
I've try to read the voltage on oscilloscope a few days before but having a hard time to monitor it since it's need several reg write instruction before the action command is sent
But maybe tomorrow I'll try it again using sync write. (I don't have oscilloscope at home)
by Fritzoid
Mon May 09, 2011 5:05 pm
Hi YoKzy,
Your console output shows that both servos had registered data saved after the reg_write commands. It also shows that there was no registered data after the broadcast ID action command. So it seems that both servo 11 and servo 0F saw the broadcast action command and operated on it.
Of course they may not have done what you expected. With that in mind, you might want to look at some other control table fields (before the action command is issued). Byte 58 (0x3A) has the registered write address and byte 59 (0x3B) has the registered write length. Unfortunately the actual registered data is in flash memory and cannot be queried.
Also, move commands for positions beyond the CW and CCW angle limits can be ignored without an error being generated. So you will want to take a look at control table addresses 6 and 8 too.
Assuming all that checks out, I'd say this is more of a voltage problem than a communications issue.
FYI
Punch is the minimum voltage that will be applied to the motor when the position is just outside the compliance margin. It is usually a small number (default is 32). It is needed to overcome the internal gear friction. Since the maximum torque (100% of supply voltage) is usually set to 1023, a punch of 32 translates to just over 3 percent of the available voltage (33/1023).
The applied voltage ranges from the punch (minimum) to the torque limit (maximum) over the range of the compliance slope. Assuming that your goal position is outside the compliance margin and the compliance slope (more than 33 points off) the full voltage would be supplied at startup. You can avoid this by sending incremental position commands over the time span of the motion as opposed to a single command for the whole displacement. This is what Robotis does.
Finally, I know that problems like this can be a real challenge to resolve, if it were easy anyone could do it.
Your console output shows that both servos had registered data saved after the reg_write commands. It also shows that there was no registered data after the broadcast ID action command. So it seems that both servo 11 and servo 0F saw the broadcast action command and operated on it.
Of course they may not have done what you expected. With that in mind, you might want to look at some other control table fields (before the action command is issued). Byte 58 (0x3A) has the registered write address and byte 59 (0x3B) has the registered write length. Unfortunately the actual registered data is in flash memory and cannot be queried.
Also, move commands for positions beyond the CW and CCW angle limits can be ignored without an error being generated. So you will want to take a look at control table addresses 6 and 8 too.
Assuming all that checks out, I'd say this is more of a voltage problem than a communications issue.
FYI
Punch is the minimum voltage that will be applied to the motor when the position is just outside the compliance margin. It is usually a small number (default is 32). It is needed to overcome the internal gear friction. Since the maximum torque (100% of supply voltage) is usually set to 1023, a punch of 32 translates to just over 3 percent of the available voltage (33/1023).
The applied voltage ranges from the punch (minimum) to the torque limit (maximum) over the range of the compliance slope. Assuming that your goal position is outside the compliance margin and the compliance slope (more than 33 points off) the full voltage would be supplied at startup. You can avoid this by sending incremental position commands over the time span of the motion as opposed to a single command for the whole displacement. This is what Robotis does.
Finally, I know that problems like this can be a real challenge to resolve, if it were easy anyone could do it.