[ODE] Problems in QuickStep

[Remi Ricard]

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