Skip to content

Continuous execution of motion primitives with blending in InstructionExecuter when sending single primitives #306

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

Open
mathias31415 opened this issue Apr 3, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@mathias31415
Copy link

Feature summary

I would like to send new motion primitives live to the InstructionExecuter. Since the full trajectory is not necessarily known at the start, using a MotionSequence is not ideal. However, I still want to utilize blending between two primitives using blend_radius.
The issue is that the InstructionExecuter only processes the next primitive once the previous one has fully completed. This causes the motion to come to a stop between two primitives.
Is there a way to enable continuous execution of motion primitives with blending when sending single primitives instead of a MotionSequence?

@mathias31415 mathias31415 added the enhancement New feature or request label Apr 3, 2025
@urfeex
Copy link
Member

urfeex commented May 6, 2025

Thank you for your suggestion. One thing to consider here is state handling:

When sending a motion to a queue -- how would we communicate context on this?

  • Is this motion going to be executed immediately?
  • If not - how big is the queue?
  • Should the caller get notified, when the motion is started?
  • Should the caller get notified, when the motion is finished / aborted?
  • Who should be notified, when the queue gets empty?
  • What would be the initial call? Would "starting motions with potentially more motions coming in" be a separate interface? Currently, executing motions or motion-sequences has a predefined call -> result structure. That wouldn't be possible with such an interface, as the original caller wouldn't necessarily be in control over future motions.

I am not saying, we shouldn't do this, I'm just brainstorming some considerations to that topic.

@mathias31415
Copy link
Author

I agree that this would make some things more complicated than they are right now.
One idea could be to start executing the motion command immediately, and if another motion command arrives in the queue in time, use blending between the two commands. If the queue is empty after the current motion, the blending is simply ignored and the robot comes to a stop as it does now.

My idea would be to assign a unique, incrementing ID to each motion command. This way, the caller could be notified when a specific motion command is started, running, completed, or aborted. To support this, the call can no longer be blocking as it is currently. Most likely, the entire state handling would need to be changed for this. The question is, of course, whether such a change is actually desirable.

I'm not sure how to integrate this elegantly while still allowing the instruction executer to be used the same way it is today.

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

No branches or pull requests

2 participants