BLOG DE PRÁCTICAS EXTERNAS JDEROBOT ALBERTO LEÓN LUENGO
¡Bienvenido! En esta web se encuentra todo el contenido visto y aprendido en mis
Prácticas Externas realizadas con la empresa JdeRobot durante el curso 2025-2026
en el Grado en Ingeniería de Robótica Software.
A continuación, se muestran todas las entradas correspondientes a los blogs de prácticas
realizados durante el transcurso de las mismas, cuyo contenido se divide en las
20 semanas que ha durado mi periodo de Prácticas Externas.
SEMANA 01: 22-09-2025 al 26-09-2025
Instalación de Docker en Ubuntu 24.04
En primer lugar, se abre una terminal por defecto en el directorio
HOME, a través de la cual se irán ejecutando los siguientes
comandos:
PASO 1: Acceso al escritorio
cd Escritorio/
PASO 2: Clonación del repositorio de RoboticsAcademy
Este script intenta configurar el entorno de desarrollo. Al ejecutar este script por
primera vez, aparecen varios errores, ya que faltan dependencias por instalar
(yarn y docker).
./scripts/develop_academy.sh
./scripts/develop_academy.sh: linea 146: yarn: orden no encontrada ./scripts/develop_academy.sh: linea 147: yarn: orden no encontrada ./scripts/develop_academy.sh: linea 166: docker: orden no encontrada Cleaning up... ./scripts/develop_academy.sh: linea 28: docker: orden no encontrada
PASO 5: Ejecución de comandos de configuración
Todos los comandos que se ejecutan a continuación se encargan de actualizar los
repositorios de APT, instalar las herramientas necesarias (certificados y curl),
crear el directorio para las claves de Docker, descargar la clave GPG de
Docker, dar permisos de lectura a dicha clave, añadir el repositorio de Docker a
APT y volver a actualizar la lista de paquetes.
PASO 9: Verificación de la versión de Docker instalada
docker --version
PASO 10: Creación del grupo de usuarios de Docker
sudo groupadd docker
PASO 11: Adición del usuario actual al grupo Docker
sudo usermod -aG docker $USER
PASO 12: Cambio de grupo
newgrp docker
PASO 13: Reejecución del script de preparación
sudo ./scripts/develop_academy.sh
IMPORTANTE: Hay que ejecutar el comando con sudo.
Configuración y uso de Docker en Visual Studio Code
PASO 1: Apertura de RoboticsAcademy en Visual Studio Code
cd Escritorio/RoboticsAcademy/
code .
PASO 2: Instalación de las extensiones de Docker
Tras instalar ambas extensiones, es necesario reiniciar el equipo para que
Docker y Visual Studio Code se integren correctamente.
PASO 3: Bucle de trabajo a seguir en Visual Studio Code
- Hacer los cambios necesarios dentro del directorio
RoboticsInfrastructure/.
- Hacer commit y push de dichos cambios en una nueva rama (Publish Branch).
- Acceder al directorio RoboticsAcademy/scripts/RADI/.
cd scripts/RADI/
- Ejecutar el script build.sh dentro de la nueva rama.
./build.sh -i <branch_name>
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
- Volver al directorio principal.
cd ../..
- Cambiar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml.
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
- Ejecutar el script de preparación (sin sudo) para lanzar el Docker de
RoboticsAcademy con todos los cambios realizados.
./scripts/develop_academy.sh
- Acceder a la dirección web http://0.0.0.0:7164/ que aparece en la terminal al
ejecutar el comando anterior para poder entrar a Unibotics en local y verificar
que los cambios se han realizado correctamente.
IMPORTANTE: En el caso de que los cambios se hayan realizado
únicamente en el fichero database/universes.sql, sólo sería
necesario realizar el último de todos los pasos que componen este bucle de trabajo,
escrito a continuación.
./scripts/develop_academy.sh
Lanzamiento del RoboticsBackend en local
PASO 1
Para lanzar el RoboticsBackend y poder trabajar en Unibotics en local, se debe
ejecutar el siguiente comando en la terminal:
Se deja ejecutando el comando anterior ejecutando en la terminal y se accede a la
página web de Unibotics.
PASO 3
Una vez dentro de Unibotics, se selecciona el ejercicio en el que se quiera
trabajar.
IMPORTANTE: Para que todo funcione correctamente, se debe
seleccionar la opción 'Local ROS2 (RoboticsBackend 4)', que aparece en la esquina
superior derecha al hacer clic en la foto de perfil.
PASO 4
Verificar que, tanto la simulación en Gazebo como en la terminal, se han lanzado
correctamente.
Lanzamiento del RoboticsDatabase junto a RoboticsAcademy en local
PASO 1
Para poder lanzar RoboticsDatabase junto a RoboticsAcademy, se debe ejecutar el
siguiente comando en la terminal:
IMPORTANTE: Este comando se ejecuta ÚNICAMENTE la primera vez que
se lance el RoboticsDatabase junto a RoboticsAcademy.
PASO 2
Una vez ejecutado el comando anterior, ya no será necesario ejecutarlo
más veces, ya que lo que ha hecho este comando es crear un nuevo contenedor para
RoboticsDatabase, al cual se llamará con el flag --link cuando se vaya a lanzar
RoboticsAcademy. A continuación se muestran 3 formas diferentes de lanzar
RoboticsDatabase junto a RoboticsAcademy:
Lanzamiento de RoboticsDatabase + RoboticsAcademy (NVIDIA + GPU)
Por último, para comprobar que todos los Dockers que se van a utilizar se hayan
descargado y configurado correctamente, se debe ejecutar el siguiente comando
en la terminal:
sudo docker images
Cuyo resultado debe ser el siguiente:
REPOSITORY TAG IMAGE ID CREATED SIZE jderobot/robotics-backend latest 0e2a10ccfaf4 5 days ago 27.2GB jderobot/robotics-academy latest 1c67a50c79c2 13 days ago 28.5GB jderobot/robotics-database latest 3a1d0407347e 13 days ago 483MB
SEMANA 02: 29-09-2025 al 03-10-2025
Ejercicio de calentamiento: Cambiar el mundo a un ejercicio
Para ir familiarizándome con el software de RoboticsInfrastructure, se me ha
pedido como primer ejercicio cambiar el mundo de Gazebo de uno de los ejercicios
que ya se haya migrado a Gazebo Harmonic.
En primer lugar, he accedido al fichero
RoboticsInfrastructure/database/universes.sql para localizar
aquellos mundos ya migrados a Gazebo Harmonic.
IMPORTANTE: La forma más sencilla de identificar los mundos migrados
a Gazebo Harmonic, es mirando si en su columna type aparece escrito
gazebo o gz. En caso de que aparezca escrito
gazebo, significa que ese mundo todavía se encuentra en Gazebo 11
y no se ha migrado. Pero si aparece escrito gz, significa que ese
mundo ya se ha migrado a Gazebo Harmonic.
A continuación se listan todos los mundos que tienen escrito gz
en su columna type, y que podrían utilizarse para llevar a cabo
este ejercicio:
En mi caso, he seleccionado los mundos correspondientes a los ejercicios de
Laser Mapping (número 12) y Marker Based Visual Loc
(número 25). El mundo del Laser Mapping es un almacén tipo Amazon,
mientras que el mundo del Marker Based Visual Loc es una casa de
dos plantas.
El resultado final de este ejercicio visualizará el almacén del ejercicio
Laser Mapping en la ventana de Gazebo del ejercicio
Marker Based Visual Loc.
A continuación se muestra cómo se ve inicialmente el ejercicio
Marker Based Visual Loc al lanzar el Docker de RoboticsAcademy
antes de realizar cualquier cambio en el código:
El único cambio que he realizado ha sido en el fichero
RoboticsInfrastructure/Launchers/marker_visual_loc.launch.py
en la siguiente línea:
# ANTES (MUNDO ORIGINAL) world_file_name = "marker_visual_loc.world"
# DESPUÉS (MUNDO NUEVO) world_file_name = "laser_mapping.world"
Una vez realizado este cambio, he hecho commit y push en una nueva rama que he creado
y publicado llamada test-aleon2020. Es importante hacer esto
siempre para evitar así cualquier tipo de conflicto con la rama principal.
Como los cambios se han realizado en un fichero que se encuentra dentro de
RoboticsInfrastructure, es obligatorio generar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i test-aleon2020
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
IMPORTANTE: Si es la primera vez que se ejecuta este script, el
tiempo que tardará en ejecutarse por completo será considerablemente largo, ya que
debe configurar todo el entorno. Si es la primera vez que se ejecuta tardará unos
35-45 minutos, de lo contrario, tardará unos 2-3 minutos.
Una vez finalizada la ejecución del script build.sh, se debe
regresar al repositorio principal:
cd ../..
Pero antes de ejecutar el script develop_academy.sh, hay que
modificar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml:
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
Con este cambio ya realizado, ya se puede lanzar el script
develop_academy.sh:
./scripts/develop_academy.sh
Y por último, sólo quedaría acceder a la dirección web `http://0.0.0.0:7164/` que
aparece en la terminal al ejecutar el comando anterior para poder entrar a Unibotics
en local y verificar que los cambios se han realizado correctamente.
A continuación se muestra cómo se ve el ejercicio
Marker Based Visual Loc al lanzar el Docker de RoboticsAcademy
con todos estos cambios realizados en el código:
SEMANA 03: 06-10-2025 al 10-10-2025
Migración del ejercicio Obstacle Avoidance a Gazebo Harmonic
Una vez realizado este primer ejercicio de calentamiento para irme familiarizando
con el código de RoboticsInfrastructure, se me ha pedido realizar la migración
completa de Gazebo 11 a Gazebo Harmonic del ejercicio
Obstacle Avoidance, que introduce de forma práctica la navegación
local mediante el uso de campos de fuerza virtuales (VFF, Virtual Force Fields).
A continuación, se encuentran todos los ficheros que se han modificado y/o creado
(y de qué forma) para poder llevar a cabo la migración completa de este ejercicio
de Gazebo 11 a Gazebo Harmonic:
En este fichero se han modificado las partes correspondientes a las etiquetas
<plugin> y <sensor>, donde el plugin pasa de estar declarado dentro
del sensor a integrarse en él. Además, es importante añadir al final de la nueva
versión los plugins correspondientes al diff-drive-system y al
odometry-publisher-system:
Este fichero se crea de cero en la ruta especificada, aunque se puede coger
cualquier fichero del tipo robot_params.yaml como referencia.
En este caso, sólo se añaden los topics correspondientes al publicador y al
subscriptor del plugin del diff-drive-system y aquellos relativos al publicador
del plugin del láser:
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "F1ROS/odom" ros_type_name: "nav_msgs/msg/Odometry" gz_type_name: "gz.msgs.Odometry" direction: GZ_TO_ROS
# gz topic subscribed to by DiffDrive plugin - ros_topic_name: "cmd_vel" gz_topic_name: "/F1ROS/cmd_vel" ros_type_name: "geometry_msgs/msg/Twist" gz_type_name: "gz.msgs.Twist" direction: ROS_TO_GZ
# gz topic published by Sensors plugin (LIDAR) - ros_topic_name: "f1/laser/scan" gz_topic_name: "f1/laser/scan" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
En este caso, la única modificación realizada en este fichero es la
adición de la línea f1/params para que el fichero que se acaba de
crear (f1_result_laser_no_cam.yaml) se tenga en cuenta a la hora de
lanzar el Docker:
Una vez creado el directorio obstacle_avoidance/, y a su vez dentro
de él el fichero spawn_robot.launch.py, lo único que habría que
hacer es coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y sólamente habría que comentar todo
lo relativo a las variables start_gazebo_ros_image_bridge_cmd y
start_gazebo_ros_depth_bridge_cmd, y lo más importante, modificar
el nombre del fichero que se le pasa como argumento a bridge_params (en este caso,
f1_renault_laser_no_cam.yaml):
# Copyright 2019 Open Source Robotics Foundation, Inc. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License.
import os
from ament_index_python.packages import get_package_share_directory from launch import LaunchDescription from launch.actions import DeclareLaunchArgument from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description(): # Get the urdf file model_folder = "f1_renault_laser_no_cam" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, lo único que habría que hacer es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y modificar únicamente las líneas correspondientes a las
variables robot_launch_dir y world_file_name,
correspondientes a las rutas en las que se encuentran el directorio que almacena el
fichero spawn_robot.launch.py y el fichero del mundo que utiliza
este ejercicio.
import os
from ament_index_python.packages import get_package_share_directory
from launch import LaunchDescription from launch.actions import ( DeclareLaunchArgument, IncludeLaunchDescription, SetEnvironmentVariable, AppendEnvironmentVariable, ) from launch.launch_description_sources import PythonLaunchDescriptionSource from launch.substitutions import LaunchConfiguration, Command from launch_ros.actions import Node from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description():
x = LaunchConfiguration("x") y = LaunchConfiguration("y") z = LaunchConfiguration("z") roll = LaunchConfiguration("R") pitch = LaunchConfiguration("P") yaw = LaunchConfiguration("Y")
IMPORTANTE: En caso de que no se haya creado dentro del directorio
obstacle_avoidance/ el fichero
robot_state_publisher.launch.py, es obligatorio comentar
y/o eliminar del código todo lo relacionado con la variable
robot_state_publisher_cmd.
En este fichero, lo único que habría que realizar es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y sustituir todas aquellos flags <include> de la versión antigua por
aquellos que aparezcan en la versión nueva.
En este fichero, lo único que habría que realizar es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic, ya que el contenido de todos los ficheros existentes en este directorio y
de este formato son exactamente iguales.
Este es uno de los cambios más sencillos de realizar en todo el proceso de migración.
Lo único que habría que hacer es identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Obstacle Avoidance) y cambiar el valor de
la columna type de gazebo a gz:
Una vez realizados todos estos cambios en todos los ficheros mencionados,
he hecho commit y push en una nueva rama que he creado y publicado llamada
obstacle-avoidance-harmonic. Es importante hacer esto siempre para
así evitar cualquier tipo de conflicto con la rama principal.
Como todos los cambios se han realizado en ficheros que se encuentran dentro de
RoboticsInfrastructure, es obligatorio generar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i obstacle-avoidance-harmonic
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
Una vez finalizada la ejecución del script build.sh, se debe
regresar al repositorio principal:
cd ../..
Pero antes de ejecutar el script develop_academy.sh, hay que
modificar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml:
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
Con este cambio ya realizado, ya se puede lanzar el script
develop_academy.sh:
./scripts/develop_academy.sh
Y por último, sólo quedaría acceder a la dirección web `http://0.0.0.0:7164/` que
aparece en la terminal al ejecutar el comando anterior para poder entrar a Unibotics
en local y verificar que los cambios se han realizado correctamente.
A continuación se muestra cómo se ve el ejercicio Obstacle Avoidance
al lanzar el Docker de RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto el escenario como el coche han sido migrados
correctamente, se muestra una pequeña animación del coche moviéndose en línea
recta para verificar que todo el proceso se ha realizado correctamente:
SEMANA 04: 13-10-2025 al 17-10-2025
Migración del ejercicio Global Navigation a Gazebo Harmonic
Con el ejercicio de Obstacle Avoidance ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
segundo ejercicio, en este caso, Global Navigation, que introduce
de forma práctica la navegación global mediante el uso y la implementación de la
lógica del algoritmo de planificación de ruta del gradiente (GPP, Gradient Path
Planning).
A continuación, se encuentran todos los ficheros que se han modificado y/o creado
(y de qué forma) para poder llevar a cabo la migración completa de este ejercicio
de Gazebo 11 a Gazebo Harmonic:
En este caso, no ha sido necesario llevar a cabo ninguna modificación en este
fichero, ya que el coche utilizado para esta versión ya se encuentra migrado a
Gazebo Harmonic:
<!-- collision & visual both use the same mesh --> <collision name="collision"> <geometry> <mesh> <uri>model://taxi_holo_ROS_harmonic/meshes/taxi_holo.obj</uri> </mesh> </geometry> </collision> <visual name="visual"> <geometry> <mesh> <uri>model://taxi_holo_ROS_harmonic/meshes/taxi_holo.obj</uri> </mesh> </geometry> </visual> </link>
<!-- VelocityControl plugin: applies Twist directly to the chassis link --> <plugin filename="gz-sim-velocity-control-system" name="gz::sim::systems::VelocityControl">
Este fichero se crea de cero en la ruta especificada, aunque se puede coger
cualquier fichero del tipo robot_params.yaml como referencia.
En este caso, se añaden los topics correspondientes a los plugins publicador y
subscriptor del DiffDrive:
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/taxi_holo/odom" ros_type_name: "nav_msgs/msg/Odometry" gz_type_name: "gz.msgs.Odometry" direction: GZ_TO_ROS
# gz topic subscribed to by DiffDrive plugin - ros_topic_name: "cmd_vel" gz_topic_name: "/taxi_holo/cmd_vel" ros_type_name: "geometry_msgs/msg/Twist" gz_type_name: "gz.msgs.Twist" direction: ROS_TO_GZ
En este caso, la única modificación realizada en este fichero es la
adición de las líneas taxi_navigator/launch,
taxi_navigator/params y taxi_navigator/worlds,
para que el fichero que se acaba de crear (taxi_holo_ROS_harmonic.yaml),
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio global_navigation/, y a su vez dentro
de él el fichero spawn_robot.launch.py, lo único que habría que
hacer es coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y sólamente habría que comentar todo
lo relativo a las variables start_gazebo_ros_image_bridge_cmd y
start_gazebo_ros_depth_bridge_cmd, y lo más importante, modificar
el nombre del fichero que se le pasa como argumento a bridge_params (en este caso,
taxi_holo_ROS_harmonic.yaml):
# Copyright 2019 Open Source Robotics Foundation, Inc. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License.
import os
from ament_index_python.packages import get_package_share_directory from launch import LaunchDescription from launch.actions import DeclareLaunchArgument from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description(): # Get the urdf file model_folder = "taxi_holo_ROS_harmonic" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, lo único que habría que hacer es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y modificar únicamente las líneas correspondientes a las
variables robot_launch_dir y world_file_name,
correspondientes a las rutas en las que se encuentran el directorio que almacena el
fichero spawn_robot.launch.py y el fichero del mundo que utiliza
este ejercicio.
import os
from ament_index_python.packages import get_package_share_directory
from launch import LaunchDescription from launch.actions import ( DeclareLaunchArgument, IncludeLaunchDescription, SetEnvironmentVariable, AppendEnvironmentVariable, ) from launch.launch_description_sources import PythonLaunchDescriptionSource from launch.substitutions import LaunchConfiguration, Command from launch_ros.actions import Node from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description():
x = LaunchConfiguration("x") y = LaunchConfiguration("y") z = LaunchConfiguration("z") roll = LaunchConfiguration("R") pitch = LaunchConfiguration("P") yaw = LaunchConfiguration("Y")
IMPORTANTE: En caso de que no se haya creado dentro del directorio
global_navigation/ el fichero
robot_state_publisher.launch.py, es obligatorio comentar
y/o eliminar del código todo lo relacionado con la variable
robot_state_publisher_cmd.
En este fichero, lo único que habría que realizar es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y sustituir todas aquellos flags <include> de la versión antigua por
aquellos que aparezcan en la versión nueva.
Este es uno de los cambios más sencillos de realizar en todo el proceso de migración.
Lo único que habría que hacer es identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Global Navigation) y cambiar el valor de
la columna type de gazebo a gz:
# GAZEBO 11 8 City Large /opt/jderobot/Launchers/taxi_navigator.launch.py None ROS2 gazebo {0.0,0.0,0.0,0.0,0.0,0.0}
# GAZEBO HARMONIC 8 City Large /opt/jderobot/Launchers/taxi_navigator.launch.py None ROS2 gz {0.0,0.0,0.0,0.0,0.0,0.0}
Una vez realizados todos estos cambios en todos los ficheros mencionados,
he hecho commit y push en una nueva rama que he creado y publicado llamada
global-navigation-migration. Es importante hacer esto siempre para
así evitar cualquier tipo de conflicto con la rama principal.
Como todos los cambios se han realizado en ficheros que se encuentran dentro de
RoboticsInfrastructure, es obligatorio generar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i global-navigation-migration
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
Una vez finalizada la ejecución del script build.sh, se debe
regresar al repositorio principal:
cd ../..
Pero antes de ejecutar el script develop_academy.sh, hay que
modificar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml:
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
Con este cambio ya realizado, ya se puede lanzar el script
develop_academy.sh:
./scripts/develop_academy.sh
Y por último, sólo quedaría acceder a la dirección web `http://0.0.0.0:7164/` que
aparece en la terminal al ejecutar el comando anterior para poder entrar a Unibotics
en local y verificar que los cambios se han realizado correctamente.
A continuación se muestra cómo se ve el ejercicio Global Navigation
al lanzar el Docker de RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto el escenario como el coche han sido migrados
correctamente, se muestra una pequeña animación del coche moviéndose en línea
recta para verificar que todo el proceso se ha realizado correctamente:
SEMANA 05: 20-10-2025 al 24-10-2025
Migración del ejercicio Autoparking a Gazebo Harmonic
Con el ejercicio de Global Navigation ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
tercer ejercicio, en este caso, Autoparking, que consiste en la
implementación de la lógica de un algoritmo de navegación en un vehículo autónomo
que se encuentra buscando aparcamiento.
A continuación, se encuentran todos los ficheros que se han modificado y/o creado
(y de qué forma) para poder llevar a cabo la migración completa de este ejercicio
de Gazebo 11 a Gazebo Harmonic:
En este caso, no ha sido necesario llevar a cabo ninguna modificación en este
fichero, ya que el coche utilizado para esta versión ya se encuentra migrado a
Gazebo Harmonic.
IMPORTANTE: Dada la gran extensión en cuanto a líneas se refiere
de este fichero, adjunto a continuación un enlace a dicho fichero en el que se
puede visualizar todo su contenido.
Este fichero se crea de cero en la ruta especificada, aunque se puede coger
cualquier fichero del tipo robot_params.yaml como referencia.
En este caso, se añaden los topics correspondientes al plugin subscriptor del
DiffDrive, y los plugin publicadores del DiffDrive y de los 3 sensores láser LIDAR.
# gz topic published by DiffDrive plugin - ros_topic_name: "/prius_autoparking/odom" gz_topic_name: "/prius_autoparking/odom" ros_type_name: "nav_msgs/msg/Odometry" gz_type_name: "gz.msgs.Odometry" direction: GZ_TO_ROS
# gz topic subscribed to by DiffDrive plugin - ros_topic_name: "/prius_autoparking/cmd_vel" gz_topic_name: "/prius_autoparking/cmd_vel" ros_type_name: "geometry_msgs/msg/Twist" gz_type_name: "gz.msgs.Twist" direction: ROS_TO_GZ
# gz topic published by Sensors plugin (LIDAR) - ros_topic_name: "/prius_autoparking/scan_front" gz_topic_name: "/prius_autoparking/scan_front" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
# gz topic published by Sensors plugin (LIDAR) - ros_topic_name: "/prius_autoparking/scan_side" gz_topic_name: "/prius_autoparking/scan_side" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
# gz topic published by Sensors plugin (LIDAR) - ros_topic_name: "/prius_autoparking/scan_back" gz_topic_name: "/prius_autoparking/scan_back" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
En este caso, la única modificación realizada en este fichero es la
adición de las líneas autopark_harmonic/launch,
autopark_harmonic/models, autopark_harmonic/params
y autopark_harmonic/worldspara que el fichero que se acaba de crear
(prius_autoparking_3laser_harmonic.yaml), se tenga en cuenta a la hora de lanzar el Docker:
Una vez creados los directorios autopark_line/,
autopark_battery/ y autopark_sideways/, y a su vez
dentro de cada uno de ellos el mismo fichero spawn_robot.launch.py,
lo único que habría que hacer es coger cualquier fichero con el mismo nombre de otro
ejercicio que ya esté migrado a Gazebo Harmonic, copiar su contenido y sólamente
habría que comentar todo lo relativo a las variables
start_gazebo_ros_image_bridge_cmd y
start_gazebo_ros_depth_bridge_cmd, y lo más importante, modificar
el nombre del fichero que se le pasa como argumento a bridge_params (en este caso,
prius_autoparking_3laser_harmonic.yaml):
# Copyright 2019 Open Source Robotics Foundation, Inc. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License.
import os
from ament_index_python.packages import get_package_share_directory from launch import LaunchDescription from launch.actions import DeclareLaunchArgument from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description(): # Get the urdf file model_folder = "prius_autoparking_3laser_harmonic" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para estos ficheros, lo único que habría que hacer es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y modificar únicamente las líneas correspondientes a las
variables robot_launch_dir y world_file_name,
correspondientes a las rutas en las que se encuentran el directorio que almacena el
fichero spawn_robot.launch.py y el fichero del mundo que utiliza
este ejercicio.
import os
from ament_index_python.packages import get_package_share_directory
from launch import LaunchDescription from launch.actions import ( DeclareLaunchArgument, IncludeLaunchDescription, SetEnvironmentVariable, AppendEnvironmentVariable, ) from launch.launch_description_sources import PythonLaunchDescriptionSource from launch.substitutions import LaunchConfiguration, Command from launch_ros.actions import Node from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node
def generate_launch_description():
x = LaunchConfiguration("x") y = LaunchConfiguration("y") z = LaunchConfiguration("z") roll = LaunchConfiguration("R") pitch = LaunchConfiguration("P") yaw = LaunchConfiguration("Y")
IMPORTANTE: En caso de que no se hayan creado dentro de los
directorios autopark_line/, autopark_battery/ y
autopark_sideways/ el fichero
robot_state_publisher.launch.py, es obligatorio comentar
y/o eliminar del código todo lo relacionado con la variable
robot_state_publisher_cmd.
En estos ficheros, lo único que habría que realizar es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y sustituir todas aquellos flags <include> de la versión antigua por
aquellos que aparezcan en la versión nueva.
Este es uno de los cambios más sencillos de realizar en todo el proceso de migración.
Lo único que habría que hacer es identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Autoparking) y cambiar el valor de la
columna type de gazebo a gz:
Una vez realizados todos estos cambios en todos los ficheros mencionados,
he hecho commit y push en una nueva rama que he creado y publicado llamada
autopark_harmonic. Es importante hacer esto siempre para
así evitar cualquier tipo de conflicto con la rama principal.
Como todos los cambios se han realizado en ficheros que se encuentran dentro de
RoboticsInfrastructure, es obligatorio generar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i autopark_harmonic
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
Una vez finalizada la ejecución del script build.sh, se debe
regresar al repositorio principal:
cd ../..
Pero antes de ejecutar el script develop_academy.sh, hay que
modificar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml:
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
Con este cambio ya realizado, ya se puede lanzar el script
develop_academy.sh:
./scripts/develop_academy.sh
Y por último, sólo quedaría acceder a la dirección web `http://0.0.0.0:7164/` que
aparece en la terminal al ejecutar el comando anterior para poder entrar a Unibotics
en local y verificar que los cambios se han realizado correctamente.
A continuación se muestra cómo se ve el ejercicio Autoparking
al lanzar el Docker de RoboticsAcademy con todos estos cambios realizados:
IMAGEN UNIBOTICS GAZEBO AUTOPARK_LINE
IMAGEN UNIBOTICS GAZEBO AUTOPARK_BATTERY
IMAGEN UNIBOTICS GAZEBO AUTOPARK_SIDEWAYS
Además, para verificar que tanto el escenario como el coche han sido migrados
correctamente, se muestra una pequeña animación del coche moviéndose en línea
recta para verificar que todo el proceso se ha realizado correctamente:
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO AUTOPARK_LINE
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO AUTOPARK_BATTERY
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO AUTOPARK_SIDEWAYS
SEMANA 06: 27-10-2025 al 31-10-2025
Migración del ejercicio Follow Line a Gazebo Harmonic
Con el ejercicio de Autoparking ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
cuarto ejercicio, en este caso, Follow Line, que consiste en la
implementación de un controlador PID reactivo que sea capaz de seguir la línea roja
pintada en el suelo del circuito de carreras.
A continuación, se encuentran todos los ficheros que se han modificado y/o creado
(y de qué forma) para poder llevar a cabo la migración completa de este ejercicio
de Gazebo 11 a Gazebo Harmonic:
En este caso, no ha sido necesario llevar a cabo ninguna modificación en este
fichero, ya que el coche utilizado para esta versión ya se encuentra migrado a
Gazebo Harmonic:
Este fichero se crea de cero en la ruta especificada, aunque se puede coger
cualquier fichero del tipo robot_params.yaml como referencia.
En este caso, se añaden los topics correspondientes al plugin subscriptor del
DiffDrive, y los plugin publicadores del DiffDrive, del sensor láser LIDAR y de
la cámara.
En este caso, la única modificación realizada en este fichero es la
adición de las líneas [...],
para que el fichero que se acaba de crear (<robot_model_name>.yaml),
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio <exercise_name>/, y a su vez dentro
de él el fichero spawn_robot.launch.py, lo único que habría que
hacer es coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y sólamente habría que comentar todo
lo relativo a las variables start_gazebo_ros_image_bridge_cmd y
start_gazebo_ros_depth_bridge_cmd, y lo más importante, modificar
el nombre del fichero que se le pasa como argumento a bridge_params (en este caso,
<robot_model_name>.yaml):
Para este fichero, lo único que habría que hacer es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y modificar únicamente las líneas correspondientes a las
variables robot_launch_dir y world_file_name,
correspondientes a las rutas en las que se encuentran el directorio que almacena el
fichero spawn_robot.launch.py y el fichero del mundo que utiliza
este ejercicio.
CODE
IMPORTANTE: En caso de que no se haya creado dentro del directorio
<exercise_name>/ el fichero
robot_state_publisher.launch.py, es obligatorio comentar
y/o eliminar del código todo lo relacionado con la variable
robot_state_publisher_cmd.
En este fichero, lo único que habría que realizar es un Ctrl+C Ctrl+V de
cualquier fichero con el mismo formato de nombre que ya haya sido migrado a Gazebo
Harmonic y sustituir todas aquellos flags <include> de la versión antigua por
aquellos que aparezcan en la versión nueva.
Este es uno de los cambios más sencillos de realizar en todo el proceso de migración.
Lo único que habría que hacer es identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Follow Line) y cambiar el valor de la
columna type de gazebo a gz:
CODE
Una vez realizados todos estos cambios en todos los ficheros mencionados,
he hecho commit y push en una nueva rama que he creado y publicado llamada
harmonic-follow-line-tests. Es importante hacer esto siempre para
así evitar cualquier tipo de conflicto con la rama principal.
Como todos los cambios se han realizado en ficheros que se encuentran dentro de
RoboticsInfrastructure, es obligatorio generar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i harmonic-follow-line-tests
IMPORTANTE: Cada vez que se genera un nuevo RADI no se borra el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
cada vez que se genere un nuevo RADI hasta que no quede espacio disponible en disco.
Para evitar que esto ocurra, se debe ejecutar el siguiente comando en la terminal,
el cual se encargará de borrar todo el espacio de memoria que se ha ido llenando por
cada RADI generado:
docker system prune -af
Una vez finalizada la ejecución del script build.sh, se debe
regresar al repositorio principal:
cd ../..
Pero antes de ejecutar el script develop_academy.sh, hay que
modificar la siguiente línea del fichero
RoboticsAcademy/compose_cfg/dev_humble_cpu.yaml:
# ANTES robotics-academy: image: jderobot/robotics-academy:latest
# DESPUÉS robotics-academy: image: jderobot/robotics-academy:test
Con este cambio ya realizado, ya se puede lanzar el script
develop_academy.sh:
./scripts/develop_academy.sh
Y por último, sólo quedaría acceder a la dirección web `http://0.0.0.0:7164/` que
aparece en la terminal al ejecutar el comando anterior para poder entrar a Unibotics
en local y verificar que los cambios se han realizado correctamente.
A continuación se muestra cómo se ve el ejercicio Follow Line
al lanzar el Docker de RoboticsAcademy con todos estos cambios realizados:
IMAGEN UNIBOTICS GAZEBO FOLLOW LINE
Además, para verificar que tanto el escenario como el coche han sido migrados
correctamente, se muestra una pequeña animación del coche moviéndose en línea
recta para verificar que todo el proceso se ha realizado correctamente: