[ODE] Problems in QuickStep

Tue Jun 26 22:39:12 MST 2007

Sorry to continue this, but Im d like to get it straight in my head.

To clarify which version I am using, it is a heavily modified version of ODE 
0.6, but the code in question hasn't changed since ODE 0.6 to the latest 
snapshot that I got off the ode site.

I tried to get the CVS version but it came up with an error.

anyway.

I found a situation inside of  universalGetInfo1() where at the end of the 
function:

constraint1 == false,
j->limot1.fmax == 0,
j->limot1.limit == 2,
and
limiting1 == false

which meant that

universalGetInfo1() was not incrementing m for the first constraint, while 
adlimot() would later on.

The m would not get incremented here becausse constraint1 == false.

The reason constraint1 == false was:

a)    j->limot1.fmax == 0

and

b)    testRotationalLimit() was not getting called on the first constraint, 
because limiting1 was == false.

The reason limiting1 == false was that the j->limot1.lostop and 
j->limot1->histop both had rubbish values in them (1.#QNAN00)

Now I thought Id put a bad joint into this function, so I checked the input 
in QuickStepper()

At the top of Quickstepper, a pointer to some dxJoints are passed in 
(*_joint) of length nj.

Then a copy of these joints is made by the lines:

dxJoint **joint = (dxJoint**) alloca (nj * sizeof(dxJoint*));
memcpy (joint,_joint,nj * sizeof(dxJoint*));

this being an allocation of some memory for a dxJoint class array of nj 
length, and copying a number of bytes the length of the size of a dxJoint 
times the number of joints.

now some of these joints could be derived classes of dxJoint, such as 
dxJointUniversal, which take more memory? dont they? Since dxJointUniversal 
have extra members such as  limot1 and  limot2

so the 2 lines above may or may not be allocating enough space for the joint 
array that is passed in?

and the mem copy may not be copying all of the joints members because the 
joints are not pure dxJoints, but dxJointUniversals which will have a larger 
sizeof(), and therefore need more memory copied.

Then when universalGetinfo1() is called, the dxJointUniversal pointer passed 
in is actually a pointer to the copy of the original joint, which was 
assumed to be of dxJoint size, and may not have been allocated or copied 
correctly in quickstepper.

This could be the cause of the j->limot1.lostop and j->limot1->histop both 
having rubbish values in them (1.#QNAN00)

Is my reasoning correct?

----- Original Message ----- 
From: "Patrick Enoch" <Hendrix_ at gmx.net>
To: <ode at ode.org>
Sent: Wednesday, June 27, 2007 12:27 AM
Subject: Re: [ODE] Problems in QuickStep

> Hi,
>
> yes, looks okay to me now, too :) I completely overlooked those lines
> checking for the "fmax" variable in getInfo1. Nothing needs to be
> fixed. Thanks for reviewing!
>
> Patrick
>
> On 26.06.2007, at 15:23, Remi Ricard wrote:
>
>> Hi Russel,
>>
>> You should state which version of ode you are using or even better
>> which
>> revision of the joint.cpp file you are refering to.
>>
>>> I had a problem in the function QuickStepper that I think might be a
>>> memory overwrite bug. I could be wrong tho.
>>>
>>>
>>> At the top of Quickstepper, the number of constraints are
>>> calculated and
>>> put into the variable m.
>>>
>>> Each joint is quizzed on the number of constraints via the function
>>> getInfo1()
>>>
>>> Now I've only been testing this on Universal joints, so it may be
>>> different for other joints.
>>>
>>> The getinfo1() function on a universal joint maps to
>>> universalgetinfo1()
>>>
>>> Inside of this universalgetinfo1() function the number of
>>> constraints is
>>> filled out into the dxJoint::Info1.m variable.
>>>
>>> This value can be from 4 to 6.
>>>
>>> it starts at 4, and  If (j->limot1.fmax > 0) and hence
>>> (constraint1 ==
>>> true) it will be incremented by 1
>>>
>>> If (j->limot2.fmax > 0) and hence (constraint2 == true) it will be
>>> incremented by 1
>>
>>  From revision 1108 to HEAD (I did not look before that)
>> You have the m increased if limot1.fmax > 0 or there is limits and the
>> angle is outside the range for this motor.
>>
>> Same thing for the second motor.
>>
>> So it is not only increased if fmax > 0
>>
>>>
>>> then later on in QuickStepper, the function joint->getinfo2() is
>>> called,
>>> which calls the function dxJointLimitMotor::addLimot() twice.
>>
>> Yes,
>>
>>>
>>> This function modifies the values in the joint based off the row
>>> index
>>> passed in, which in the first call to dxJointLimitMotor::addLimot
>>> () row
>>> equals 4. The first call returns a value to indicate if more rows are
>>> needed, which is used by the second call to addlimot() as the row
>>> index
>>> to update.
>>
>> The value returned by addLimot does not indicate if more rows are
>> needed. It only tells that this row was used. So the next call to
>> addLimot should fill the next row if the first call to addLimot fills
>> the row 4.
>>
>>>
>>> The criteria to work out how many rows are needed inside of
>>> addlimot()
>>> are based off wether the (limot.fmax > 0) AND wether the
>>> limot.limit is
>>> non zero.
>>
>> The value limot.limit is set in testRotationalLimit and it indicates
>> which limit is not respected.
>> limot.limit = 0 ( both limit respected)
>> limot.limit = 1  lostop not respected.
>> limot.limit = 2  hitstop not respected
>>
>>>
>>> This is different to the original calculations of how much memory
>>> would be required by the earlier calls to universalgetinfo1().
>>
>> For me everything looks OK.
>>>
>>> This means that occasionally these criteria would be different, and
>>> underestimate the required memory needed from the getinfo1()
>>> function.
>>> This resulted in the calls to addlimot() modifying memory after the
>>> allocation (which in this case I believe would be the jb array?)
>>>
>>>
>>> I modified getinfo1 to calculate the m value based off not only
>>> the fmax
>>>> 0 test, but also the limit != 0 test. This seemed to fix my bug.
>>>
>>> Is this a bug that has been in ODE for a long time that needs to be
>>> fixed or have I made a mistake somewhere?
>>
>> Need more info on the version you are talking since for me the code I
>> look at seems OK.
>>
>>
>> Remi
>> _______________________________________________
>> ODE mailing list
>> ODE at ode.org
>> http://ode.org/mailman/listinfo/ode
>
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://ode.org/mailman/listinfo/ode 

This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.