Con el comienzo del nuevo curso académico 2020/21, en un contexto de pandemia global, con docencia mixta (presencial y no presencial) y teniendo en cuenta las nuevas peticiones de software de los laboratorios (con nuevas aplicaciones y/o nuevas versiones de programas respecto de los del curso pasado), procede actualizar el fichero VDI asociado a la máquina virtual del curso anterior:
Al nuevo virtual le llamaremos Virtual Ubuntu EPS 2020.
Esta máquina virtual, dada la situación actual, es un poco “especial” respecto a las de cursos anteriores, pues crece significativamente en el tamaño del fichero VDI a descargar (unos 37GB mayor, prácticamente el doble, que la versión del curso pasado).
Para la obtención del mismo, deberemos descargarlo de Google Drive, para lo que tendremos que haber iniciado sesión en Gmail/Google Drive. En caso de no disponer de cuenta, puedes crearte una de la UA con espacio ilimitado siguiendo las instrucciones indicadas en https://si.ua.es/es/manuales/uacloud/uacloudse/servicios-externos.html.
El enlace para la descarga del VDI es el siguiente (arriba a la derecha aparece un enlace para iniciar sesión en Gmail/Google Drive):
https://drive.google.com/uc?id=1s7fvCf7r9LBS_Y-G1piGRdKFYmv8V1XW&export=download
Desde ella, pincharemos en el enlace que aparece para proceder a la descarga del fichero Ubuntu-VDI-EPS-16_04-2020.vdi
El archivo ocupa alrededor de 79 GB. Es decir, donde descarguemos el mismo, hemos de estar seguros de disponer de algo más de ese tamaño (preferiblemente unos 85 GB como mínimo). La duración de la descarga dependerá de la conexión a Internet que tengamos. Con una conexión relativamente modesta, en algo menos de 6 horas debería estar descargado.
Sigue estando basado en Ubuntu 16.04 LTS x86_64 (64 bits) pero con las actualizaciones pertinentes, añadiendo los nuevos programas y versiones del nuevo curso así como eliminando algunos programas cuyas versiones ya eran antiguas (años 2017-2018) y que habían quedado obsoletas.
Al arrancar, lo hace en modo ventana pero, si queremos trabajar con más comodidad, podemos optar por cambiar a pantalla completa (desde el menú Ver, en la parte superior de la máquina virtual).
Una vez casi ha terminado de arrancar, primeramente nos aparecerá un login en modo texto temporal en vt1 (que dura entre unos segundos y un minuto, dependiendo de la velocidad del anfitrión y la configuración HW de la máquina virtual). No hay que hacer nada, sólo esperar a que salga el modo gráfico.
Una vez arrancado el modo gráfico, dependiendo del modo en que arranquemos inicialmente el virtual, puede ser que, una vez acabado el proceso de arranque, los iconos que aparezcan en el Escritorio, no salgan correctamente ordenados (sino superpuestos o desordenados). Esto se soluciona fácilmente con el ratón pinchando con el botón derecho sobre el tapiz del Escritorio y seleccionando la opción “Organizar el escritorio por nombre“.
La nueva imagen del Escritorio, en modo ventana y con los iconos correctamente ordenados, queda así:
El tiempo total de arranque, desde que le damos a Iniciar en la plataforma de virtualización hasta que sale el Escritorio definitivamente, ronda los 2-3 minutos como máximo. El de apagado es bastante más rápido (a veces tarda algo más, pero es casi inmediato).
El usuario con el que hace autologin es: alu
Con contraseña: alu
En la versión 2020, la hemos modificado para que al abrir una terminal de texto y teclear el comando:
sudo su
Entre directamente como superusuario root y ya no pida contraseña.
Igualmente, en el caso de dicho usuario root, la contraseña es (también): alu
Cambios realizados y listado de SW nuevo
El SW que aparece en esta máquina virtual es, en un 99%, el que hay disponible para GNU/Linux en los laboratorios de la EPS (entre los de Politécnica I, Politécnica IV, laboratorio LTV, laboratorio LELEC y laboratorio LROB1). Además, es muy similar también al que se puede encontrar en los ordenadores del Aula de Acceso Libre (L04A y L04D).
El que no sea el 100% atiende a razones de no generar problemas entre ciertas librerías y programas muy particulares pero, sobre todo, a que hay aplicaciones que tienen sentido tenerlas en los laboratorios pero que, para en un uso en casa (o fuera de los laboratorios de la EPS), no tienen mucha utilidad, por ejemplo iTalc o máquinas virtuales que sí existen en los laboratorios pero que ponerlas, a su vez, dentro de otro virtual, además de cargar demasiado éste, se ejecutarían muy ralentizadas, y tampoco tiene mucho sentido (pues pueden funcionar, de manera independiente, en cualquier arquitectura nativa de GNU/Linux, Windows y Macintosh que tenga instalada la plataforma VirtualBox).
La lista de programas y librerías nuevos (añadidos a otros del curso pasado), sería la siguiente:
- Apache Solr-8.5.2
- Eclipse Java IDE 2020-06-R
- Google Chrome Stable 85.0.4183.10 (reemplaza la versión 69.0.3497.100) con los 3 plugins nuevos (parte superior derecha, a la derecha del campo de entrada de URL):
- Awesome Screenshot: capturar pantalla y video de pantalla.
- Meet Grid View ICE: para ver a todos los participantes en una videoconferencia de Meet.
- Meet Breakout: para crear subsalas en una videoconferencia (breakout rooms)
- jupyter-1.0.0 + jupyterlab-1.1.1 + Google-colab
- Mozilla Firefox 80.0.1 (reemplaza la obsoleta versión 62.0.3)
- nodemon-2.0.4
- npm-6.14.6 (reemplaza npm-6.10.2)
- pandas + numpy + scipy + keras + sklearn + mathplotlib + tensorflow-gpu
- pip3-20.2.3
- python-3.6.9
- Qemu + riscv64 + gcc/g++-riscv64 + gcc/g++-riscv32
- qt-opensource-linux-x64-5.12.3 (con QtCreator 4.9.0).
- Ros-Kinetic que incluye, además los nuevos paquetes:
- ros-kinetic-ros-control
- ros-kinetic-ros-controllers
- ros-kinetic-gazebo-ros-pkgs
- ros-kinetic-gazebo-ros-control
- ros-kinetic-joint-state-controller
- ros-kinetic-effort-controllers
- ros-kinetic-position-controllers
- Virtualbox-6.1.12-13918
- Visual Studio Code 1.48.2 (reemplaza la versión 1.30.2)
- vue/cli (4.4.6)
Por razones de insuficiente soporte gráfico (falta de aceleración 3D, soporte CUDA, memoria de vídeo insuficiente de sólo 128 MB y falta de capacidad de procesamiento gráfico) NO se incluye:
- cuda-10.0-nvidia-410.48
- nvidia-cuda-toolkit
Aspectos a tener en cuenta para la puesta en marcha de la máquina virtual
Básicamente, son los mismos que para el VDI del curso anterior:
- Habilitar el bit de virtualización en la BIOS del equipo anfitrión.
- Configuración HW similar con estas particularidades:
- Al menos 2 Procesadores (CPUs o núcleos de procesamiento). Generalmente, las máquinas actuales, tienen 4-6-8 e incluso algunos más. Hasta la mitad de ellos, es buena idea dar. Es decir, en una máquina con 4 núcleos, daremos 2 al virtual, en una de 6, podemos dar 3, y en una de 8, podremos dar hasta 4 núcleos de procesamiento a la misma.
- Al menos 2048 MB de RAM (e, idealmente, 3072-4096 MB).
- Al menos 128MB de Memoria de vídeo.
- Arranque sólo disco duro (ni red ni CD ni disquete).
- Recomendable utilizar VirtualBox 5.2 o superior (con la rama 5.1 ya no la hemos testado este año pues es demasiado antigua). En este caso, hemos hecho pruebas con la 5.2.44 que es la versión más reciente, de 14 de julio de 2020, de la rama 5.2 de VirtualBox. De hecho, las VBoxGuestAdditions incluidas son de esa versión y va bien. También funcionará, probablemente mejor en cuestiones gráficas y de procesamiento 3D, con las versiones 6.0 y 6.1 de VirtualBox (la más reciente es la 6.1.16).
- Usando las versiones recomendadas de VirtualBox, podremos habilitar soporte para USB 3.0 (xHCI) creando, en el apartado USB, un filtro vacío para admitir dispositivos USB 3.0.
- Instalar Oracle VM VirtualBox Extension Pack (si no lo teníamos ya instalado en nuestra versión instalada de la plataforma VirtualBox).
- Instalar las Guest Additions en la máquina virtual para la versión de VirtualBox que tengamos instalada. Esto ya se explicaba en este mismo apartado para el Virtual Ubuntu EPS 2018.
Bug resuelto en relación a la instalación de las VirtualBox Guest Additions desde entorno gráfico
En relación al último apartado (GuestAdditions), añadir que en esta nueva versión 2020, hemos solucionado un bug que había en las anteriores versiones del VDI a la hora de instalar dichas Additions desde el entorno gráfico (que lo impedía y sólo permitía, como mostrábamos en el enlace del anterior apartado, la instalación desde una terminal de texto como root).
Ahora ya podemos ir a desplegar el Menú Dispositivos, opción Añadir CD de las “Guest Additions” (la de más abajo) y, desde el mismo entorno gráfico, cuando abra la aplicación y pida la contraseña de Administrador para proceder a la instalación, introducir la contraseña:
alu
De esta forma, abrirá el mismo sistema una terminal y empezará a lanzar automáticamente el fichero ejecutable correcto de las Guest Additions para nuestra versión de VirtualBox.
Tendremos que esperar entre 1-2 minutos a su instalación completa. Cuando acabe, bastará con pulsar la tecla INTRO para que dicha terminal se cierre y ya tendremos las Guest Additions de nuestra versión de VirtualBox instaladas en el fichero VDI de nuestra máquina Virtual Ubuntu EPS 2020.
Actualización de ROS-Kinetic con paquetes de julio 2020
Debido a unos problemas que hubo en el laboratorio LROB1 respecto al SW Ros-Kinetic sobre Ubuntu 16.04 LTS, se ha procedido a una actualización masiva de dicho SW con versiones de paquetes más recientes del mismo (liberadas en julio de 2020).
En total, se han actualizado 360 paquetes relacionados con ros-kinetic e instalado algún paquetes nuevo como python-catkin-pkg.
El procedimiento seguido, como root, para dicha actualización, ha sido el siguiente:
1. Modificar repositorio de ROS en:
/etc/apt/sources.list.d/ros-latest.list
asegurándonos que contiene esta línea:
deb http://packages.ros.org/ros/ubuntu xenial main amd64 Packages
2. Borrar información del repositorio de ROS-Kinetic antigua: IMPORTANTE
rm -f /var/lib/apt/lists/packages.ros.org_ros_ubuntu_dists_xenial_*
Si no hacemos esto, aunque hagamos:
apt-get update apt-get upgrade
Nunca actualizará nada (y se empeñará en traerse paquetes antiguos que ya no existen en el repositorio de ROS).
3. Actualizamos, una vez más, información de repositorios:
apt-get update
Ahora, ya sí, se trae la información actualizada de paquetes de ros-kinetic (paquetes de julio de 2020).
4. Actualizamos, ahora ya sí (360 paquetes de ROS, 91,5 MB de descarga y 8573 KB de espacio ocupado):
apt-get upgrade
5. Instalar también los paquetes: catkin y/o python-catkin-pkg
apt install catkin apt-get update && apt-get install --only-upgrade python-catkin-pkg
Prueba de ROS-Kinetic
Esta asignatura se imparte en el laboratorio LROB1 del edificio Politécnica III de la EPS.
Para la prueba vamos a seguir parte del guión de la Práctica 3 de la asignatura IC.
1. Obtener una copia limpia del directorio ~/catkin_ws /src/gazebo_ros_demos :
cd ~/catkin_ws/src rm -fr gazebo_ros_demos git clone https://github.com/ros-simulation/gazebo_ros_demos.git
2. Regenerar “limpios” los directorios ~/catkin_ws/build y ~/catkin_ws/devel:
cd .. rm -fr build devel catkin_make
Este último paso fallará si en el laboratorio o en el VDI de Ubuntu, está instalado python-3.6 (3.6.2) y tenemos estos enlaces simbólicos:
/usr/local/bin/python → /usr/bin/python3.6 /usr/local/sbin/python → /usr/bin/python3.6
La razón es que ROS-Kinetic y catkin_make no funcionan bien con python3 y requieren de Python-2.7 (el que contiene en /opt/ros/kinetic o el propio de Ubuntu 16.04).
Para ello, habrá que renombrar (o borrar) dichos enlaces simbólicos anteriores.
3. Regenerar limpio el directorio ~/catkin_ws/src/my_robot_control:
cd ~/catkin_ws/src rm -fr my_robot_control catkin_create_pkg my_robot_control
4. Dentro de la carpeta ~/catkin_ws/src/my_robot_control ejecutar:
cd my_robot_control mkdir config cd config
5. Crear un fichero llamado my_robot_control.yaml, escribiendo la siguiente estructura en dicho fichero:
rrbot:
joint_state_controller:
type: joint_state_controller/JointStateController
publish_rate: 50
joint1_position_controller:
type: effort_controllers/JointPositionController
joint: joint1
pid: {p: 100.0, i: 0.01, d: 10.0}
joint2_position_controller:
type: effort_controllers/JointPositionController
joint: joint2
pid: {p: 100.0, i: 0.01, d: 10.0}
6. Dentro de la carpeta ~/catkin_ws/src/my_robot_control ejecutar:
cd .. mkdir launch cd launch
7. Crear un fichero llamado my_robot_control.launch y escribir el siguiente contenido en dicho fichero:
<launch> <rosparam file="$(find my_robot_control)/config/my_robot_control.yaml" command="load"/> <node name="controller_spawner" pkg="controller_manager" type="spawner" respawn="false" output="screen" ns="/rrbot" args="joint1_position_controller joint2_position_controller joint_state_controller"/> <node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" respawn="false" output="screen"> <remap from="/joint_states" to="/rrbot/joint_states" /> </node> </launch>
8. Desde la misma terminal de comandos del usuario, ejecutar la simulación del robot RR con los siguientes comandos:
cd ~/catkin_ws source ./devel/setup.bash roslaunch rrbot_gazebo rrbot_world.launch
Esperar a que Gazebo termine de abrir completamente (y aparezca el brazo robótico).
Nota: Si al arrancar, falla y da error de red (como que no puede hacer ping a sí mismo), hay que editar /etc/hosts y comprobar que la dirección IP del host es correcta y existe (vale perfectamente poner 127.0.0.1 en caso de no tener otra IP válida y real disponible).
9. Abrimos una segunda terminal de comandos del usuario y cargamos los controladores de las dos articulaciones ejecutando fichero my_robot_control.launch que hemos creado previamente:
cd ~/catkin_ws source ./devel/setup.bash roslaunch my_robot_control my_robot_control.launch
10. Si todo se ha realizado correctamente y sin errores, abrimos una tercera terminal y ejecutamos:
cd ~/catkin_ws setup ./devel/setup.bash rostopic list
En la salida, entre varias líneas de rutas, deben aparecer los siguientes topics:
/rrobot/join1_position_controller/command /rrobot/joint1_position_controller/pid/parameter_descriptions /rrobot/joint1_position_controller/pid/parameter_updates /rrobot/joint1_position_controller/state /rrobot/joint2_position_controller/command /rrobot/joint2_position_controller/pid/parameter_descriptions /rrobot/joint2_position_controller/pid/parameter_updates /rrobot/joint2_position_controller/state /rrobot/joint_states
Estos son los topics que se han creado por el fichero launch que se ha ejecutado, más concretamente, por el nodo controller_spawner.
Los command topics permitirán enviar referencias a las articulaciones, mientras que el topic joint_states proporciona información acerca del estado actual de las articulaciones.
11. Probaremos los controladores publicando en los correspondientes ”command topics”, por ejemplo:
rostopic pub -1 /rrbot/joint1_position_controller/command std_msgs/Float64 "data: 1.5" rostopic pub -1 /rrbot/joint2_position_controller/command std_msgs/Float64 "data: 1.0"
Con esto conseguimos enviar, como referencias articulares, los valores en radianes 1.5 y 1.0 a las articulaciones 1 y 2, respectivamente, quedando el brazo robótico como se muestra en la imagen siguiente:
