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/08/17 16:35] – [The timeout] 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 37: Line 37:
  
 Explanation:\\ 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 saty ON until you write the position to 0, to disable or power down the device)\\+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.\\ 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. For information about which memory positions to use, please see the Control Tables, listed above.
Line 97: Line 97:
   * 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, or performing very long READs or WRITES may use timeouts of 10~20 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 a reply from the actuators.+  * 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 a reply from the actuators, and needs to re-query them.
  
-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. However, 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).\\+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. 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.
  
  

Copyright © 2015-2023 Seed Robotics Ltd

  • dynamixel/dynamixel_protocol.1502987748.txt.gz
  • Last modified: 2017/08/17 16:35
  • by Pedro Ramilo