[ODE] Problems in QuickStep

[Patrick Enoch]

I agree.

"testRotationalLimit" returns 1 iff the angle is over the limits (and  
sets the variable "limit" accordingly), otherwise it will return 0.  
This value is used for the calculation of "m" in any getInfo1 that  
uses "dxJointLimitMotor".

"addLimot" will modify an additional row, if ("limit" != 0) OR (fmax  
 > 0). (Look at fourth line of function "addLimot").

--

This is a proposed fix for this:

int dxJointLimitMotor::testRotationalLimit (dReal angle)
{
   int retval=0;
   // test limits for overshooting
   if (angle <= lostop) {
     limit = 1;
     limit_err = angle - lostop;
     retval = 1;
   }
   else if (angle >= histop) {
     limit = 2;
     limit_err = angle - histop;
     retval = 1;
   }
   else {
     limit = 0;
     retval = 0;
   }
   // test for being powered
   if (fmax > 0)
     retval = 1;

   return retval;
}

--

I cannot browse the online repository. We need at least 2 other ppl  
reviewing this.

Patrick

On 26.06.2007, at 07:53, Russell Bartley wrote:

> 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
>
> then later on in QuickStepper, the function joint->getinfo2() is  
> called, which calls the function dxJointLimitMotor::addLimot() twice.
>
> 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 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.
>
> This is different to the original calculations of how much memory  
> wouldbe required by the earlier calls to universalgetinfo1().
>
> 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?
>
>
>
>
> 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.
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://ode.org/mailman/listinfo/ode