Motoman Driver Feedback vs Commanded position

[Vladimír Petrík]

Hi all,

we have dual arm motoman robot with DX100 controller (CloPeMa project) and we have successfully moved with the robot using motoman_driver package.
ChangeLists including source codes (in development) are available at CloPeMa DX100

However I found a problem with feedback from the robot, namely with status 'in_motion' which is not synchronized with robot movement (difference about 100ms).

If we use feedback position from the controller it looks like robot is still moving even when queue is empty - how is it possible? (in my understanding of motion this should not happen, see below)
Using the commanded position, the 'in_motion' status is correct so I think it is not problem of communication latency.
You can find graphs from experiment in attachment.

I will try to explain my understanding (and my modification) of the driver movement which can help with problem solving:

In time i when interpolationClk is announced (every 8ms):
 - The increment from time i-1 is applied to the robot position
 - The increment for time i+1 is computed
 - If there is no point in queue the controller announce 'not in motion' to the PC
 - My modification: If there is no point in queue the controller will announce 'not in motion' in time i+1 (another flag added not just queue size checking)

I thought that modification will solve synchronization problem but it did not help.

In last two years we used hard coded sleeps in all our codes because there were no correct feedback about motion status - we would like to avoid such a solution with a new driver so any help is welcome and appreciate.

Best wishes
Vladimir

[eric....@motoman.com]

Hi Vladimir,

The motoman_driver is adding the increments to the motion command.  That command goes through an averaging filter for motion smoothness and then PID control loop command the motion to reduce the error between the feedback position and command position.  The even thus the motion command is completed, the actual feedback position lag behind a little bit so the robot will keep on moving a little afterward.

So I guess that the "Not In Motion" is misleading.  It is indicating that we've completed transmitting the current motion command but the robot (feedback) may not have reach the command position yet.  As you pointed out, it may take about 100 ms to really reach the position.  The DX100 clock is at 4 ms, so even by doing i+1, it will not compensate for the averaging and damping in the system.

We would have to check is there is an internal signal that can be used or make a comparison between feedback and motion to check that we have truly stop moving.

Eric

[Vladimír Petrík]

Hi Eric,
thanks for the explanation.
 
Based on your answer, I modified our code to compare commanded and feedback positions and report 'in motion' if difference is higher than START_MAX_PULSE_DEVIATION for at least one axis in at least one group.

If you will find better solution please let me known.

thanks,
Vladimir

--
You received this message because you are subscribed to the Google Groups "swri-ros-pkg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swri-ros-pkg-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.