dynamixel:dynamixel_protocol

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dynamixel:dynamixel_protocol [2017/03/22 11:17] Pedro Ramilodynamixel:dynamixel_protocol [2017/08/23 16:03] (current) Pedro Ramilo
Line 21: Line 21:
   * for other devices, consult the manufacturer's documentation   * for other devices, consult the manufacturer's documentation
  
-Seed Robotics designed the Control tables to resemble those of an Robotis MX series sevro; this enables comptibility with RObotis products as well as a large code base built for Dynamixel devices.+Seed Robotics designed the Control tables to resemble those of an Robotis MX series servo; this enables compatibility with Robotis products as well as a large code base built for Dynamixel devices.
  
 **Other Protocol features to ensure reliability** **Other Protocol features to ensure reliability**
Line 35: Line 35:
  
 ''WRITE ID=2, MEMORY POSITION 30, VALUE=256 /* set the desired goal position */'' ''WRITE ID=2, MEMORY POSITION 30, VALUE=256 /* set the desired goal position */''
 +
 +Explanation:\\
 +First we write to memory position 24, which is the Memory Position to turn TORQUE ON. (you only need to turn Torque ON once; after that it will stay ON until you write the position to 0, to disable or power down the device)\\
 +Next we write to the memory position 30, which is the Memory Position for GOAL POSITION.\\
 +For information about which memory positions to use, please see the Control Tables, listed above.
 +
  
 After each ''WRITE'', and assuming Status Return Level is configured to 2, the slave replies with a Status packet. This status packet includes valuable information such as the Error bitmask that reports any errors on the servo. After each ''WRITE'', and assuming Status Return Level is configured to 2, the slave replies with a Status packet. This status packet includes valuable information such as the Error bitmask that reports any errors on the servo.
Line 49: Line 55:
  
 ''READ ID=7, MEMORY POSITION 43, LENGTH=1  /* READ, start at memory position 43 (the memory position for temperature), and read only 1 byte */'' ''READ ID=7, MEMORY POSITION 43, LENGTH=1  /* READ, start at memory position 43 (the memory position for temperature), and read only 1 byte */''
 +
 +Explanation:\\
 +Memory Position 43 corresponds to the Present Temperature in the Control Table. It is represented by only 1 byte.\\
 +For information about which memory positions to use, please see the Control Tables, listed above.
  
 You would have noticed that READ has the ability to read a sequence of bytes from the Control table: you specify the start address on the Control Table and length of data to read. This is especially efficient when you need to query multiple status variables at once. You would have noticed that READ has the ability to read a sequence of bytes from the Control table: you specify the start address on the Control Table and length of data to read. This is especially efficient when you need to query multiple status variables at once.
Line 80: Line 90:
  
 As far as we know, the protocol specification does not specify a maximum time between sending a command and receiving a reply. However one can deduce proper timeout values considering the following: As far as we know, the protocol specification does not specify a maximum time between sending a command and receiving a reply. However one can deduce proper timeout values considering the following:
-  * Most Dynamixel slave devices have a setting called "Return Delay Time". This is a virtually introduced delay that was meant to allow time for slower peripherals to switch from TX to RX mode. By default this is set at 500 microseconds. On modern setups users actively disable this, by setting this parameter to 0. Otherwise, if set at 500microsecs, you add significant latency to the communication.  The Eros series of firmware no longer supports this setting and will always reply as fast as possible (the equivalent behavior of setting the parameter to 0).+  * Most Dynamixel slave devices have a setting called "Return Delay Time". This is a virtually introduced delay that was meant to allow time for slower peripherals to switch from TX to RX mode. By default this is set at 500 microseconds. On modern setups users actively disable this, by setting this parameter to 0. Otherwise, if set at 500microsecs, you add unnecessary latency to the communication.  The Eros series of firmware no longer supports this setting and will always reply as fast as possible (the equivalent behavior of setting the parameter to 0).
   * The Dynamixel documentation refers (buried deep in the documentation) that a command is considered interrupted if no byte is sent after a period of 100 milliseconds.   * The Dynamixel documentation refers (buried deep in the documentation) that a command is considered interrupted if no byte is sent after a period of 100 milliseconds.
  
Line 86: Line 96:
 While we can't immediately draw a conclusion from this data, real world experience shows the following: While we can't immediately draw a conclusion from this data, real world experience shows the following:
   * Robotis Dynamixel Wizard seems to use a timeout of 5 milliseconds when scanning the bus: when it ''PING''s an I D, if no reply is received within 5 milliseconds it assumes a timeout   * Robotis Dynamixel Wizard seems to use a timeout of 5 milliseconds when scanning the bus: when it ''PING''s an I D, if no reply is received within 5 milliseconds it assumes a timeout
-  * Other users in more complex setups and with commands other than ''PING'' use timeouts of at least 20 milliseconds, and on some cases they go up to a full 100 milliseconds.+  * Other users in more complex setups, or performing very long READs or WRITES may use timeouts of 10~20 milliseconds
 +  * The typical measured turn around time for a command in the EROS architecture can be 2.5ms maximum or up to 6ms if the board is unable to verify reply from the actuators, and needs to re-query them.
  
