Optimizing Planning with PersistentLazyPRMstar: Constraints vs. Unconstrained
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 15/100
Línea de trabajo
Comienza con el planificador PersistentLazyPRMstar y compara su comportamiento para los roadmaps restringido y no restringido descritos en el issue. Determina si se admite la combinación de ambos tipos de muestras e identifica por qué el roadmap más grande no logra la mejora esperada en el tiempo de planificación. Se considerará terminado cuando se documente una respuesta clara y cualquier restricción relevante.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hello! I'm new to using the Probabilistic Roadmaps (PRM) planner, so please bear with me as I navigate through this. I have a setup with two robot arms, and I'm attempting to build a roadmap using PersistentLazyPRMstar. My aim is to enhance the success rate of planning and achieve motion planning in milliseconds rather than seconds, as my operating environment for the robot arms is fairly static. My pipeline includes both constrained and unconstrained settings.
I've run the planner extensively, resulting in two roadmaps for the robot arms, each with approximately 10,000 vertices and around 10 million edges. While testing with PersistentLazyPRMstar, I've noticed some improvement in the success rate, but the planning time hasn't significantly decreased.
My question is, is it acceptable to combine both constrained and unconstrained joint configuration samples in one roadmap?
Previously, when building the roadmap for both arms in a constrained setting alone, I observed a reduction in planning time from seconds to milliseconds. This was achieved with a roadmap roughly half the size of the current one with 10,000 vertices and 10 million edges.
Please let me know if you need more information to answer my question.
- 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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ompl/ompl
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
-
Possible [optimization] Does EITstar::isValidAtResolution re-calculate the same path excessively?Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
-
AORRTC always returns zero-length path on RealVectorStateSpace (OMPL 2.0.0 Python bindings)Posiblemente ocupada @zkingston la tomó hace 182 días. Abierto
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/microsoft-ui-xaml#12515 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
FujiNetWIFI/fujinet-firmware#2261 ·
Los mantenedores suelen responder en 1 día
-
bug difficulty: easy good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
nagisa-kamishiro/rosehip#73 ·
Los mantenedores suelen responder en 1 día
-
bazel bug odb
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
The-OpenROAD-Project/OpenROAD#12095 · 1 comentario ·
Los mantenedores suelen responder en 1 día