Weights having different effects in different uses of CompoundStateSpace

Abierto
#1,204 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
robotics

Línea de trabajo

Comienza comparando CompoundStateSpace::distance con CompoundStateSampler::sampleUniformNear; después, sigue la llamada de RRTstar en la línea 277 y el uso que hace STRIDE del sampler. Determina el significado previsto de los pesos de los componentes y verifica si los cálculos de distancia y el muestreo cercano los aplican de forma coherente. Se considerará terminado cuando el comportamiento esté alineado y cubierto por las pruebas de regresión adecuadas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Hi, First of all, my assumption is that I am missing something and that this is not an issue.

CompoundStateSpace has a notion of weights for each subspace. In my case, I am setting the weight of an SO3StateSpace to be 10 instead of 1 in a compound SE3StateSpace (where the RealVectorStateSpace component has a default weight of 1).

RRTstar will then sample a random state from the overall boundry and will interpolate between the closest existing sample and the new one like so (line 277):
si_->getStateSpace()->interpolate(nmotion->state, rstate, maxDistance_ / d, xstate);
But maxDistance is calculated with CompoundStateSpaces distance function which multiplies each distance component by the weight of the corresponding subspace.

double ompl::base::CompoundStateSpace::distance(const State *state1, const State *state2) const
 {
     const auto *cstate1 = static_cast<const CompoundState *>(state1);
     const auto *cstate2 = static_cast<const CompoundState *>(state2);
     double dist = 0.0;
     for (unsigned int i = 0; i < componentCount_; ++i)
         dist += weights_[i] * components_[i]->distance(cstate1->components[i], cstate2->components[i]);
     return dist;
 }

This will effectivly mean that a subspace with higher weight will result in a greater distance for a given change in that subspace and consequently mean the interpolation will be finer (maxDistance_ / d) so the overall movement in that subspace will be more limited.
Effectivly - a higher weight for a subspace means lower sensitivity.

In contrast, STRIDE uses the CompoundStateSpace's sampleUniformNear function. This function will then call the undertlying samplers of each subspace while providing them a distance multiplied by the corresponding weight. This means that a subspace with higher weight will be sampled with higher radius which means the overall sensitivity of that subspace will be higher!

void ompl::base::CompoundStateSampler::sampleUniformNear(State *state, const State *near, const double distance)
 {
     State **comps = state->as<CompoundState>()->components;
     State **nearComps = near->as<CompoundState>()->components;
     for (unsigned int i = 0; i < samplerCount_; ++i)
         if (weightImportance_[i] > std::numeric_limits<double>::epsilon())
             samplers_[i]->sampleUniformNear(comps[i], nearComps[i], distance * weightImportance_[i]);
         else
             samplers_[i]->sampleUniform(comps[i]);
 }

In conclusion, it seems to me that the use of the weights is somewhat inconsistent when measuring the distance and when sampling the space.
If a subspace has higher effect on the distance measure, it means that when sampling near some point we should sample in a smaller radius around that point because the difference in that subspace will then have higher effect which will cancel out the smaller change and will lead to the expected result.

In contrast, the current implementation will give greater distance to a given change in a subspace with a higher weight while also sampling a larger radius in that same subspace.

Trying to make this as clear as I can - if a higher weight means higher density than a given distance should get larger as the density increases. At the same time, the higher the density, the finer the movements that should be made in order to achieve the same distance.

Thanks!
Dan.

Lenguaje dominante
C++
Estrellas
2.2k
Forks
718
Merge medio
16 h 12 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ompl/ompl

Todos los issues de ompl/ompl

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.