Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
dynamixel:dynamixel_protocol [2017/04/10 09:44] – [Other Dynamixel features and commands] Pedro Ramilo | dynamixel:dynamixel_protocol [2017/08/23 16:03] (current) – Pedro Ramilo | ||
---|---|---|---|
Line 21: | Line 21: | ||
* for other devices, consult the manufacturer' | * for other devices, consult the manufacturer' | ||
- | Seed Robotics designed the Control tables to resemble those of an Robotis MX series | + | Seed Robotics designed the Control tables to resemble those of an Robotis MX series |
**Other Protocol features to ensure reliability** | **Other Protocol features to ensure reliability** | ||
Line 35: | Line 35: | ||
'' | '' | ||
+ | |||
+ | 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 '' | After each '' | ||
Line 49: | Line 55: | ||
'' | '' | ||
+ | |||
+ | 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 " | + | * Most Dynamixel slave devices have a setting called " |
* 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 '' | * Robotis Dynamixel Wizard seems to use a timeout of 5 milliseconds when scanning the bus: when it '' | ||
- | * Other users in more complex setups | + | * 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 | ||
- | Our recommendation | + | Our recommendation, based on our measurements and experience, is to use ** 5 milliseconds** |
+ | 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, | ||
**Note:** it is important to **clarify the " | **Note:** it is important to **clarify the " | ||
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, | ||
Copyright © 2015-2023 Seed Robotics Ltd