Thread too fast

URCap Development
1

Hi!

I have developed a thread which is run by a URCAP.
the main structure of my program is the following:

  • MainCustomInstruction1

    • MoveP

      • waypoint1

      • waypointN

    • customInstruction1

    • customInstruction2 (like a stop instruction)

The customInstruction1 is able to launch a thread which:

  • move across the points inside the MOveP

  • performs some math on the points inside the MoveP and then performs a movement

Problem: if i use the previous syntax, the robot performs the fist movement but is unable to perform teh movements proposed inside the thread and as a consequence jumps to the customInstruction2

If i rewrite the program in the following way:

  • MainCustomInstruction1

    • MoveP

      • waypoint1

      • waypointN

    • customInstruction1

    • Wait(20)

  • customInstruction2 (like a stop instruction)

adding a long wait ( since the movements that have to be performed by customInstruction1 can take up a lot of time) the problem does not take place and the robot is able to execute the movements that are calculated inside the thread.

I cannot figure out why does this problem happens and how to solve it

Does someone have any hints?

2

Threads can be tricky, and you’re likely running into race conditions. Is there a reason you chose to use a thread as opposed to the traverse() method provided in the API?

3

Hi!

I had a look at the possible race conditions. Does the following look like a race condition in your opinion?

  k=0
        while(k<q):
            movep(new[k], acc,vel,r)
            k=k+1
        end
4

Maybe if q is changing via a thread, or the value of k is used somewhere else. Really hard to say from just that little bit of code.

5

The code that runs is all inside a unique thread. a part of the code is the following:

def function(a):
    while(j<b):
       poseVect = poseVect2
        s = 0   
        while(s<a): 
            newVect[s] = pose_add(poseVect[s], p[0, 1, 0,0,0,0])
            s = s + 1
            sync()
        end
        
          m = 0
        while(m<a):
            movep(newVect[m], a, vel, r)
            m = m + 1
            sync()

        end
        j = j + 1
        sync()
    end
 end

This is a simplification if it.

Depending on an upper condition, different variations of this code take place.
The general setting of the code is the one you see here.

I have tried investigating the use of locks in script, but it looks like there is no lock instruction in the script language

6

Personally, I would avoid moving the robot inside a thread at all costs if I could. It’s too easy to get lost and be unsure what the robot is going to schedule next. You get into more OS design considerations, and spending more time checking race conditions, deadlocks, etc. Let your main robot program handle the movements, and let threads do additional data collection/IO monitoring.

If you’re using a CAP like you’re suggesting, you should absolutely be able to leverage the API to generate a script containing all MovePs that you’re going to be using. I can’t really see a need for this to be done in URscript. Especially since it looks like all this thread is doing is constructing some vectors of poses and then moving to them. The CAP can create the poses and store them in the model, and then in the generateScript() method you can iterate over the array, writing a sequence of MovePs that the robot can simply execute. No need for threading.

1 Like
7

Thank you for your help!

i have moved the math that i was making to the Cap and everything works fine now.