1. Instalación del paquete

2. Anotaciones

3. Nodos

   • HMI
   • Kinematic Model
   • Gait Control
   • Control MSD
   • Control ZMP
   • Frame
   • Gaming
   • States Machine
   • Simulink Node

4. Tipos de Mensaje Utilizados

5. Equipo

0. Requisitos sistema:

• Ubuntu 22.04
• Instalación desktop de ROS2 Humble

1. Crear una carpeta workspace (p.e. nimble_ws o ros_ws) y subcarpeta nimble_ws/src. En ella copiaremos los archivos descargandolos directamente o ejecutando:

git clone https://github.com/jcarballeira/nimble.git

3. Compilar: Situarse en "cd nimble_ws" y ejecutar "colcon build". Rezar a vuestra divinidad favorita.

4. Cargar la instalación con "source install/setup.bash"

• Este paso hay que realizarlo desde nimble_ws al abrir un nuevo terminal. Para evitarlo, abrir un terminal nuevo, ejecutar "gedit .bashrc" Se abrirá un archivo en el que debemos copiar al final la siguiente instrucción:

  source ~/nimble_ws/install/setup.bash

  De esta forma se ejecuta automáticamente al abrir un nuevo terminal. De todas formas, al compilar algo nuevo habrá que reiniciar el terminal para que se actualice ese archivo.

5. Ejecución del nodo deseado "ros2 run nimble your_node"

6. En el caso del mainPC existe un fichero launch para ejecutar todos los nodos en una única instrucción. Ejecutar "ros2 launch nimble nimble_launch.py".

• Existen 2 paquetes diferentes e imprescindibles:

  • nimble_interfaces: Contiene el servicio para la generacion de trayectorias ideales (NN) y los mensajes creados para almacenar información de forma concreta (para el resto se usan msgs predefinidos en ROS2). Al final del documento hay una lista de los tipos de mensaje creados y los distintos campos que contienen

  • nimble: Incluye todos los nodos a ejecutar tanto en el mainPC como el los diferentes micros o raspberrys.

Cada nodo está suscrito a todos los topics indicados y preparado para publicar lo necesario (o eso creo).

Tiene las funciones asociadas a la recepción de cada mensaje (callbacks). En esos callbacks se almacena cada mensaje en una estructura de datos para procesarlos según el objetivo de cada nodo. La estructura está pensada para almacenar los mensajes según lleguen y poder hacer el procesamiento necesario según el nodo. De esta manera se puede comprobar si ya llegó toda la información, subdividirlo en varias funciones de procesamiento si solo se necesitan 2 mensajes, directamente en el callback si solo hace falta un mensaje...según cada nodo.

Además cada nodo tiene un timer (de perido ajustable, default:1000ms) que ejecuta un callback por si se quiere publicar o ejecutar algo periódicamente. Típicamente los sensores se publican cada cierto tiempo, habrá casos en los que solo se quiera publicar si ocurre algo concreto, por ejemplo para enviar un set point. En caso de no usarlo eliminadlo para evitar que entre innecesariamente.

Ahora que cada cual haga sus chapuzas correspondientes en cada nodo. Salud y república. Deslicen hacia abajo para más info interesante, suscribanse y denle a like.

• std_msgs/Header header

• float64 height
• float64 femur
• float64 tibia
• float64 height_ankle
• float64 distance_to_heel
• float64 distance_to_toe
• float64 depth_pelvis
• float64 width_pelvis

• std_msgs/Header header

• float64 speed
• float64 step_length
• float64 step_height
• int32 min_assist
• int32 max_assist

• std_msgs/Header header

• float64 optic_sensor
• float64 velocity
• float64 position

• std_msgs/Header header
• std_msgs/Float32MultiArray phase (fase de marcha)
• trajectory_msgs/msg/JointTrajectory trajectory
• bool new_indicator (indicador de que la trayectoria completa es nueva)

• std_msgs/Header header

• geometry_msgs/Point[] left_pelvis
  • float64 x
  • float64 y
  • float64 z
• geometry_msgs/Point[] right_pelvis
• geometry_msgs/Point[] base_pelvis
• geometry_msgs/Point[] left_hip
• geometry_msgs/Point[] right_hip
• geometry_msgs/Point[] left_knee
• geometry_msgs/Point[] right_knee
• geometry_msgs/Point[] left_ankle
• geometry_msgs/Point[] right_ankle
• geometry_msgs/Point[] left_heel
• geometry_msgs/Point[] right_heel
• geometry_msgs/Point[] left_toe
• geometry_msgs/Point[] right_toe

• std_msgs/Header header
• std_msgs/Float32MultiArray phase (fase de marcha)
• geometry_msgs/Point point

• Request 1: measurements (nimble_interfaces/msg/Measurements)

• Request 2: therapy_requirements (nimble_interfaces/msg/TherapyRequirements)
• Response: joints_trajectory (trajectory_msgs/msg/JointTrajectory)

• Request 1: measurements (nimble_interfaces/msg/Measurements)

• Request 2: joints_trajectory (trajectory_msgs/msg/JointTrajectory)
• Response 1: cartesian_trajectory (nimble_interfaces/msg/CartesianTrajectory)
• Response 2: step_target (nimble_interfaces/msg/TherapyRequirements)

• std_msgs/Header header

• string[] name (seguiremos este orden para articulaciones ["hipR", "kneeR", "ankleR","hipL", "kneeL", "ankleL"]) ó ["x","y","z"] si es cartesiana
• float64[] position (vector de vectores con posicion angular)
• float64[] velocity (análogo al anterior con velocidades)
• float64[] effort (análogo al anterior con velocidades)

• float64 x
• float64 y
• float64 z

• std_msgs/Header header

• string[] joint_names (seguiremos este orden ["hipR", "kneeR", "ankleR","hipL", "kneeL", "ankleL","pelvisList", "pelvisTilt", "hipR_Abd", "hipL_Abd"])
• JointTrajectoryPoint[] points
  • float64[] positions
  • float64[] velocities
  • float64[] accelerations
  • float64[] effort
  • duration time_from_start

• MultiArrayLayout layout

• int32[] data

• MultiArrayLayout layout

• float32[] data

• int16 data

• Juan Carballeira
• Jaime Ramos
• Adrián Madinabeitia