[ODE] Problems in QuickStep
Hendrix_ at gmx.net
Tue Jun 26 07:27:12 MST 2007
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!
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
> 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
>> 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
>> 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
>> which calls the function dxJointLimitMotor::addLimot() twice.
>> This function modifies the values in the joint based off the row
>> 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
>> 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
>> 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()
>> 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.
> ODE mailing list
> ODE at ode.org
More information about the ODE