TOPP
TOPP copied to clipboard
quangounet
Repar
I'm noticing several errors with the Reparameterize function; it appears to be very sensitive to the reparameterization step size and there appears to be a lot of introduced noise. Specifically, valid velocity profiles tend to have a fair deal of noise at what appears to be the intersection point between profiles. Often times this will lead to torque profiles that violate constraints at these points despite the profile never entering the inadmissible region above the MVC.
From my robot over a very long, complex, and heavily constrained path:
The blue curve should not go above or below 0.75 in this scenario, all of those spikes above the flat part are violations. The MVC is not violated and the velocity profiles in the phase plane look good.
One can see this even in the simple test example torque_limits.py:
We can see that the constraint is violated by the black curve right at the start.
Additionally, decreasing the reparameterization step size can cause another issue. The SPieceToChunks function will throw an exception when SolveQuadraticEquation is called, usually when the reparameterization step size is set very small. Looking at SolveQuadraticEquation, it appears to be incomplete.
The error is reproducible on the examples provided with TOPP. Taking the torque_limits.py, if you set the time step to 0.0001 as in: x.ReparameterizeTrajectory(0.0001) then the failure will occur. Changing this to 0.001 as in: x.ReparameterizeTrajectory(0.001) then it will succeed.
FYI, this is why i had to write the ExtractOpenRAVETrajectoryFromProfiles function (found in TorqueLimitsRave.cpp), which will extract the profiles exactly without re-sampling.
The quadratic constraints do not have an OpenRAVE dependency and are quite agnostic to what they represent which is very nice. TOPP claims that OpenRAVE is an optional dependency. If there is no way to parameterize the profiles as a function of time without OpenRAVE then it should be required to install OpenRAVE as clearly the software cannot function without it.
Time-optimal path parameterization, Or I guess you could change the name to Time-Optimal Path Profiles (TOPP).
the function just outputs the data directly to openrave trajectory object, there's no dependency on openrave used to extract the profiles. even if openrave functionality was being used, if the function is useful to you, i'm sure you could figure out a way to remove openrave out of it.