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 en la Universidad Rey Juan Carlos.
A continuación, se muestran todas las entradas correspondientes a los blogs realizados,
cuyo contenido se divide en las 20 semanas que han durado mis Prácticas.
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/username, 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 configurará el entorno de desarrollo. Sin embargo, al intentar ejecutar
este script por primera vez, aparecerán varios errores debido a algunas dependencias
que están pendientes de instalar, concretamente 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 mostrados a continuación se encargarán 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
SEMANA 02: 29-09-2025 al 03-10-2025
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>
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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 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.
SEMANA 03: 06-10-2025 al 10-10-2025
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 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.
NOTA: 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.
SEMANA 04: 13-10-2025 al 17-10-2025
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:
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)
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 05: 20-10-2025 al 24-10-2025
Ejercicio de calentamiento: Cambiar universo
Para ir familiarizándome con el software de RoboticsInfrastructure, se me ha
pedido como primer ejercicio cambiar el universo 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 universos ya migrados a Gazebo Harmonic.
NOTA: La forma más sencilla de identificar los universos 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 universo todavía se encuentra en Gazebo 11
y no se ha migrado. Pero si aparece escrito gz, significa que ese
universo ya se ha migrado a Gazebo Harmonic.
A continuación se listan todos los universos que tienen escrito gz
en su columna type, y que podrían utilizarse para llevar a cabo
este ejercicio de calentamiento:
En mi caso, he seleccionado los universos correspondientes a los ejercicios de
Laser Mapping (número 12) y Marker Based Visual Loc
(número 25). El universo del Laser Mapping es un almacén tipo Amazon,
mientras que el universo 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 el visor 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 (UNIVERSO ORIGINAL) world_file_name = "marker_visual_loc.world"
# DESPUÉS (UNIVERSO 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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i test-aleon2020
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
docker system prune -af
NOTA: 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, habría 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 06: 27-10-2025 al 31-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 velocity-control-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, se añaden los topics correspondientes al publicador y al
subscriptor del plugin del DiffDrive (F1ROS/odom y
/F1ROS/cmd_vel) y aquellos relativos al publicador del plugin del
láser (f1/laser/scan):
# 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
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 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 la variable
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, habría que hacer un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
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 universo 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")
NOTA: 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir todos
aquellos flags <include> de la versión antigua por aquellos que aparezcan en
la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que 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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i obstacle-avoidance-harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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 circuito 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 07: 03-11-2025 al 07-11-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 (/taxi_holo/odom y
/taxi_holo/cmd_vel):
# 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
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, habría que coger cualquier
fichero con el mismo nombre de otro ejercicio que ya esté migrado a Gazebo Harmonic,
copiar su contenido y 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 la variable
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, habría que hacer un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar 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 universo 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")
NOTA: 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir todos
aquellos flags <include> de la versión antigua por aquellos que aparezcan en
la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que 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 {"gzsim":"/opt/jderobot/Launchers/visualization/global_nav.config"} 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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i global-navigation-migration
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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 la ciudad como el taxi han sido migrados
correctamente, se muestra una pequeña animación del taxi moviéndose en línea
recta para verificar que todo el proceso se ha realizado correctamente:
SEMANA 08: 10-11-2025 al 14-11-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.
NOTA: 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.
Estos ficheros se crean 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 publicador y
subscriptor del DiffDrive (/prius_autoparking/odom y
/prius_autoparking/cmd_vel), y los plugin publicadores de los 3
sensores láser LIDAR (/prius_autoparking/scan_front,
/prius_autoparking/scan_side y
/prius_autoparking/scan_back).
# 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/worlds para 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,
habría que coger cualquier fichero con el mismo nombre de otro ejercicio que ya
esté migrado a Gazebo Harmonic, copiar su contenido y 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, habría que hacer un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
las líneas correspondientes a las variables robot_launch_dir y
world_file_name, correspondientes a las rutas en las que se
encuentra el directorio que almacena el fichero
spawn_robot.launch.py y el fichero del universo 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")
NOTA: 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
NOTA: 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.
En este fichero, habría que realizar 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.
En este fichero, habría que 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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i autopark_harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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 los diferentes parkings 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 09: 17-11-2025 al 21-11-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 ninguno de
estos ficheros, ya que los dos coches utilizados para esta versión (tanto el coche
holonómico como el coche Ackermann) ya se encuentran migrados a Gazebo Harmonic.
NOTA: Dada la gran extensión en cuanto a líneas se refiere
de estos ficheros, adjunto a continuación un enlace a cada uno de estos ficheros en
el que se puede visualizar todo su contenido.
Estos ficheros se crean de cero en la ruta especificada, aunque se puede coger
cualquier fichero del tipo robot_params.yaml como referencia.
En el caso de ambos ficheros
(fichero f1_renault.yaml y
f1_renault_camera.yaml), se añaden los topics
correspondientes a los plugins publicadores y subscriptores del DiffDrive
(F1ROS/odom y /F1ROS/cmd_vel) y de la cámara
(/cam_f1_left/camera_info).
# 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 (Camera) - ros_topic_name: "/cam_f1_left/camera_info" gz_topic_name: "/cam_f1_left/camera_info" ros_type_name: "sensor_msgs/msg/CameraInfo" gz_type_name: "gz.msgs.CameraInfo" direction: GZ_TO_ROS
En este caso, la única modificación realizada en este fichero es la
adición de las línea f1/params y
ackermann_cars/params para que los ficheros que se acaban
de crear (f1_result_laser_no_cam.yaml y
f1_renault_camera.yaml) se tengan en cuenta a la
hora de lanzar el Docker:
# GAZEBO 11
install( DIRECTORY ... # F1 f1/models f1/launch f1/worlds ... # ACKERMAN CAR ackermann_cars/models ackermann_cars/launch ackermann_cars/worlds ... DESTINATION share/${PROJECT_NAME})
# GAZEBO HARMONIC
install( DIRECTORY ... # F1 f1/models f1/launch f1/worlds f1/params ... # ACKERMAN CAR ackermann_cars/models ackermann_cars/launch ackermann_cars/worlds ackermann_cars/params ... DESTINATION share/${PROJECT_NAME})
Una vez creados los directorios monaco_circuit/,
montmelo_circuit/, montreal_circuit/,
nurburgring_circuit/, simple_circuit/,
monaco_circuit_ackermann/,
montmelo_circuit_ackermann/,
montreal_circuit_ackermann/,
nurburgring_circuit_ackermann/ y
simple_circuit_ackermann/, y a su vez dentro de cada uno de ellos
el fichero spawn_robot.launch.py, habría que coger cualquier
fichero con el mismo nombre de otro ejercicio que ya esté migrado a Gazebo Harmonic,
copiar su contenido y comentar todo lo relativo a la variable
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.yaml y
f1_renault_camera.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
Para estos ficheros, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con
el mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
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 universo 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")
NOTA: En caso de que no se haya creado dentro de los directorios
monaco_circuit/, montmelo_circuit/,
montreal_circuit/, nurburgring_circuit/,
simple_circuit/, monaco_circuit_ackermann/montmelo_circuit_ackermann/,
montreal_circuit_ackermann/,
nurburgring_circuit_ackermann/ o
simple_circuit_ackermann/, 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que 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:
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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i harmonic-follow-line-tests
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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:
Además, para verificar que tanto los circuitos como los coches 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 MONACO_CIRCUIT
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO MONTMELO_CIRCUIT
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO MONTREAL_CIRCUIT
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO NURBURGRING_CIRCUIT
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO SIMPLE_CIRCUIT
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO MONACO_CIRCUIT_ACKERMANN
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO MONTMELO_CIRCUIT_ACKERMANN
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO MONTREAL_CIRCUIT_ACKERMANN
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO NURBURGRING_CIRCUIT_ACKERMANN
VÍDEO DEL COCHE MOVIÉNDOSE POR EL ESCENARIO SIMPLE_CIRCUIT_ACKERMANN
SEMANA 10: 24-11-2025 al 28-11-2025
Migración del ejercicio Basic Vacuum Cleaner a Gazebo Harmonic
Con el ejercicio de Follow Line ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
quinto ejercicio, en este caso, Basic Vacuum Cleaner, que consiste
en la implementación de la lógica de un algoritmo de navegación para una aspiradora
autónoma, cuyo objetivo principal será cubrir la mayor superficie posible de una
casa utilizando el algoritmo programado.
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 velocity-control-system,
al odometry-publisher-system y al contact-system:
NOTA: 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 a los plugins
publicadores y subscriptores del diff-drive (/roombaROS/odom y
/roombaROS/cmd_vel), del sensor láser LIDAR
(/roombaROS/laser/scan) y de los 3 sensores bumper de contacto
(/roombaROS/events/center_bumper,
/roombaROS/events/right_bumper y
/roombaROS/events/left_bumper):
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/roombaROS/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: "/roombaROS/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: "/roombaROS/laser/scan" gz_topic_name: "/roombaROS/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 roomba_robot/params para que el
fichero que se acaba de crear (roombaROS.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio basic_vacuum_cleaner/, y a su vez
dentro de él el fichero spawn_robot.launch.py, habría que
coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y 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,
roombaROS.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 = "roombaROS" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar 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 universo 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")
NOTA: En caso de que no se haya creado dentro del directorio
basic_vacuum_cleaner/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Basic Vacuum Cleaner) 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
basic-vacuum-cleaner-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i basic-vacuum-cleaner-harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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
Basic Vacuum Cleaner al lanzar el Docker de RoboticsAcademy con
todos estos cambios realizados:
Además, para verificar que tanto la casa como la aspiradora han sido migrados
correctamente, se muestra una pequeña animación de la aspiradora moviéndose
para verificar que todo el proceso se ha realizado correctamente:
SEMANA 11: 01-12-2025 al 05-12-2025
Migración del ejercicio Localized Vacuum Cleaner a Gazebo Harmonic
Con el ejercicio de Basic Vacuum Cleaner ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
sexto ejercicio, en este caso, Localized Vacuum Cleaner, que
consiste en implementar la lógica de un algoritmo de navegación para una aspiradora
autónoma utilizando la ubicación del robot, donde el robot está equipado con un
mapa y conoce su ubicación actual en él, cuyo objetivo principal será cubrir la
mayor superficie posible de una casa utilizando el algoritmo programado.
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 velocity-control-system,
al odometry-publisher-system y al contact-system:
NOTA: 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 a los plugins
publicadores y subscriptores del DiffDrive (/roombaROS/odom y
/roombaROS/cmd_vel), del sensor láser LIDAR
(/roombaROS/laser/scan) y de los 3 sensores bumper de contacto
(/roombaROS/events/center_bumper,
/roombaROS/events/right_bumper y
/roombaROS/events/left_bumper):
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/roombaROS/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: "/roombaROS/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: "/roombaROS/laser/scan" gz_topic_name: "/roombaROS/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 roomba_robot/params para que el
fichero que se acaba de crear (roombaROS.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio localized_vacuum_cleaner/, y a su vez
dentro de él el fichero spawn_robot.launch.py, habría que coger
cualquier fichero con el mismo nombre de otro ejercicio que ya esté migrado a
Gazebo Harmonic, copiar su contenido y 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,
roombaROS.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 = "roombaROS" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
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 universo 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")
NOTA: En caso de que no se haya creado dentro del directorio
localized_vacuum_cleaner/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por
aquellos que aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Localized Vacuum Cleaner) 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
localized-vacuum-cleaner-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i localized-vacuum-cleaner-harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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
Localized Vacuum Cleaner al lanzar el Docker de RoboticsAcademy
con todos estos cambios realizados:
Además, para verificar que tanto la casa como la aspiradora han sido migrados
correctamente, se muestra una pequeña animación de la aspiradora moviéndose
para verificar que todo el proceso se ha realizado correctamente:
SEMANA 12: 08-12-2025 al 12-12-2025
Migración del ejercicio Montecarlo Laser Localization a Gazebo Harmonic
Con el ejercicio de Localized Vacuum Cleaner ya migrado por completo a Gazebo
Harmonic, se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo
Harmonic de un séptimo ejercicio, en este caso,
Montecarlo Laser Localization, que consiste en desarrollar un
algoritmo de localización basado en el filtro de partículas utilizando el láser del
robot.
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 velocity-control-system,
al odometry-publisher-system y al contact-system:
NOTA: 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 a los plugins
publicadores y subscriptores del DiffDrive (/roombaROS/odom y
/roombaROS/cmd_vel), del sensor láser LIDAR
(/roombaROS/laser/scan) y de los 3 sensores bumper de contacto
(/roombaROS/events/center_bumper,
/roombaROS/events/right_bumper y
/roombaROS/events/left_bumper):
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/roombaROS/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: "/roombaROS/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: "/roombaROS/laser/scan" gz_topic_name: "/roombaROS/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 roomba_robot/params para que el
fichero que se acaba de crear (roombaROS.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio montecarlo_laser_localization/, y a
su vez dentro de él el fichero spawn_robot.launch.py, habría que
coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y 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,
roombaROS.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 = "roombaROS" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, habría que realizar 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 universo 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")
NOTA: En caso de que no se haya creado dentro del directorio
montecarlo_laser_localization/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En ets fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Montecarlo Laser Localization) 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
montecarlo-laser-localization-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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
Montecarlo Laser Localization al lanzar el Docker de
RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto la casa como la aspiradora han sido migrados
correctamente, se muestra una pequeña animación de la aspiradora moviéndose
para verificar que todo el proceso se ha realizado correctamente:
SEMANA 13: 15-12-2025 al 19-12-2025
Migración del ejercicio Montecarlo Visual Localization a Gazebo Harmonic
Con el ejercicio de Montecarlo Laser Localization ya migrado por completo a Gazebo
Harmonic, se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo
Harmonic de un octavo ejercicio, en este caso,
Montecarlo Visual Localization, que consiste en desarrollar un
algoritmo de localización visual basado en el filtro de partículas.
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 velocity-control-system,
al odometry-publisher-system y al contact-system:
NOTA: 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 a los plugins
publicadores y subscriptores del DiffDrive (/roombaROS/odom y
/roombaROS/cmd_vel), del sensor láser LIDAR
(/roombaROS/laser/scan) de los 3 sensores bumper de contacto
(/roombaROS/events/center_bumper,
/roombaROS/events/right_bumper y
/roombaROS/events/left_bumper) y de la cámara
(/camera/camera_info):
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/roombaROS/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: "/roombaROS/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: "/roombaROS/laser/scan" gz_topic_name: "/roombaROS/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 roomba_robot/params para que el
fichero que se acaba de crear (roombaROS_cam.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
Una vez creado el directorio montecarlo_visual_localization/, y a
su vez dentro de él el fichero spawn_robot.launch.py, habría que
coger cualquier fichero con el mismo nombre de otro ejercicio que ya esté
migrado a Gazebo Harmonic, copiar su contenido y comentar todo lo relativo a la
variable 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, roombaROS_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 = "roombaROS_cam" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con
el mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
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 universo 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")
NOTA: En caso de que no se haya creado dentro del directorio
montecarlo_visual_localization/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Montecarlo Visual Localization) 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
montecarlo-visual-localization-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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
Montecarlo Visual Localization al lanzar el Docker de
RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto la casa como la aspiradora han sido migrados
correctamente, se muestra una pequeña animación de la aspiradora moviéndose
para verificar que todo el proceso se ha realizado correctamente:
SEMANA 14: 22-12-2025 al 26-12-2025
SEMANA 15: 29-12-2025 al 02-01-2026
SEMANA 16: 05-01-2026 al 09-01-2026
SEMANA 17: 12-01-2026 al 16-01-2026
Migración del ejercicio 3D Reconstruction a Gazebo Harmonic
Con el ejercicio de Montecarlo Visual Localization ya migrado por completo a Gazebo
Harmonic, se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo
Harmonic de un noveno ejercicio, en este caso, 3D Reconstruction,
que consiste en programar la lógica necesaria para permitir que el robot Kobuki
genere una reconstrucción 3D de la escena que recibe a través de sus cámaras,
tanto de la izquierda como de la derecha.
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.
NOTA: 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 publicador y al
subscriptor del sensor láser LIDAR (/turtlebotROS/laser/scan) y
de las cámaras (/cam_turtlebot_left/camera_info y
/cam_turtlebot_right/camera_info):
# gz topic published by Sensors plugin (LIDAR) - ros_topic_name: "/turtlebotROS/laser/scan" gz_topic_name: "/turtlebotROS/laser/scan" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
# gz topic published by Sensors plugin (Camera) - ros_topic_name: "/cam_turtlebot_left/camera_info" gz_topic_name: "/cam_turtlebot_left/camera_info" ros_type_name: "sensor_msgs/msg/CameraInfo" gz_type_name: "gz.msgs.CameraInfo" direction: GZ_TO_ROS
En este caso, la única modificación realizada en este fichero es la
adición de la línea 3d_reconstruction/params para que el
fichero que se acaba de crear (turtlebotROS.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
# GAZEBO 11
install( DIRECTORY ... # 3D RECONSTRUCTION 3d_reconstruction/models ... DESTINATION share/${PROJECT_NAME})
Una vez creado el directorio 3d_reconstruction/, y a su vez dentro
de él el fichero spawn_robot.launch.py, habría que coger cualquier
fichero con el mismo nombre de otro ejercicio que ya esté migrado a Gazebo Harmonic,
copiar su contenido y comentar todo lo relativo a la variable
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,
turtlebotROS.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 = "turtlebotROS" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para este fichero, habría que realizar 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 universo 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")
NOTA: En caso de que no se haya creado dentro del directorio
3d_reconstruction/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
En este fichero, habría que realizar 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.
En este fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, 3D Reconstruction) 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
3d-reconstruction-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i 3d-reconstruction-harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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 3D Reconstruction
al lanzar el Docker de RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto los objetos como el Kobuki han sido migrados
correctamente, se muestra una pequeña animación de la solución de este ejercicio
para verificar que todo el proceso se ha realizado correctamente:
SEMANA 18: 19-01-2026 al 23-01-2026
Migración del ejercicio Follow Person a Gazebo Harmonic
Con el ejercicio de 3D Reconstruction ya migrado por completo a Gazebo Harmonic,
se me ha pedido realizar la migración completa de Gazebo 11 a Gazebo Harmonic de un
décimo ejercicio, en este caso, Follow Person, que consiste en
implementar la lógica de un algoritmo de navegación que se utilizará para seguir a
una persona en un hospital utilizando una R-CNN (Red Neuronal Convolucional basada
en Regiones) llamada SSD (Detector de Disparo Único).
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 velocity-control-system
y al odometry-publisher-system:
NOTA: 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 a los plugins
publicadores y subscriptores del DiffDrive (/odom y
/cmd_vel), del sensor láser LIDAR
(/scan) y de la cámara
(/depth_camera/camera_info):
# gz topic published by DiffDrive plugin - ros_topic_name: "odom" gz_topic_name: "/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: "/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: "/scan" gz_topic_name: "/scan" ros_type_name: "sensor_msgs/msg/LaserScan" gz_type_name: "gz.msgs.LaserScan" direction: GZ_TO_ROS
# gz topic published by Sensors plugin (Camera) - ros_topic_name: "/depth_camera/camera_info" gz_topic_name: "/depth_camera/camera_info" ros_type_name: "sensor_msgs/msg/CameraInfo" gz_type_name: "gz.msgs.CameraInfo" direction: GZ_TO_ROS
En este caso, la única modificación realizada en este fichero es la
adición de la línea 3d_reconstruction/params para que el
fichero que se acaba de crear (turtlebotROS.yaml)
se tenga en cuenta a la hora de lanzar el Docker:
# GAZEBO 11
install( DIRECTORY ... # 3D RECONSTRUCTION 3d_reconstruction/models ... DESTINATION share/${PROJECT_NAME})
Una vez creados los directorios follow_person/ y
follow_person_teleop/, y a su vez dentro de ellos el fichero
spawn_robot.launch.py, habría que coger cualquier fichero con el
mismo nombre de otro ejercicio que ya esté migrado a Gazebo Harmonic y copiar su
contenido, y lo más importante, modificar el nombre del fichero que se le pasa como
argumento a bridge_params (en este caso, turtlebotROS.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 = "turtlebotROS" urdf_path = os.path.join( get_package_share_directory("custom_robots"), "models", model_folder, "model.sdf", )
Para estos ficheros, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con
el mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y modificar
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 universo 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")
NOTA: En caso de que no se haya creado dentro de los directorios
follow_person/ y follow_person_teleop/ 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, habría que realizar un Ctrl+C Ctrl+V de cualquier fichero con el
mismo formato de nombre que ya haya sido migrado a Gazebo Harmonic y sustituir
todos aquellos flags <include> de la versión antigua por aquellos que
aparezcan en la versión nueva.
NOTA: Dada la gran extensión en cuanto a líneas se refiere
de estos ficheros, adjunto a continuación un enlace a dichos ficheros en el que se
puede visualizar todo su contenido.
En este fichero, habría que realizar 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.
En este fichero, habría que identificar el ejercicio que se quiere migrar de
Gazebo 11 a Gazebo Harmonic (en este caso, Follow Person) y cambiar
el valor de la columna type de gazebo a
gz:
# GAZEBO 11 10 Follow Person /opt/jderobot/Launchers/follow_person.launch.py None ROS2 gazebo {0.0,0.0,0.0,0.0,0.0,0.0} 11 Follow Person Teleop /opt/jderobot/Launchers/follow_person_teleop.launch.py None ROS2 gazebo {0.0,0.0,0.0,0.0,0.0,0.0}
# GAZEBO HARMONIC 10 Follow Person /opt/jderobot/Launchers/follow_person.launch.py {"gzsim":"/opt/jderobot/Launchers/visualization/follow_person.config"} ROS2 gz {0.0,0.0,0.0,0.0,0.0,0.0} 11 Follow Person Teleop /opt/jderobot/Launchers/follow_person_teleop.launch.py {"gzsim":"/opt/jderobot/Launchers/visualization/follow_person.config"} 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
follow-person-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 compilar un nuevo RADI. Para ello, se deben
ejecutar los siguientes comandos en la terminal:
cd scripts/RADI/
./build.sh -i follow-person-harmonic
NOTA: Cada vez que se compile un nuevo RADI no se borrará el
anterior, por lo que el espacio disponible en disco se irá llenando y llenando
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 compilado:
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, habría 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 Person al lanzar el Docker de
RoboticsAcademy con todos estos cambios realizados:
Además, para verificar que tanto el escenario como el robot han sido migrados
correctamente, se muestra una pequeña animación del robot moviéndose
para verificar que todo el proceso se ha realizado correctamente: