Barrett hand odd behaviour

Typically: "How do I... ", "How can I... " questions
kleinash
Posts: 112
Joined: 28 Sep 2014, 09:58

Barrett hand odd behaviour

Post by kleinash » 09 Jan 2015, 07:39

Hi,

I move the barrett hand from one location to the next and it has this odd behaviour with the fingers. I have uploaded a video for demonstration: https://www.dropbox.com/s/btfr9588mrm8p ... t.mp4?dl=0. Is there anyway to keep them in the starting position or static wrt to the hand? i.e. to stop this?

Rgds

Eric
Posts: 186
Joined: 11 Feb 2013, 16:39

Re: Barrett hand odd behaviour

Post by Eric » 09 Jan 2015, 23:51

Hello,

As you are moving instantaneously the Barrett hand, the force applied to the fingers are infinite hence the behavior. Try to reset the dynamic of all the objects inside the Barrett hand, right after you moved the hand (to do so have a look at this post)

Cheers

Eric

kleinash
Posts: 112
Joined: 28 Sep 2014, 09:58

Re: Barrett hand odd behaviour

Post by kleinash » 12 Jan 2015, 15:05

Ok thank you.. am I correct in saying that neither of these options can be used through the remote API?

I really hope this will solve my other issue, that when I move the hand close to the object to grasp, it inadvertently knocks it before being able to grasp it.

coppelia
Site Admin
Posts: 7267
Joined: 14 Dec 2012, 00:25

Re: Barrett hand odd behaviour

Post by coppelia » 12 Jan 2015, 23:34

Yes, you cannot directly perform that task from a remote API client. But you can do it indirectly:

From the remote API client, send a trigger signal to a child script that will wait for that signal. If the child script receives that signal, it will perform the code mentioned above.

Cheers

kleinash
Posts: 112
Joined: 28 Sep 2014, 09:58

Re: Barrett hand odd behaviour

Post by kleinash » 13 Jan 2015, 10:19

Hi,

I am sorry to ask but can you help talk me through this please?

I have tried using simxQuery, but I am getting this error in Matlab:

Code: Select all

Error using vrchk (line 41)
Remote API function call returned with error code: 2. Explanation: The
function timed out (probably the network is down or too slow).


Error in barrett01 (line 108)
    vrchk(vrep, res);
My lines 107-111 looks like this:

Code: Select all

[res, replyData] = vrep.simxQuery(h.id, 'request', 'send me a 42', 'reply', 10000);
vrchk(vrep, res);
if (res == vrep.simx_return_ok)
      fprintf('The reply is: %s\n', replyData);
end
Should I be using another communication call?

This is what the child script looks like now:

Code: Select all

--if (sim_call_type==sim_childscriptcall_resetDynamic) then 
req = simGetStringSignal("request")
if (req) then
	simClearStringSignal("request")
if (req=="send me a 42") then
	simSetStringSignal("reply","42\0") -- will be automatically cleared by the client
