Why is the Force feature acting like this?

[Ivory]

I do not understand why this Force feature from the Templates tab is skipping waypoint my_z_height.

It will only do this skip after a few seconds (maybe 6 seconds) of holding the tool flange in place with my hand. What I actually want it to do is keep pushing in the Z axis until I let go and it reaches my_z_height

Any idea of what I’m doing wrong?

I will post my program here:
force test 1.urp (1.3 KB)

[properInproperizer]

Hi Ivory

In my understanding, you are pushing in -Z direction with 10N, and you want to do it, until you reached the Z coordinate of my_z_height. Probably my_z_height is in x and y already at the same spot as Waypoint_3 was?

Correct me please if I got something wrong in this interpretation.

So, considered my understanding was correct, we have found the problem with that. In Movements within the force mode, all axes where a force is applied get ignored in the waypoints driven to. (As force mode is “stronger” than movements.)

If your goal is to push with a certain force until you reached some distance, some height, I fear you have to go with script functions.. We are doing something similiar in Polyscope X by calculating the distance moved. But you can also just go on the coordinates. Like a while loop, e.g.:

while(get_actual_tcp_pose()[2]>0.2m)

hope this helps

[Jack_N]

Hello @Ivory,

From what I have seen and just re-checked in a simulator, the force node spends the time it takes the moveL to reach the waypoint my_z_height when not in a Force Node.

If you could check and share the MoveL speed and acceleration, you should find the time it takes to reach that waypoint is the same as the time spent inside the Force template.

To fix this you can either increase the speed limit of the force template or reduce the speed of the MoveL so that they match.

P.S. On experimenting in the simulator, dropping (20mm/s^2) the acceleration in the MoveL made a difference in time taken to move.

P.S.S Changing the move speed of the waypoint directly to time instead of mm/s and setting it to 6 seconds worked in a more obvious manner, that the speed limit of the force determines the speed of the force and the time spent moving is inside the Waypoint.

Kind regards,

Jack

[dbarton]

there could be easier ways but this works.

if you need more explanation, let me know

[properInproperizer]

@dbarton

image548×363 17.8 KB

Nice, I like the approach of comparing z of the actual pose and the pose of the Waypoint.

I wouldnt loop the force function though. Like that, it starts applying force, moves to x and y of Waypoint1, and stops the force again, which also stops the movement in z direction shortly. And this repeats until z is reached. So, I would just turn the order, by putting the loop within the force function.

[efn]

You can use a wait instead of looping the action and then insert the z height (with regard to the Base frame/feature) read from the Move tab. I often do it like this at least:

[properInproperizer]

Which is in the end quite the same, as wait also uses while in the background

Okay, the Wait is more proper as it inserts the sync() statement.

[efn]

Yes, but the waypoint is obsolete since it is acting in the same direction as the force.
All it’s good for in this case is setting the z height.