I’m working on an application where I’d like to have the robot output a pulse using its digital output at every predefined increment of movement of the TCP while it is continuously moving. So, if I tell it to move from point A to point B, I might ask for a few dozen pulses at even increments of length along that path. This would allow an external process to happen at predefined distances while the robot is moving.
I’ve seen some posts about how you might do something like this with URscript running a separate thread alongside your movement. However, I haven’t yet seen anyone discuss doing something like this in the context of ROS. Is this presently possible?
We are using a UR10e and ROS2 Humble.
Loads of different ways to do this.
You could divide the movement into several shorter movements and output a signal between each movement.
You can set a bit at the start of a movement. Then have a separate thread that will start a series of timers when that bit is set. First timer would pulse an output after 2 seconds the second timer would pulse an output after 4 seconds etc.
When the movement is finish the bit is reset.
Thanks for the follow up!
We’re basically doing option 1 right now, but one of the issues is that we’re interested in trying to push the limits of what the robot is capable of in terms of spatial resolution. As long as the timing is reasonably accurate (particularly the start of the pulses with respect to the start of the motion – assuming that this approach can accurately pulse at a constant frequency with reasonable accuracy), sending pulses while moving I would expect to enable us to increase spatial resolution as long as they can be timed reasonably accurately.
Any thoughts on whether we could expect reasonably repeatable timing if using option 2? Obviously acceleration is a concern for getting things to line up, but a bigger issue would be if there is a non-repeatable delay between the start of motion and the start of the pulses.