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

[mathias31415]

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?

[urfeex]

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]

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.