PLANIFICACIÓN EN
STRIPS/PDDL
UNIVERSIDAD: UNIR MÉXICO
PERTENECE A: JUNIOR USCA HUACASI
2021
1
2
DATOS GENERALES
1. UNIVERSIDAD
UNIR MÉXICO
2. CARRERA
MAESTRÍA EN INTELIGENCIA ARTIFICIAL
3. AUTOR
JUNIOR USCA HUACASI
4. LÍNEA DE INVESTIGACIÓN
RAZONAMIENTO Y PLANIFICACIÓN AUTOMÁTICA
5. TÍTULO DEL PROYECTO
PLANIFICACIÓN EN STRIPS/PDDL
3
CAPÍTULO 2
Desarrollo
1. Dominio y Problema del escenario
1.1 Dominio
El dominio nos permite definir los aspectos relacionados al problema que no cambian.
Está compuesto por tipos, predicados y acciones.
Para el escenario que se nos ha planteado resolver, usamos 6 predicados para definir la
ubicación del paciente la ambulancia y el hospital, el estado de la ambulancia (llena o
vacía) y si existe una vía para ir de una ubicación a otra.
4
1.2 Problema
Un problema hace uso del dominio y sus reglas para completar el escenario o problema
que se debe resolver. En el problema se define exactamente que objetos existen, junto
con las distintas variables iniciales y el objetivo que se debe alcanzar.
En nuestro problema planteamos la situación especifica, con 2 pacientes ubicados en l3 y
l4, 4 ubicaciones con sus conexiones, 1 ambulancia vacía ubicada en l1 y 1 hospital ubicado
en l1. También se planteo el objetivo que es: que los pacientes se encuentren en la
ubicación del hospital.
2. Resolviendo el problema con planificadores
1.1 DecStar Team2
Configuración:
Resultados obtenidos:
5
1.2 PDB Team40
Configuración:
Resultados obtenidos:
6
1.3 Scorpion Team44
Configuración:
Resultados obtenidos:
1.4 FDMS1 Team26
Configuración:
Resultados obtenidos:
7
Los 4 planificadores ejecutados funcionaron satisfactoriamente, dando buenos resultados en el
plan resultante.
A continuación, se compara con mas detalle los resultados de los planificadores:
DecStar Team2 PDB Team40
Tiempo de ejecución: <1s Tiempo de ejecución: 1.34463s
Número de Pasos: 14 Número de Pasos: 14
Costo: 14 Costo: 14
Expandidos: 55 estados Expandidos: 15 estados
Evaluados: 86 estados Evaluados: 25 estados
Generados: 132 estados Generados: 33 estados
Dead ends: 0 estados Dead ends: 10 estados
Memoria: 4404 KB Memoria: 987420 KB
Scorpion Team44 FDMS1 Team26
Tiempo de ejecución: 200.287s Tiempo de ejecución: 0.00508741s
Número de Pasos: 14 Número de Pasos: 14
Costo: 14 Costo: 14
Expandidos: 15 estados Expandidos: 15 estados
Evaluados: 25 estados Evaluados: 25 estados
Generados: 33 estados Generados: 33 estados
Dead ends: 0 estados Dead ends: 0 estados
Memoria: 5808 KB Memoria: 5476 KB
De los 4 se puede notar que el mas lento es Scorpion, tomando 200 segundos para completar su
ejecución; todos alcanzaron resultados con buena calidad con 14 pasos y un costo de 14; el que
tuvo mas nodos expandidos, evaluados y generados es DecStar; notar que PDB tuvo 10 finales
muertos y consumió bastante memoria en su ejecución.
De los 4 se concluye que FDMS1 tuvo mejores tiempos, consumo de memoria y llego a un
resultado satisfactorio con pocos estados expandidos, evaluados y generados. Por esto se usará
FDMS1 para el resto de la actividad.
8
3. Modelando situaciones diferentes
El planificador con mejores resultados fue FDMS1 del Team26, por ello se usará para los
siguientes problemas.
3.1. Primera Variante del Problema
En esta primera variante, se agregaron 2 ubicaciones posibles adicionales, con las
conexiones como se ve en la imagen inferior, también se agrego un paciente que debe ser
llevado, como los otros a la ubicación L1.
El problema se definió y ejecutó de la siguiente forma:
3.2. Segunda Variante del Problema
En esta segunda variante, se trabajo con 14 ubicaciones posibles en total, con las
conexiones como se ve en la imagen inferior, también se consideraron 4 pacientes y 2
hospitales; los pacientes ubicados en L3 y L14 deben ser llevados al hospital mas cercano
ubicado en L12, los pacientes ubicados en L4 y L6 deben ser llevados al hospital más
cercano ubicado en L7. Notar que solo hay una ambulancia ubicada en L8. Además, en los
posibles caminos hay un ciclo formado por L9, L7, L5 y L2. L10 es considerado como un
callejón sin salida.
9
El problema se definió y ejecutó de la siguiente forma:
10
Conclusiones
Los 4 planificadores llegaron a resultados similares, cada planificador resalto en un ámbito
distinto. El planificador que mejores resultados obtuvo fue FDMS1, que usa el framework merge-
and-shrink que se encuentra en Fast Downward. El uso de factores individuales calculados por
Dijkstra y el que se almacenen las transiciones de forma agrupada por etiquetas permite tener
una heurística mas rápida y confiable.
El modelado de problema fue fácil en la situación inicial, pero a medida que se hacen cambios y se
agregan cosas, el dominio debe ser modificado para adaptarse a esos cambios y el problema crece
bastante junto con las variables de estado.
Se noto que los tiempos de ejecución dependen bastante del problema, en nuestro caso en la
ultima variante trabajamos 14 nodos, esto ocasiono que el tiempo total de ejecución fuera
7.03991 segundos, a diferencia de cuando se tenia 4 nodos donde demoraba 0.00508741
segundos, que es aproximadamente mil veces menos.
Bibliografía
Dr. Adriana Cervantes Castillo. (2021). Laboratorio: Planificación en STRIPS/PDDL
IPC 2018. (s. f.). INTERNATIONAL PLANNING COMPETITION 2018 CLASSICAL TRACKS. Recuperado
18 de octubre de 2021, de https://ipc2018-classical.bitbucket.io/
Planning.Wiki - The AI Planning & PDDL Wiki. Recuperado 18 de octubre de 2021, de
https://planning.wiki
sylabs. (s. f.). Release SingularityCE 3.8.0 · sylabs/singularity. GitHub. Recuperado 18 de octubre
de 2021, de https://github.com/sylabs/singularity/releases/tag/v3.8.0
Gnad, D., Shleyfman, A., & Hoffmann, J. (2018). DecStar – STAR-topology DECoupled. IPC 2018
Moraru, I., Edelkamp, S., Martinez, M., & Franco, S. (2018). Planning-PDBs Planner. IPC 2018
Seipp, J. (2018). Scorpion. IPC 2018
Sievers, S. (2018). Fast Downward Merge-and-Shrink. IPC 2018
