Questions about Sync Write example

[petercohen]

Hello, I have some questions about the SyncWrite C++ example given in:
e-Manual Software Help > Dynamixel SDK > USB2Dynamixel > Windows
DXL_SDK_Win64_v1_02.zip. For your convenience, I am posting the code fragment.

In example/visual c++/SyncWrite/SyncWrite.cpp, they have:

do
{
// Make syncwrite packet
dxl_set_txpacket_id(BROADCAST_ID);
dxl_set_txpacket_instruction(INST_SYNC_WRITE);
dxl_set_txpacket_parameter(0, P_GOAL_POSITION_L);
dxl_set_txpacket_parameter(1, 2);
for( i=0; i < NUM_ACTUATOR; i++ )
{
dxl_set_txpacket_parameter(2+3*i, id[i]);
GoalPos = (int)((sin(theta+phase[i]) + 1.0) * (double)AmpPos);
printf( "%d ", GoalPos );
dxl_set_txpacket_parameter(2+3*i+1, dxl_get_lowbyte(GoalPos));
dxl_set_txpacket_parameter(2+3*i+2, dxl_get_highbyte(GoalPos));
}

dxl_set_txpacket_length((2+1)*NUM_ACTUATOR+4);
printf( "\n" );
dxl_txrx_packet();
:
:


Q1: It seems that after setting up the id, instruction and parameters 0 to 10, one only needs to call dxl_txrx_packet() to send the entire packet to the motors. Am I right?

Q2: In Dynamixel/Communication/Instruction/Status Packet, one has to include the Checksum at the end of the packet. Why it is not necessary in this case?

Q3: What does dxl_set_txpacket_parameter(1, 2); mean? I do not understand what the 2 represents.

Q4: Here, the txpacket_length is 13 if NUM_ACTUATOR is 3. The reason is that id + instruction + 11 parameters. Am I right? This txpacket length seems to be different from the LENGTH (length of packet) listed under Instruction Packet. I am a bit confused. Could anybody please clarify?

Thanks.

[i-Bot]

I don't use this library, but based on other Robotis similar code.

Q1 dxl_txrx_packet(); will send the two 0xff sync bytes and then transmit the packet based on the values set with dxl_set_packet_... . It will then send a valid checksum and wait for the reply back. The dxl_set_txpacket_length is used to set the length based on the number of parameters and is used by the tx routine. Make sure you understand the parameter layout specific to the SyncWrite.
I don't know why the example uses dxl_txrx_packet(); when no packet will be returned from a broadcast, so dxl_tx_packet(); could be used.

Q2 Checksum is calculated and sent automatically

Q3 dxl_set_txpacket_parameter(1, 2); means set parameter 1 to the value 2. In SYNC write this parameter is the number of control table entries to write, so wirites both P_GOAL_POSITION_L and P_GOAL_POSITION_H

Q4 If NUM_actuator is 3, then the parameters are:
First parameter (0) = P_GOAL_POSITION_L
Second Parameter(1) = 2 bytes to send
Third Parameter(2) = First actuator ID
Fourth Paramater(3) = First actuator goal position low value
Fifth Parameter(4) = First actuator goal position high value
Sixth Parameter(5) = Second actuator ID
Seventh Paramater(6) = Second actuator goal position low value
Eighth Parameter(7) = Second actuator goal position high value
Ninth Parameter(8 ) = Third actuator ID
Tenth Paramater(9) = Third actuator goal position low value
Eleventh Parameter(10) = Third actuator goal position high value

txpacket_length = number of parameters + 2 = 13

[petercohen]

Q3 dxl_set_txpacket_parameter(1, 2); means set parameter 1 to the value 2. In SYNC write this parameter is the number of control table entries to write, so wirites both P_GOAL_POSITION_L and P_GOAL_POSITION_H

Q4 If NUM_actuator is 3, then the parameters are:
First parameter (0) = P_GOAL_POSITION_L
Second Parameter(1) = 2 bytes to send
Third Parameter(2) = First actuator ID
Fourth Paramater(3) = First actuator goal position low value
Fifth Parameter(4) = First actuator goal position high value
Sixth Parameter(5) = Second actuator ID
Seventh Paramater(6) = Second actuator goal position low value
Eighth Parameter(7) = Second actuator goal position high value
Ninth Parameter(8 ) = Third actuator ID
Tenth Paramater(9) = Third actuator goal position low value
Eleventh Parameter(10) = Third actuator goal position high value

txpacket_length = number of parameters + 2 = 13

Thanks again i-Bot for the explanations.

Do you mean by setting the second parameter of
dxl_set_txpacket_parameter as 2, for each motor id, write to both P_GOAL_POSITION_L and P_GOAL_POSITION_H as in parameters 3,4,6,7,9,10?

In Kind of Instruction, there is an example on Sync Write (Example 5). In that example, the Instruction Packet is: 0xFF 0xFF 0xFE 0x18 0x83 0x1E 0x04...

i) Due to 0x04, four bytes (2 for position and 2 for speed) are written for each motor. Am I right?