end
--end
	--allObjectsToExplore={modelBase}
	--while (#allObjectsToExplore>0) do
	--	obj=allObjectsToExplore[1]
	--	table.remove(allObjectsToExplore,1)
	--	simResetDynamicObject(obj)
	--	index=0
	--while true do
	--	child=simGetObjectChild(obj,index)
	--	if (child==-1) then
	--		break
	--	end
	--	table.insert(allObjectsToExplore,child)
	--	index=index+1
	--end
end
Is this the right way to remove the barrett and place it back where I now want it to be?
How do I talk to this: sim_call_type==sim_childscriptcall_resetDynamic ? should I be talking to the if sim_call_type at all or should I just have a the req = simGetStringSignal("request")?

Thank you for your help.

Rgds

coppelia
Site Admin
Posts: 7267
Joined: 14 Dec 2012, 00:25

Re: Barrett hand odd behaviour

Post by coppelia » 13 Jan 2015, 12:09

For what you want to do, I would do it as follows:

on the Matlab side:

Code: Select all

vrep.simxSetStringSignal(h.id,'cmd','resetBarretHand',vrep.simx_opmode_oneshot);
On the V-REP side, inside of a non-threaded child script:

Code: Select all

if (sim_call_type==sim_childscriptcall_actuation) then
	local cmd=simGetStringSignal('cmd')
	if cmd then
		if cmd=='resetBarretHand' then
			-- reset the hand here
		end
		simClearStringSigfnal('cmd')
	end
end
On the Matlab side, you simply post a command and forget about it (you don't really need to wait for an answer).

If you are postion commands in a high frequency, then Matlab might overwrite previous commands not yet executed. In that case, I would use on the Matlab side simxWriteStringStream. On the V-REP side, you will then have to decompose the received string, then extract a command one-by-one. For that you will need some kind of simply rule that helps knowing how long each command in the string is, in order to correctly decompose the individual commands.

Cheers

kleinash
Posts: 112
Joined: 28 Sep 2014, 09:58

Re: Barrett hand odd behaviour

Post by kleinash » 13 Jan 2015, 13:16

Ok thank you..

So does simxSetStringSignal send a sim_childscriptcall_actuation sim call type?

for this line:

Code: Select all

-- reset the hand here
is this what I have to do, and should I do this before or after I have moved the hand? :

Code: Select all

allObjectsToExplore={modelBase}
while (#allObjectsToExplore>0) do
   obj=allObjectsToExplore[1]
   table.remove(allObjectsToExplore,1)
   simResetDynamicObject(obj)
   index=0
   while true do
      child=simGetObjectChild(obj,index)
      if (child==-1) then
         break
      end
      table.insert(allObjectsToExplore,child)
      index=index+1
   end
end
I don't know whether this issue is related - but when I run this my matlab crashes, sometimes it works but I would say 60% of the time it crashes.. asks for a crash report and then I have to restart Matlab R2013b..

EDIT: I am not getting this to work.. do you think maybe its because of the handle that is specifying the hand but not the fingers? I am trying to position the hand and the fingers should just stay constant wrt to the hand..

coppelia
Site Admin
Posts: 7267
Joined: 14 Dec 2012, 00:25

Re: Barrett hand odd behaviour

Post by coppelia » 13 Jan 2015, 21:23

if you call simxSetStringSignal from your remote API, it will not trigger a specific child script call type. There is only a limited type of child script calls (e.g. initialization, clean-up, actuation or sensing). If you want to read the string signal, you can do this in any of the child script call types. I would intercept this in the actuation phase, since the hand movement is directly followed by a reset phase:

Code: Select all

if (sim_call_type==sim_childscriptcall_actuation) then
   local cmd=simGetStringSignal('cmd')
   if cmd then
      if cmd=='resetBarretHand' then
         simSetObjectPosition(modelBase,-1,{x,y,z})
         simSetObjectOrientation(modelBase,-1,{a,b,g})
         allObjectsToExplore={modelBase}
         while (#allObjectsToExplore>0) do
            obj=allObjectsToExplore[1]
            table.remove(allObjectsToExplore,1)
            simResetDynamicObject(obj)
            index=0
            while true do
               child=simGetObjectChild(obj,index)
               if (child==-1) then
                  break
               end
               table.insert(allObjectsToExplore,child)
               index=index+1
            end
         end
      end
      simClearStringSignal('cmd')
   end
end
Cheers

kleinash
Posts: 112
Joined: 28 Sep 2014, 09:58

Re: Barrett hand odd behaviour

Post by kleinash » 14 Jan 2015, 08:26

Hi,

I have added below the actuation area (just under like yours) but the Barrett is still behaving badly.. is it where I am putting this:

Code: Select all

vrep.simxSetStringSignal(h.id,'cmd','resetBarretHand',vrep.simx_opmode_oneshot);
line perhaps? Do I add it before or after

Code: Select all

res = vrep.simxSetObjectPosition(h.id, h.bhand, pos_relative, new_pos, vrep.simx_opmode_oneshot); 
?

coppelia
Site Admin
Posts: 7267
Joined: 14 Dec 2012, 00:25

Re: Barrett hand odd behaviour

Post by coppelia » 14 Jan 2015, 10:15

What is very important:

you need to change the position AND reset the model at the same time! If you do this in two successive remote API commands, then you will have some delay between both.

So my suggestion is that you create a trigger signal on the remote API side that tells a child script to change the position and reset the model (like the code I wrote previously: the change of position needs to be executed just before the reset phase!)

Cheers

Post Reply