Questions about the Examples given in Kind of Instruction

[petercohen]

Hello, we are trying to understand the examples provided in the document:
Product Information > Dynamixel > Communication > Kind of Instruction

Could anybody please let us know the answers? Thank you.

Q1. Example 6. Read the Model Number and Firmware Version.
a) Under Communication. Instruction Packet. Why there is a 00 03 before F5? What the 00 03 actually mean? Shouldn't the 03 be 02 because the address for Version of Firmware is 0x02?
b) Under Status Packet. Why there is a 00 between 40 and 08?

Q2. Example 10. Restricts the movement angle from 0 to 150 degrees.
Since 300 degrees is represented by a value of 1023, 150 degrees is represented by 511.5. Rounding off means 512 which in Hex is 0x0200. How come in the Instruction Package, it is represented in reverse order (i.e. 00 02)?

Q3. Example 13. We know that the maximum torque is 0x03FF which is 1023 in decimal. So, half of that is 511.5. In this example, they seem to use 511 which has a hex value of 0x1FF.

a) Not sure why because in my Q2, they rounded 511.5 to 512. Any idea?
b) Under Hint. Address = 0x0E. Why only lower byte address? We don't need to write down upper byte address as well?
c) 50% of maximum torque is 0x01FF. Why in instruction package, they write: FF FF 01 05 03 0E FF 01 E8 rather than
FF FF 01 05 03 0E 01 FF E8?

Q4. Example 16. Under Communication, Instruction Packet:
FF FF 01 05 03 18 01 01 DC
a) Why they only specify the lower byte of 0x18 Torque Enable? There is no need to specify the upper byte and also the address of the LED 0x19?
b) Is the reason 01 01 is that we want to turn on both the LCD and enable torque?
c) Why the checksum is DC? We got E2.

Q5. Example 17. Locates at the Position 180 degrees with the speed of 57RMP.
a) It sets the goal position (0x1E) to 512. I think 512 corresponds to 150 degrees not 180 degrees. Is it a typo?
b) The position address is: 0x1F 0x1E while the speed address is: 0x21 0x20. Why we only need to put 1E in the address part?
c) The data for position is 0x200 while that for speed is 0x200. I guess this can also be written as: 0x0200 and 0x0200. How come in the instruction package, it is written as:
FF FF 01 07 03 1E 00 02 00 02 D2 rather than
FF FF 01 07 03 1E 02 00 02 00 D2?

[i-Bot]

To correctly interpret the examples you need to understand the packet format:
http://support.robotis.com/en/product/d ... packet.htm
And the layout of the control table, especially where 16 bit values are represented as two bytes with least significant first:
http://support.robotis.com/en/product/d ... tuator.htm
You may also want to google "endianness" to understand how values can be represented in different ways on different processors.
In example 6
The bytes sent are:
0xFF First Sync
0xFF Second Sync
0x01 Dynamixel ID
0x04 Length (number of parameters + 2)
0x02 Instruction (Read)
0x00 Parameter 1 (Control Table start address)
0x03 Parameter 2 (number of control entries to read)
0xF5 Checksum

The bytes returned are:

