Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

If MAX_HANDLER_NUM can be changed to a larger number #367

Open
Bozenton opened this issue Nov 3, 2022 · 1 comment
Open

If MAX_HANDLER_NUM can be changed to a larger number #367

Bozenton opened this issue Nov 3, 2022 · 1 comment
Assignees

Comments

@Bozenton
Copy link

Bozenton commented Nov 3, 2022

Hi there.

Thanks for your work.

I am using dynamixel workbench in my ROS project. I am wondering if I can change MAX_HANDLER_NUM to a larger number, which now is only as small as 5:

If it cannot be changed to a larger number, could you please explain why?

Hope for your reply sincerely. 😃

@yun-goon yun-goon self-assigned this Jan 22, 2025
@yun-goon
Copy link

Hi @Bozenton
Sorry for the delayed response.

Although there are no previous records addressing this specific matter:

1. Hardware Resource Limitations

  • Memory Constraints: Dynamixel controllers (e.g., U2D2, OpenCR) have limited memory and processing capabilities.
    Handlers are used during sync read/write operations, and each handler consumes memory and CPU resources.
    Adding many handlers can lead to memory shortages or performance degradation.

  • Bandwidth Issues: Dynamixel communication is based on serial communication (USART), and as the number of motors and communication cycles increases, the likelihood of data collisions or delays also rises.
    Synchronizing many motors requires additional data packets, which can strain the bandwidth.

2. Stability

  • Minimizing Complexity: When designing a software library, typical use cases are considered.
    With 5 handlers, most robotic systems (e.g., robotic arms, mobile robots) can be sufficiently supported.
    A smaller default value might have been set to prioritize stability and maintainability.

  • Timing Issues: With more handlers, timing synchronization problems can arise.
    If synchronization breaks, motors might not respond to commands or behave unpredictably.
    Setting a smaller default value could be a way to avoid such issues.

You can test this by gradually increasing the number of handlers while monitoring memory usage, CPU load, and communication timing. If you encounter issues, please share your observations, and we will be happy to provide further support.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants