Semanas 24-25. Moviendo a Nao como es debido

Para esta semana, mis tareas eran hacer 2 patrones fijos de movimiento para levantar a NAO y, después, hacerlo caminar de manera coherente.

Haciendo andar a Nao

Para esta tarea, decidí probar con patrones fijos de movimeinto para definir los pasos, como he ido haciendo siempre.

Lo bueno, es que encontré este video en el que se veía super bien el patrón que seguía NAO para caminar, así que, lo repliqué con mi editor de movimientos, sin tener en cuenta las ondas ya que estas de momento no aportan absolutamente nada al patrón, sólo están presentes para el futuro.

Cuando conseguí replicarlo, obtuve lo siguiente:

Así que sólo quedaba que se repitiera en bucle para conseguir la caminata. Cosa que me dio muchísimos problemas, ya que, como estoy trabajando desde un contenedor docker, las instrucciones no le llegan como es debido a NAO (o esa es la conclusión a la que he llegado viendo estos resultados):

Otra cosa que hace más robusta mi teoría es, que, cuando lleva un rato ejecutándose, sale el movimiento muy bien, el problema es el primer movimiento, como se ve en los videos anteriores:

Y no sólo eso, el NAO por sí mismo en el simulador tiene colisiones de cubo, por lo que el movimiento no es nada coherente:

nao_cubo

Cosa que no puedo editar porque en el fichero sdf ya se le indica que las colisines siguen la forma de la malla, pero no funciona no sé por qué.

Creando patrones para levantarse

Esto es aún más dificil que lo anterior, ya que me di cuenta de que los movimientos del robot real (en el que me estaba fijando) no concordaban con los de mi robot simulado, desgraciadamente no lo grabé, pero, en un frame del siguiente video NAO hace un movimiento y se queda totalmente sentado, mientras que mi NAO, al hacer ese mismo movimiento, no se mueve ni un milímetro.

Después me di cuenta de que era porque las piernas pesan menos que el resto del cuerpo, entonces “no tienen efecto”, probé a cambiar los pesos de los pies, pero aún así on funcionaba y se movía extraño.

Poniendo soluciones alternativas

Después de este dolor de muelas, mi tutor me envió el enlace para decargar webots, y fue ahí dónde encontré mi solución. Ya que este simulador proporciona unos ficheros .motion al NAO, dónde se recopilan las posiciones y los tiempos de cada joint para conseguir diferentes movimeintos, así que simplemente hice un programa nuevo para interpretarlos al igual que los json, y después fui a probarlos, pero, el simulador gazebo iba tan a trompicones que nada funcionaba (no lo podía ni grabar), así que decidí tomar la alternativa de probar todo mi código en local, ya que probando el simulador, todo funcionaba de maravilla en local, así que tuve que hacer instalaciones, pero, como tengo Ubuntu 24.04, ros2 humble no tiene soporte y no funciona, así que decidí probar con ros2 jazzy, a ver qué tal.

Como las dependencias de ambos “roses” no eran las mismas, mi proyecto no funcionaba con jazzy, por lo que decidí volver a la ubuntu 22.04 e instalar ros2 humble, aunque para ello era necesario formatear mi pc, pero, como se está usando git para el proyecto, esto no es problema, además, tengo una copia de seguridad de todos mis ficheros importantes, así que no debería perder nada.

Una vez completa la instalación de todo, probé el código para hacer que nao se levantase:

Como se puede ver, ahora nao se mueve muy fluido, y obedece perfectamente a los movimientos, consiguiendo levantarse sin problemas, aunque, cabe destacar que al final sí le cambié el peso de los pies para que pesasen más que la cabeza. También cabe destacar que el seguimiento del git ahora es mucho más rápido, ya que antes tenía que sincronizar el del docker y el de mi pc, y ahora, sólo hay que gestionar el del pc, además que la fluidez de la simulación se agradece muchísimo y se ve estupenda.

Respecto a la caminata, he de decir que el sistema “fotograma-tiempo” no es muy eficiente, a continuacion muestro un vídeo dónde se aprecia:

Como se puede ver, eso de esperar al tiempo no hace que el paso sea fluido, por lo que he pensado hacer que se mueva no esperando al tiempo, sino esperando a que la articulación en cuestión llegue a su destino.

Para ello, me puse a hacer otro programa basado en el anterior, pero se suscribe a las posiciones de los topics para poder “verlas”. Pero, cuando me puse a ello, vi que no era del todo factible, y decidí preguntar a mi tutor al respecto, pero, por el momento, probé sin esperar el tiempo a ver qué ocurría, y ocurría lo mismo, por lo que pensé que podría dividir los movimientos en submovimientos para que no fuese tan brusco, es decir, en lugar de pasar de, por ejemplo, de 0.15 a 0.2 directamente, pasar por 0.155,0.16,0.165, etc, para intentar hacer el movimiento más fluido. Pero tampoco funcionó.

Por lo que decidí dejarlo com estaba por tiempos y probar todos los patrones de movimiento que encontré en webots:

Desplazamiento lateral izquierdo

Desplazamiento lateral derecho

Caminar hacia atrás

Giros a la izquierda

40 grados

60 grados

180 grados

Giros a la derecha

40 grados

60 grados

Como se puede ver, esto de que el movimeinto sea por fotogramas es un inconveniente, ya que el movimiento no es nada fluido, aunque la simulación sí lo sea. Cosa que tendría que solucionar a continuación, aunque no se me ocurría nada para hacerlo, pero, depués, volví a la idea de dividir los movimientos en submovimientos, cosa, que al final funcionó con una simple interpolación lineal en base a la posicion actual y futura de la articulación, pero, esto era muy pesado, y a veces se saturaba, pero otras funcionaba. Dejo un video a continuación:

Que como se puede ver, cumple con los objetivos propuestos esta semana, aunque se deben hacer mejoras aún.