[ODE] Problems in QuickStep

[Patrick Enoch]

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