ii) In that example, 0x83 is the length calculated by (L+1)XN+4. Why this length parameter is not required when setting up the packet in the C++ program fragment I posted?

[i-Bot]

In example 5, 4 bytes are written to each servo.
The instruction bytes are:

0xFF First Sync
0xFF Second sync
0xFE Broadcast address
0x18 Length
0x83 Sync Write Instruction
0x1E Address in control table to start writing
0x04 number of bytes to write in control table for each id
0x00 id of first servo
0x10 start of data bytes for first servo
..... etc.

Number of parameters = (1[id] + 4[bytes per servo]) * 4(number of servos) + 2(start address and length) = 22
Length = Number of parameters + 2 = 24 (0x18)
The length in the example is written with the dxl_set_txpacket_length(Length)

[petercohen]

In example 5, 4 bytes are written to each servo...

Thanks i-Bot for the explanations.

In practice, what are the advantages and disadvantages of using SyncWrite vs. calling dxl_write_word( DEFAULT_ID, P_GOAL_POSITION_L, GoalPos[index]) in a loop when we want to turn different motors at once? Is there a limitation on the number of motors?

[xevel]

In practice, what are the advantages and disadvantages of using SyncWrite vs. calling dxl_write_word( DEFAULT_ID, P_GOAL_POSITION_L, GoalPos[index]) in a loop when we want to turn different motors at once? Is there a limitation on the number of motors?

With SYNC_WRITE, you can send data to a lot of servos faster than with a loop of WRITE_DATA.
You also get the added bonus of having the data written simultaneously, as the name implies (iirc), or close enough to make no matter. With a loop of WRITE_DATA over a lot of servo, when the servos are configured to send back a status packet to acknowledge each command, a delay might get noticeable between when the first servo start moving and when the last one does.

