You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By definition a slave device should communicate over the Dynamixel bus, therefore I think it would be logical to include the baudrate as a default register in the class along with the ID, protocol, model number and firmware version.
I would recommend using the register id 8, which keeps it consistent with other devices. Also I would use the mapping table for baudrates based on the latest devices.
I think also we should implement the return delay time, as this is a common feature of the Dynamixel communication and all devices should accommodate it in case the master requires this delay. Typically the return delay time is register 9 that is already used by the protocol, so I suggest we use 10.
I can put a PR if this is ok.
The text was updated successfully, but these errors were encountered:
Hi @sonelu
Thanks for the suggestion.
I think adding the baudrate and return delay time are good practice as setting up a slave device.
I'll review and merge your PR.
Thanks!
By definition a slave device should communicate over the Dynamixel bus, therefore I think it would be logical to include the baudrate as a default register in the class along with the ID, protocol, model number and firmware version.
I would recommend using the register id 8, which keeps it consistent with other devices. Also I would use the mapping table for baudrates based on the latest devices.
I think also we should implement the return delay time, as this is a common feature of the Dynamixel communication and all devices should accommodate it in case the master requires this delay. Typically the return delay time is register 9 that is already used by the protocol, so I suggest we use 10.
I can put a PR if this is ok.
The text was updated successfully, but these errors were encountered: