More about I-SOBOT servo protocol

Here are some conclusions after tracking servo frames.

Standby frame, sent a few seconds after no order is sent (to reduce servo power):


see below! I don't know why the table is displayed there... probably wysiwyg

Byte	left arm	right arm	left leg	right leg
1	0x05	0x05	0x05	0x05
2	0x00	0x00	0x00	0x00
3	0x00	0x00	0x65	0x9B
4	0x00	0x00	0xB5	0x4B
5	0x00	0x80	0x9A	0x66
6	0x80	0x80	0x00	0x00
7	0x85	0x06	0xBA	0x52
8	0xFF	0xFF	0xFF	0xFF

Remarks:

• Only one difference between left arm frame and right arm frame in byte 5. In fact, Byte 5 in left arm frame is the head position. When head is turned right (Joystick action #16), this byte value is 0xBB = -69. When head is turned left (Joystick action #15), this byte value is 0x45 = +69. As we will see below, servo positions are signed values.
• In the legs, the 5 bytes are used. Although there are only 4 servos in each leg, one is double and that might be the reason. Note that values for left leg are just the opposite of values for right leg (expressed with 8bits): 0x65 = -0x9B, 0xB5 = -0x4B and so on. It is rather logical but it also proves that these servos are well calibrated and might be easy to use without detailed technical data we probably can't get from Tomy.
• Checksum computation: it is rather clear with these 4 frames that the checksum is the sum of byte 1 ("start" byte = 0x05) through byte 6 including carries. Carry include explains the result 0x06 for right arm as well as results for legs.

Some position values for shoulder rotation (byte 2) obtained with Arm Lock (Joystick control #14):

• Arms vertically downward along body: left 0x26, right 0xDA which is the opposite of 0x26.
• Arms horizontal: left 0x80, right 0x80.
• I think that with left 0xDA and right 0x26 w, I-SOBOT will raise its arms vertically upward.

That's all for today. Now it's OK to send frames with an external UART and check which servo correspond to which byte.