There is a limitation to the length of the packets : 143 bytes (see http://support.robotis.com/en/product/d ... uction.htm):

Generally, in the event 1 command packet is 4 byte, 26 Dynamixel can be controlled simultaneously. Make sure that the length of packet does not to exceed 143 bytes since the volume of receiving buffer of RX-64 is 143 bytes.

This is also valid for other AX, RX and EX servos. I don't know if they use a bigger buffer for MX.

[i-Bot]

For general purpose write to the servos, I usually use the WRITE _DATA, it is more flexible, easier to use, and more robust. It is more robust because it can give you a status byte back.

As Xevel said the advantages of the SYNC_WRITE are performance and synchronisation. These factors are especially important if you drive the Dynamixel bus from a PC, because each transaction has to pass through the operating system between your application and the Dyanmixel bus. These delays really add up over 18 or 20 servos, making a slow update rate and also adding a slew in the time each servo is updated. The control table places the slope(PID on MX servo) and the speed next to the goal position to help to use SYNC_WRITE.

[petercohen]

Generally, in the event 1 command packet is 4 byte, 26 Dynamixel can be controlled simultaneously. Make sure that the length of packet does not to exceed 143 bytes since the volume of receiving buffer of RX-64 is 143 bytes.

This is also valid for other AX, RX and EX servos. I don't know if they use a bigger buffer for MX.

I cannot find the buffer size for the MX. So, at least for the pre-MX motors, if I only send position data to each motor, I can control 26x2 Dynamixel simultaneously? However, if in addition I want to get back the angle data from the motors, I will again be able to control only 26 Dynamixel. Am I right?

What is the practical maximum number of motors one could control via usb2dynamixel and robotis controllers, with and without angle data feedback for recording?

[i-Bot]

In the DARwin code, the largest SYNC_WRITE appears to be writing 5 bytes (position and PID) to 20 servos [< 143 bytes], so I would stick to 143 unless you can get Robotis to answer otherwise or try it yourself.

If you want to read the position, then you would need to use BULK_READ on the MX servos, though this instruction is not available on the AX and RX servos.

[xevel]

If you only send position data, you have to send 3 bytes per servo (one for ID + 2 for Goal Position), plus the command header (7 bytes in all) and checksum (1byte). That means you can send it to at most 44 or 45 servos (45 servos gives a total of 143 bytes, but since in the example they say you can send data to 26 servos even if it's 27 that would give exactly 143 bytes).

All this is, of course, if you want to limit yourself to only one command to write data to all your servos. you could send two or more consecutive SYNC_WRITE commands to write data to many more servos, up to the maximum of 253 (or 254, depends on your controller).

That's for writing data to the servos, reading data is a whole other story. You can not both write and read with just one command. So the comment about being able to control only half the number of servos when you want the get data back from them misses the point.

Please read at least the basics of the dynamixel protocol, this is fairly thoroughly explained here:
http://support.robotis.com/en/product/d ... cation.htm and http://support.robotis.com/en/product/d ... uction.htm

[petercohen]

In the DARwin code, the largest SYNC_WRITE appears to be writing 5 bytes (position and PID) to 20 servos [< 143 bytes], so I would stick to 143 unless you can get Robotis to answer otherwise or try it yourself.

If you want to read the position, then you would need to use BULK_READ on the MX servos, though this instruction is not available on the AX and RX servos.

Could you please let me know where a description/example of BULK_READ is? This is the first time I heard about it. Under Instruction Packet, there are only 7 instructions (PING, READ_DATA, WRITE_DATA, REG WRITE, ACTION, RESET, SYNC_WRITE). Thank you.

[xevel]

There is no documentation that I know of for BULK_READ. You can have a look at the source code for the CM-730 in the Darwin-OP source repository.

Also, i-Bot talks a little about it here : http://robosavvy.com/forum/viewtopic.php?t=8859

And some more stuff here : http://www.robotis.com/robotsource/6338

[i-Bot]

In the latest CM730 application code the following instructions are defined:

Code: Select all

#define INST_PING           0x01
#define INST_READ           0x02
#define INST_WRITE          0x03
#define INST_REG_WRITE      0x04
#define INST_ACTION         0x05
#define INST_RESET          0x06
#define INST_DIGITAL_RESET  0x07
#define INST_SYSTEM_READ    0x0C
#define INST_SYSTEM_WRITE   0x0D
#define INST_SYNC_WRITE     0x83
#define INST_SYNC_REG_WRITE 0x84
#define INST_BULK_READ       0x92

I think the additional SYSTEM and DIGITAL instructions are to do with firmware down load.
The SYNC REG write may be useful if you have a large number of servos.

The format of the BULK_READ appears to be:

Instruction:
0xFF First Sync
0xFF Second Sync
0xFE Broadcast Address
0x0A Packet length(Param + 2)
0x92 BULK_READ instruction
0x00 Parameter 0 = 0x00
0x02 Parameter 1 = Number of bytes to read from first device
0x01 Parameter 2 = ID of first device
0x24 Parameter 3 = Start address in control table for first device
0x02 Parameter 4 = Number of bytes to read from next device
0x02 Parameter 6 = ID of next device
0x24 Parameter 7 = Start address in control table for next device
.....
0x?? Checksum

The lengths and addresses can be different for each ID, so you can read FSR, servo positions and IMU from CM730 in the same bulk read.

The multiple replies are exactly the same as they would be for a normal read to those devices, and are returned in the order their id appears in the parameters. Special application software is needed to handle the multiple replies, I don't think it is supported in the existing DXL libraries, only in the DARwin code.

[Fritzoid]

Bulk-read is NOT a servo command per se. The CM730 maintains an internal table which includes the most recent position readings from the servos. It keeps this table up-to-date by continuously polling the servos in the background. This works for Darwin because the bus speed is so fast that the time constraint of issuing 20 read-data commands is minimal. The bulk-read command allows you to read sections of this table from the CM730 memory.

By the way, you can control what servo control table fields are maintained in the bulk-read table. The current position is included by default but other fields like speed and load can be extracted.

[i-Bot]

Hi Fritzoid,
The method you describe seems to have been used in earlier versions of DARwin, but in the latest CM730 firmware, and the latest DARwin software from Robotis, BULK_READ does appear to be an MX servo command, and there is no bulk read table in the CM730.
Take a look at the latest versions and see what you think.