0xFF First Sync
0xFF Second Sync
0x01 Dynamixel ID
0x05 Length (number of parameters + 2
0x00 Status/ Error Byte
0x40 Parameter 1 (Low byte of Model)
0x00 Paramater 2 (high byte of Model)
0x08 Parameter 3 (Firmware version)
0xB1 Checksum.


Try working all the examples again and come back if you still don't understand.

[petercohen]

To correctly interpret the examples you need to understand the packet format:
http://support.robotis.com/en/product/d ... packet.htm
And the layout of the control table, especially where 16 bit values are represented as two bytes with least significant first:
http://support.robotis.com/en/product/d ... tuator.htm
You may also want to google "endianness" to understand how values can be represented in different ways on different processors.
In example 6
The bytes sent are:
0xFF First Sync
0xFF Second Sync
0x01 Dynamixel ID
0x04 Length (number of parameters + 2)
0x02 Instruction (Read)
0x00 Parameter 1 (Control Table start address)
0x03 Parameter 2 (number of control entries to read)
0xF5 Checksum

The bytes returned are:

0xFF First Sync
0xFF Second Sync
0x01 Dynamixel ID
0x05 Length (number of parameters + 2
0x00 Status/ Error Byte
0x40 Parameter 1 (Low byte of Model)
0x00 Paramater 2 (high byte of Model)
0x08 Parameter 3 (Firmware version)
0xB1 Checksum.


Try working all the examples again and come back if you still don't understand.

Thanks for the reply i-Bot. Actually we read though the links before posting.

Since we are using a PC, we are dealing with little endian. As a result, for Instruction Packet and Status Packet, we list the low byte first followed by high byte. However, when converting a decimal number into hex, we keep using the format 0x[high byte][low byte]. Is this true?

Could you please let us know the answers for: Q3a and b; Q4 a, b and c; Q5 a and b.

[i-Bot]

Yes, the bytes sent in the instruction and status packets should always be in the order the appear in the control table. How they are represented in your software is up to you and your processor.

3a - it make little difference whether you round up or down
3b- the control table address is automatically incremented as the bytes are received, so the data is put in both 0x0E(0xFF) and 0x0F(0x01)

4a/4b- Torque enable is only a single byte so the first 0x01 sets the torque on, the seconf 0x01 is put int0 control table address 0x19 and sets the LED on

4c 0xFF - 0x01 - 0x01 - 0x18 - 0x03 - 0x05 - 0x01 = 0xDC

5a- 180 degrees is often used as a term to describe the centre position
5b - as above the control table address is automatically incremented for each byte
5c- low byte first in data packet

[petercohen]

4c 0xFF - 0x01 - 0x01 - 0x18 - 0x03 - 0x05 - 0x01 = 0xDC

5a- 180 degrees is often used as a term to describe the centre position

Thank you very much for the explanations.

For 4c, we did it as following:

Checksum = ~(0x01 + 0x05 + 0x03+ 0x18 + 0x01 + 0x01)
= ~( 1 + 5+ 3+ 18+ 1 +1)
= ~(29) All bytes are used since the value is less than 255
= ~(11101)
= ~(0001 1101)
= 1110 0010
= E2

Could you please tell us where the error is? We used the same method to calculate the checksum in other examples. There has been no problem except for this one.

For 5a, I am not sure what you meant. For RX and AX-18, 150 degrees (position 512) is the centre position. For the MX series, 180 degrees (2048) is the centre position. I think this example refers to RX/AX motors because it uses 512 as the data. In that case, shouldn't the question be "Locate at the Position 150 degrees..."?

[i-Bot]

The values are hex (0x18 = 24 decimal)
Checksum = ~(0x01 + 0x05 + 0x03+ 0x18 + 0x01 + 0x01)
= ~( 1 + 5+ 3+ 24+ 1 +1)
= ~(35)
= ~(0x23)
= ~(0010 0011)
= 1101 1100
= 0xDC

By chosing the centre at 180 degrees, then the AX servo simply has an angle range of 30 degrees to 330 degrees and the MX from 0 degrees to 360 degrees

[petercohen]

By chosing the centre at 180 degrees, then the AX servo simply has an angle range of 30 degrees to 330 degrees and the MX from 0 degrees to 360 degrees

Thanks i-Bot.

Still confused why the question is "Locates at the Position 180" rather than "Locates at the Position 150". I think that example refers to older motors such as the AX and RX servos.

For the new MX motor, the center position is at 180 degrees. This corresponds to a value of 2048 which is 0x800. As for the speed, it is 57/0.114 = 500 (the unit is about 0.114rpm). In Hex, it is 0x1F4.

So, the Instruction package is: FF FF 01 07 03 1E 00 08 F4 01 09 ?

Checksum = ~(1+7+3+30+0+8+244+1)
=~(294) > 255, use lower byte only.
=~(100100110)
=1001
= 0x09

Is this right?

[i-Bot]

Content looks OK, your checksum is wrong.

=~(1 0010 0110)
=~(0010 0110) mask to single byte
=1101 1001
= 0xD9

[petercohen]

Content looks OK, your checksum is wrong.

=~(1 0010 0110)
=~(0010 0110) mask to single byte
=1101 1001
= 0xD9

Thanks i-Bot. When you say mask to single byte, do you mean when making the checksum, we only need to care about the lower 8 digits?

[i-Bot]

Yes only the lower 8 bits are used.