-Our recommendation would be to use** 5 milliseconds for PING replies** and **20 milliseconds for any other commands**. If you experience communication issues, you can try increasing the timeout up to 100 millisecondsOver 100 milliseconds, which is already apretty high timeout value, you'd be operating outside the Robotis own maximum timeout recommendation for Dynamixel communications.+Our recommendation, based on our measurements and experience, is to use ** 5 milliseconds** if you're performing short READs and writes (reading/writing up 10 sequential memory positions) or bring it up to 10ms if you are doing longer READs/WRITEs. If you experience communication issues, you can try increasing the timeout even more\\ 
 +Typically if after 10~20ms you did not get a reply, you should re-send the command as there was likely some communication issue (data corruption for example).\\ 
 +Increasing the timeout over 100 milliseconds, which is already a pretty high timeout value, you'd be operating outside the Robotis own maximum timeout recommendation for Dynamixel communications.
  
 **Note:** it is important to **clarify the "timeout"** concept depicted in this section: "timeout" is the time that is counted between __sending the **last** byte of a command__ and __receiving the **first** byte of a reply__.\\ **Note:** it is important to **clarify the "timeout"** concept depicted in this section: "timeout" is the time that is counted between __sending the **last** byte of a command__ and __receiving the **first** byte of a reply__.\\
 Because the protocol can operate at different baud rates, timeout should always be counted as above and never be counted as the time it takes between sending the last byte of the command and receiving the last byte of a reply. This would be wrong and would produce inconsistent results operating at different baud rates. Because the protocol can operate at different baud rates, timeout should always be counted as above and never be counted as the time it takes between sending the last byte of the command and receiving the last byte of a reply. This would be wrong and would produce inconsistent results operating at different baud rates.
 +
 +Furthermore, for BULK_* commands, where the units will reply in sequence, they will take up to 5ms for each device to send the reply. Therefore, if you are doing a BULK_* query on 5 devices, for example, it may take a maximum of 5 devices * 5ms = 25ms to get the replies for all the servos queried.
  
  
Line 98: Line 113:
 To improve bus efficiency and for added functionality, the Dynamixel Protocol offers enhanced forms of the READ and WRITE commands To improve bus efficiency and for added functionality, the Dynamixel Protocol offers enhanced forms of the READ and WRITE commands
   * ''PING'' - used to query for a presence of a servo (by detecting a timeout) or to quickly request a Status packet to check the error flags.   * ''PING'' - used to query for a presence of a servo (by detecting a timeout) or to quickly request a Status packet to check the error flags.
-  * ''REG_WRITE'' and ''ACTION'' - these are deprecated commands. They were sued to cache a WRITE command on several slave devices. When all is done, you send an ''ACTION'' command to the bus which triggers the slaves to execute the cached WRITE. The purpose is to synchronize operations such as the beginning of a movement.+  * ''REG_WRITE'' and ''ACTION'' - these are deprecated commands (there is now the new, more efficient ''SYNC_WRITE''). They were used to cache a WRITE command on several slave devices. When all was done, you send an ''ACTION'' command to the bus which triggers the slaves to execute the cached WRITE. The purpose is to synchronize operations such as the beginning of a movement.
   * ''BULK_READ'' - used to request data from multiple slaves in one go. In this mode, you send the sequence of IDs to read and requested memory positions. The slaves will reply in sequence, one after the other, in the order that you specified in the command. Please note that not all Dynamixel devices support this command.   * ''BULK_READ'' - used to request data from multiple slaves in one go. In this mode, you send the sequence of IDs to read and requested memory positions. The slaves will reply in sequence, one after the other, in the order that you specified in the command. Please note that not all Dynamixel devices support this command.
   * ''SYNC_WRITE'' - writes data to multiple slaves in one go. Please note that not all Dynamixel devices support this command.   * ''SYNC_WRITE'' - writes data to multiple slaves in one go. Please note that not all Dynamixel devices support this command.
   * ''SYNC_READ'' and ''BULK_WRITE'' are only  supported in Protocol version 2 and have similar behavior as above.   * ''SYNC_READ'' and ''BULK_WRITE'' are only  supported in Protocol version 2 and have similar behavior as above.
  
-  * Another feature for improved efficiency is the ''BROADCAST ID (0xFE)''. When the master sends a packet to this ID, all slaves will treat the command as address to themselves. There are a few particularities with the Broadcast ID, the main one is that the slaves NEVER reply to a broadcast command. Broadcast is used, for example, to support the BULK_* and SYNC_* commands and to perform WRITES in one go.+  * Another feature for improved efficiency is the ''BROADCAST ID (0xFE)''. When the master sends a packet to this ID, all slaves will treat the command as addressed to themselves. There are a few particularities with the Broadcast ID, the main one is that the slaves NEVER reply to a broadcast command. Broadcast is used, for example, to support the BULK_* and SYNC_* commands and to perform WRITES to all devices in one go (for example to set Torque ON). (Note: Because the BROADCAST ID never returns a reply, it is pointless to use it with READ commands; if you need to read multiple IDs at once, consider using BULK_READ instead.)
  
 For more information, depending on your protocol version: For more information, depending on your protocol version:

Copyright © 2015-2023 Seed Robotics Ltd

  • dynamixel/dynamixel_protocol.1490181479.txt.gz
  • Last modified: 2017/03/22 11:17
  • by Pedro Ramilo