Aquí va a quedar el pdf con mi presentación del taller de ROS en el Encuentro de Software Libre de la UCM 🙂
Categoría: Software Libre
Entrando al mundo de la robótica contemporánea con ROS
En los últimos años, la robótica ha dado saltos tremendos que si bien, no ha alcanzado esas sociedades extremadamente automatizadas que nos muestra la ciencia ficción (R. Daneel Olivaw [1], la humanidad necesita tu apoyo), ha logrado grandes progresos y contribuciones y, de lo que trata el tema de hoy, ha motivado a más gente a entrar al mundo de la robótica.
Es común ver, cuando se habla de educación en robótica, que en carreras de orientación tecnológica y que no necesariamente son de especialización robótica se hacen talleres en los que los participantes pueden interactuar con pequeños robots, o armar los suyos propios con diversos sensores y actuadores. Esto es una experiencia altamente recomendable y disfrutable para personas con cualquier nivel de experiencia, incluso niños o personas sin formación en áreas tecnológicas. Pero cuando uno quiere profundizar e investigar en el área se pregunta, ¿cómo se puede cruzar esa barrera que separa el taller de robótica de la robótica comercial que uno ve en la TV o en internet? Bueno, hacer un primer acercamiento no es tan difícil.
Las personas que me conocen de cerca me habrán escuchado hablar en algunas ocasiones sobre el Software Libre y la importancia de las tecnologías abiertas. Aún hay quien dice que las tecnologías abiertas no son oportunidades para competir en el mercado… pero yo creo que a esas personas les falta un poco de visión de mundo. Basta considerar el hecho anunciado recientemente de que 486 de los 500 supercomputadores más rápidos del mundo funcionan con Linux [2][3]. Bajo mi perspectiva, vivimos en una sociedad tan interconectada que es imposible que un sólo individuo se adueñe de una idea. Las ideas complejas que benefician a mucha gente, se desarrollan desde una colectividad, ya que es en la colectividad dónde pueden nutrirse y refinarse a una velocidad que las hace usables. Así, vamos poco a poco pasando de una economía enfocada en productos (ideas desde un único agente) a una economía basada en servicios, o sea, «qué es lo que hacemos con una idea». Y en el mundo de la robótica hace tiempo se dieron cuenta de esto, de que el avance es demasiado rápido como para intentar hacerlo todo desde un único lugar para poder competir. Así es como nació ROS, uno de los frameworks de robótica más robustos y populares en la actualidad.
ROS: Robotic Operating System
Los orígenes de ROS se remontan al Laboratorio de Inteligencia Artificial de Stanford y posteriormente su desarrollo fue acogido por la incubadora de robótica Willow Garage [4]. Estos esfuerzos han dado origen a una gran comunidad y a un conjunto de herramientas abiertas que permiten avanzar sin tener que reinventar la rueda.
Técnicamente, ROS no es un sistema operativo. Generalmente, se lo considera un middleware o un framework y ambas expresiones son más acertadas. Si hablamos de sistemas operativos, lo común es que asociemos ROS a Ubuntu, que es donde funcionan la mayoría de sus aplicaciones. Existen iniciativas para utilizar ROS junto a otros sistemas operativos, pero lo más común es usar ROS junto con Ubuntu (existen formas de instalarlo en Fedora, pero no todos los paquetes funcionan [5]), así que está de más decir que es un framework pensado para trabajar en Linux (¡yay!).
ROS funciona en un sistema basado en nodos. Tenemos un nodo maestro que gestiona las comunicaciones entre los distintos nodos que se van conectando. Cada nodo puede ser un programa que implemente las bibliotecas de ROS y desarrolle una función puntual, así se logran diseños modularizados en los que el sistema general no depende de manera crítica en la presencia de un componente («Por una yegua coja no vamos a perder la trilla.»). Y esto último es algo fundamental en la robótica, ya que el sistema debe ser robusto a errores imprevistos. Incluso, los nodos pueden ejecutarse en varias máquinas para aligerar el cómputo y desarrollarlo de manera distribuida.
La comunicación en ROS se realiza mediante tópicos y servicios. Los tópicos son canales de comunicación al estilo publisher-subscriber [6]. Un nodo puede abrir un tópico en el que publica un tipo de dato particular. Por ejemplo, yo tengo un dron Parrot AR.Drone 2.0 (ya hablaré de esa criatura, ahora que llegó su repuesto y puedo volver a usarlo <3) que mediante un nodo llamado ardrone_autonomy [7] puede publicar las imágenes que se reciben del dron en el tópico ardrone/front/image_raw. Luego otra aplicación se comporta como suscriptor de ese tópico y lee los datos publicados. Así se separa el proceso de producir datos y de procesarlos, lo que hace posible el que los distintos nodos estén desarrollados en distintos lenguajes de programación. Existen tipos de datos predefinidos para levantar tópicos para las distintas labores habituales en la comunicación en robótica, ya sea recibir datos de sensores o publicar comandos de control. Además, se pueden definir nuevos tipos de mensajes de acuerdo a las necesidades particulares de cada aplicación.
Los servicios son interfaces que un nodo abre a una determinada función. Otro nodo cliente, puede realizar una llamada a un servicio y solicitar que otro nodo realice una tarea, e incluso que envíe cierta información de vuelta. A diferencia de los tópicos, que están constantemente publicando independientemente de si son leídos o no, los servicios funcionan de acuerdo a cuando son llamados. Un ejemplo de servicio es el abierto por el simulador Gazebo, que permite reiniciar una simulación, devolviendo todos los robots instanciados a sus posiciones originales; para ejecutarlo, basta con hacer una llamada a /gazebo/reset_simulation. También hay tipos de mensajes para los servicios y se pueden desarrollar otros nuevos.
Además, ROS cuenta con diversas herramientas que ayudan a trabajar sobre esta arquitectura orientada a nodos. Por ejemplo, están las herramientas rqt, como rqt_graph (Figura 1) que permite ver un grafo con todos los nodos funcionando y los tópicos como flechas desde los nodos que publican hacia los nodos que están suscritos.
También ROS cuenta con un servidor de parámetros que guarda variables y datos que sean comunes a todo el entorno que se está ejecutando, como por ejemplo el modelo de un robot que se esté simulando o las especificaciones de un robot real con el que se esté conectado.
Instalar ROS
El desarrollo de ROS se ha enfocado fuertemente en Ubuntu como plataforma principal. Existen otras plataformas sobre las que se puede instalar [8], pero yo tengo una instalación sobre Ubuntu, así que sobre esta puedo hablar con conocimiento de causa. ROS se basa en distribuciones, que son cambios mayores en sus herramientas principales junto con conjuntos de paquetes compatibles con estas herramientas. Las distribuciones llevan nombres de acuerdo a las letras del abecedario y sus logos tienen que ver con tortugas (creo que tiene que ver con que el ejemplo más básico en ROS se basa en gráficos de tortuga [9]). La versión actual es Jade Turtle, pero yo tengo instalada la versión anterior, que es Indigoo Igloo y es una de las versiones con más soporte (y sobre la que se desarrollaron unos módulos para el dron con los que quiero empezar a trabajar). Para comenzar, yo creo que es recomendable instalar cualquiera de las dos ya que la mayoría del desarrollo se ha estandarizado. Por ahora, para seguir con el conocimiento de causa, vamos con Indigo.
Instalar ROS en Ubuntu es relativamente sencillo si se hace instalando desde los repositorios. Se puede instalar desde los archivos fuente, pero no se recomienda a menos que la ocasión lo requiera. Los pasos de la instalación se pueden encontrar en inglés en [11].
Mi versión de Ubuntu es la 14.04.2 (Trusty Tahr). Indigo es compatible con las versiones 13.10 y 14.04.
Para comenzar la instalación, hay que asegurarse de que los repositorios permitan la instalación desde los componentes «restricted», «universe» y «multiverse». En mi instalación venían habilitados por defecto, así que no tuve que hacer ningún cambio. En caso de necesitar configurarlos, se pueden seleccionar en «Sistema > Administración > Orígenes del Software»o revisar el artículo [10].
Luego se configura el sistema para que acepte paquetes desde packages.ros.org y se acepta su clave:
sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116
Es conveniente revisar que el índice de paquetes esté actualizado ejecutando:
sudo apt-get update
Luego, basta instalar el paquete que incluye todas las aplicaciones de ROS. El paquete más completo, y el que yo instalé, es ros-indigo-desktop-full que incluye todas las herramientas gráficas y las bibliotecas genéricas de robótica.
sudo apt-get install ros-indigo-desktop-full
También existen alternativas que incluyen menos cosas (porque creo recordar que esa versión pesaba como un giga) como ros-indigo-desktop y ros-indigo-ros-base.
sudo apt-get install ros-indigo-desktop
Además, se pueden instalar los paquetes de manera individual de la forma:
sudo apt-get install ros-indigo-NOMBRE_DEL_PAQUETE
Para gestionar las dependencias de paquetes de ROS que vayamos a instalar, se debe instalar rosdep. Esto sirve cuando vayamos a probar algún paquete descargado como código fuente.
sudo rosdep init rosdep update
Para dejar el sistema listo para usar, hay que registrar las variables de entorno de ROS. Esto se puede hacer añadiendo un archivo de configuración predeterminado al final del archivo .bashrc.
echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc source ~/.bashrc
Para seleccionar las variables de entorno de una versión particular de ROS, se puede ejecutar source con el archivo predeterminado.
source /opt/ros/indigo/setup.bash
Otro paquete conveniente de instalar es rosinstall que permite instalar aplicaciones y gestionar sus dependencias de manera más automática.
sudo apt-get install python-rosinstall
Para verificar que todo está instalado y funcionando, abrimos una terminal y escribimos «roscore» y presionamos Enter. Deberíamos ver lo siguiente:
... logging to /home/bruno/.ros/log/70729674-2d80-11e5-9a3d-b803058568da/roslaunch-cronidea-3040.log Checking log directory for disk usage. This may take awhile. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. started roslaunch server http://cronidea:60080/ ros_comm version 1.11.13 SUMMARY ======== PARAMETERS * /rosdistro: indigo * /rosversion: 1.11.13 NODES auto-starting new master process[master]: started with pid [3053] ROS_MASTER_URI=http://cronidea:11311/ setting /run_id to 70729674-2d80-11e5-9a3d-b803058568da process[rosout-1]: started with pid [3066] started core service [/rosout]
Esto significa que lanzamos el nodo principal (master) de ROS y sus componentes, y que ahora podemos empezar a abrir otros nodos.
Un primer ejemplo de funcionamiento
Para usar ROS, es necesario que esté corriendo el roscore. Si lo hicimos funcionar como se mencionó recién, ahora abrimos otra consola y lanzamos el nodo del simulador de tortuga. Este simulador dibuja una tortuga en la pantalla y queda a la escucha de comandos de control para moverla en dos dimensiones. Esta tortuga recibe mensajes del tipo «Twist» en el tópico «/turtle1/cmd_vel», que es el tipo de mensajes estándar que se utiliza para controlar un robot. Puede servir para hacer demostraciones o incluso poner a prueba ciertos algoritmos.
Para lanzar el simulador de tortuga, escribimos:
rosrun turtlesim turtlesim_node
Las aplicaciones de ros se organizan en paquetes, los que pueden contener varios nodos. En este caso «rosrun» busca en el paquete «turtlesim» el nodo «turtlesim_node». Si todo funciona bien, deberíamos ver en la consola algo como:
[ INFO] [1437246767.585809489]: Starting turtlesim with node name /turtlesim [ INFO] [1437246767.603619905]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000]
y una imagen con el simulador funcionando.
Al lanzar el simulador de tortuga, se abrirán nuevos tópicos. El simulador abre el tópico mencionado antes «/turtle1/cmd_vel» en el que recibe comandos de movimiento, y dos tópicos más: «/turtle1/color_sensor» y «/turtle1/pose» en los que publica el color del pixel en el que está y la posición que tiene en la imagen. Para ver los tópicos actualmente abiertos, se puede ejecutar en otra terminal:
rostopic list
y aparecerá algo como:
/rosout /rosout_agg /turtle1/cmd_vel /turtle1/color_sensor /turtle1/pose
Ahora que la tortuga está suscrita a un tópico en el que recibe comandos, podemos publicar comandos a ese tópico. Para hacer un primer ejemplo, usaremos el nodo «turtle_teleop_key» que viene en el paquete «turtlesim». Este nodo recibe las entradas de las flechas del teclado y publica mensajes para controlar la tortuga.
rosrun turtlesim turtle_teleop_key
Deberíamos ver:
Reading from keyboard --------------------------- Use arrow keys to move the turtle.
Usando las teclas, la tortuga comenzará a moverse.
Si abrimos otra consola y lanzamos rqt_graph, podemos ver todos los nodos funcionando y sus respectivos tópicos.
rosrun rqt_graph rqt_graph
Dónde seguir
En este tutorial, mostré un poco sobre cómo funciona ROS, uno de los frameworks de robótica más populares en la actualidad. Para ver su popularidad, basta considerar la cantidad de robots del DARPA Robotics Challenge que lograron grandes resultados usándolo (18 de 23 equipos [12]). Estos mismos principios mostrados en el breve ejemplo de la tortuga, son los que subyacen a toda la arquitectura de ROS y permiten desarrollar complejas aplicaciones distribuidas de alto desempeño.
Para seguir aprendiendo, los pasos siguientes son profundizar en los nodos, los tópicos, los servicios y aplicaciones como el simulador Gazebo o el visualizador RViz. Un buen punto de partida son los tutoriales oficiales de ROS [13]. Además, pretendo hacer más tutoriales para ir profundizando en varios temas que he aplicado.
Referencias
- R. Daneel Olivaw en Wikipedia: https://es.wikipedia.org/wiki/R._Daneel_Olivaw
- «It’s Official: Linux is the King of Supercomputing»: http://fossbytes.com/supercomputer-operating-system-linux/
- Top 500 Supercomputers: http://www.top500.org/statistics/details/osfam/1
- Historia de ROS: http://www.ros.org/history/
- Instalando ROS en Fedora 19: http://www.jann.cc/2013/04/29/building_ros_on_fedora_19.html
- Patrón Publisher-Subscriber: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
- Nodo ROS ardrone_autonomy: http://ardrone-autonomy.readthedocs.org/en/latest/
- Instalación de ROS Indigo: http://wiki.ros.org/indigo/Installation
- Gráficas Tortuga: https://es.wikipedia.org/wiki/Gr%C3%A1ficas_tortuga
- Repositorios de Ubuntu: http://doc.ubuntu-es.org/Repositorios_desde_Ubuntu
- Instalación de ROS en Ubuntu: http://wiki.ros.org/indigo/Installation/Ubuntu
- ROS y la revolución en la robótica: http://www.zdnet.com/article/long-live-ros-why-the-robotics-revolution-is-being-driven-by-open-source-development/
- Tutoriales de ROS: http://wiki.ros.org/ROS/Tutorials/
El Software Libre es como la mayonesa casera
El Software Libre¹ es como la mayonesa casera.
por Bruno Alexis Faúndez Valenzuela
Imagínense lo siguiente por un momento:
Tenemos un mundo sin mayonesa. Luego llega una empresa y presenta su maravilloso producto: «La mayonesa». Todos quedan maravillados ante la infinidad de posibilidades que tiene en la gastronomía y en otras áreas bizarras². Al principio todos son felices, pero llega un punto en que alguien quiere modificar algo en la mayonesa. Esa persona puede tener -como mucho- la información nutricional sobre los compuestos químicos que la componen, pero no la información sobre cómo hacerla. Las personas están atadas a esa empresa que suministra mayonesa y, en consecuencia, están atadas a su sabor, su textura, sus químicos desconocidos, sus precios de mercado.
Imagínense ahora el siguiente escenario:
La empresa hace pública la receta de la mayonesa. ¿Qué ocurre?
Primero, se abre la competencia en el mercado. Nuevas empresas podrán empezar a producir mayonesa y acercarse a un entorno de «competencia perfecta», es decir, donde ninguno de los agentes pueda poner precios que no sean adecuados a la oferta y a la demanda ni poner monopolios. Además, cada empresa empezará a buscar formas de mejorar la mayonesa y darle algo que la haga especial.
Pero en otro punto (y esto es lo más hermoso), imagínense ahora que al hacer pública la receta de la mayonesa casera, su producción no se limitará solamente al ámbito comercial, sino que se extenderá a cualquier persona que pueda disponer de los materiales. Personas en sus casas podrán ver la receta, juntar los materiales y hacer su propia mayonesa. Si no les gusta como queda, podrán modificar la receta y añadir sus propias variantes. Si quieren hasta pueden compartir las variaciones que le hagan a la receta original y darle a otras personas la posibilidad de probar su creación e incluso añadir sus propias modificaciones. En este escenario, tenemos una creación constante de mayonesa casera que enriquece el entorno gastronómico de todas las personas.
El Software Libre es como la mayonesa casera.
Es hacer de libre conocimiento la forma en que los programas son hechos.
Es brindar la posibilidad de modificarlos a gusto.
Es la posibilidad de compartirlos con quien uno quiera.
Es enriquecer el entorno creativo de la tecnología.
Es atacar los monopolios.
Es horizontalizar jerarquías.
Es potenciar el trabajo en comunidad.
Hay gente a la que no le gusta la mayonesa casera, pero el mero hecho de poder usar mayonesa casera ha propiciado una diversidad siempre creciente de sabores. Lo mismo pasa en el Software Libre. Es una posibilidad constante de creación, compartición, innovacion y trabajo en pos de la comunidad.
Es Libertad.
1: http://www.gnu.org/philosophy/free-sw.es.html
2: http://www.recetasmierdaeuristas.com/15-sorprendentes-usos-de-la-mayonesa-para-el-hogar/
Creando una revista con Software Libre – Parte 1: Planificación General
Una revista es un proyecto serio. Debemos partir aclarando eso. Aunque el contenido de una revista sea lo menos serio del mundo, el proceso de desarrollarla y tenerla lista dentro de los plazos implica planificación. Por eso dedicaré un capítulo a ciertos temas referentes a la planificación de una revista.
Planificación General
Primero, al iniciar una revista, se debe definir con claridad el objetivo que se persigue con ella, la forma que adoptará el equipo de trabajo y las responsabilidades que cada uno tomará. Además, es opcional añadir una sección en la que se defina el protocolo a seguir para publicar en la revista. El nivel de rigidez que uno tenga en su plan general dependerá del tamaño del proyecto y de la cercanía con la gente con la que uno trabaje.
Como inspiración para el plan general se estudió el lineamiento editorial usado en la HDMagazine donde definen muy prolijamente los objetivos que persiguen y su método de trabajo.
Para realizar un documento de plan general se puede usar cualquier método de edición de documentos. Pero como no hay nada más maravilloso que el Software Libre, usaremos LibreOffice Writer para crear el documento.
Es recomendable hacer el documento con bastante cuidado y usando bien los títulos para que luego sea fácil de navegar. Para esto es importante marcar cada título con su correcto formato y usando los distintos niveles para organizar subsecciones. Para dar formato de título basta con seleccionar el texto y en el estilo seleccionar un tipo de encabezado.
Quizás a alguien le pueda parecer algo para principiantes el explicar esto, pero es importante mencionarlo porque así el documento queda mucho más legible y organizado si se desea pasar a PDF y compartir con otros miembros del equipo. No se debe olvidar el usar distintos niveles de encabezados, porque al generar el índice automático (razón por la que usamos los estilos de títulos) los distintos niveles de encabezados harán un índice mucho más fácil de navegar. El nivel mayor es el 1 (para el título del documento) y luego van aumentando mientras aumenta lo específico del tema designado por el título.
Para generar un índice automático basta ir a Insertar -> Índices y Tablas -> Índices, con lo que aparece un menú de configuración en el que se le podrá dar un título y al cliquear Aceptar se generará un índice automático en base a todos los títulos.
Al generar el índice, aparecerán todos los títulos del texto indentados de manera adecuada y su respectiva página:
Al seleccionar la opción «Exportar en formato PDF» en el menú «Archivo», se generará un PDF con un índice que permitirá recorrer el documento simplemente haciendo clic en las secciones.
Si se hace cualquier modificación en los títulos del documento, basta hacer clic derecho en el índice y seleccionar «Actualizar Índice/Tabla» para que los contenidos se actualicen.
Ahora pasemos a lo verdaderamente importante: el contenido del documento.
Como lo mencioné, lo que pongamos en el plan general depende del nivel de rigidez con el que vayamos a dirigir la creación de la revista. Pero para tener un inicio, aquí dejaré las secciones generales que nosotros estamos usando para nuestro proyecto.
Sobre la Revista
Aquí se incluye una descripción general sobre el objetivo de la revista, los principios y valores que regirán su producción o en su defecto la «misión» y la «visión» del proyecto, además del público al que se dirige.
Lineamientos temáticos
Aquí se define el tipo de contenido que va a ser incluido en la revista, para así definir un marco de trabajo claro para la edición. Es importante definir bien esto, porque así los redactores no se desvían del tema principal de la revista y si lo hacen, existe un respaldo para decirles que su trabajo está equivocado y reducir los conflictos.
Equipo de trabajo y tipos de colaboradores
Aquí se define la estructura que tendrá el equipo de trabajo que participará de la revista y las responsabilidades de cada uno.
Generalmente la dirección está compuesta por un director general que es responsable de coordinar el funcionamiento general de la revista y asegurarse de que los plazos se cumplan, un editor en jefe que se encargue de que el contenido publicado sea el adecuado y un director de arte que se encargue de vigilar el aspecto estético de la revista. Como nosotros tenemos una filosofía más comunitaria al movernos en torno al software libre, formamos un consejo editorial en el que nos repartimos esas tres labores de acuerdo a como sea necesario en el momento. Además se pueden añadir cargos como «comunicaciones» o «marketing» si es que son necesarios.
Luego se definen los tipos de redactores. En nuestro caso consideramos dos grupos: un grupo permanente que se compromete a contribuir con un artículo por cada edición de la revista, para asegurar un mínimo de contenido, y un grupo de redactores temporales que redactan artículos para ciertas ediciones en particular y no adquieren mayor compromiso con el equipo de la revista.
Sobre el proceso de desarrollo de una edición
Aquí se definen las «burocracias». Es importante aclarar la forma de enviar las contribuciones a la revista y los parámetros con los que se van a evaluar, para así evitarse problemas a largo plazo y asegurar que en la revista se publicará contenido de calidad.
Sobre los medios de difusión
Aquí se describen, como su nombre lo dice, los medios a través de los que se distribuirá la revista cuando esté terminada. Pueden ser medios impresos o digitales. Además, si es necesario, se puede asignar un responsable de distribución que se encargue de coordinar este proceso.
Esas son las secciones que yo considero importantes. Eso no niega que en el futuro pueda añadir otras o modificarlas. Uno siempre debe preocuparse de que toda la organización sea en pos de que la revista sea desarrollada adecuadamente y no se debe tomar la creación de un plan general como una obligación, sino como un complemento para mejorar el ambiente de trabajo.
Para terminar esta edición del tutorial, dejo disponible para descargar la plantilla del plan general que yo tengo por si alguien quiere usarla. Es un archivo .odt que pueden descargar haciendo clic Aquí.
En la próxima edición de este tutorial también tendremos el tema de la planificación. Pero ya empezaremos a hablar de cómo planificar la primera edición de una revista y echaremos un vistazo general a Scribus, el que será nuestro compañero en la maquetación y edición.
Cualquier duda u opinión la pueden dejar en los comentarios y también pueden suscribirse para que lleguen las notificaciones de las nuevas publicaciones a sus correos.
Creando una revista con Software Libre – Parte 0: Introducción
Con unos amigos de la unviersidad decidimos empezar a trabajar en una revista cuyo tema principal sea difundir la tecnología y la cultura libre. Para empezar el trabajo, he estado aprendiendo ciertas cosas sobre el campo de la «autoedición» (desktop publishing). La autoedición es el área de trabajo en la que uno, a través de diversas herramientas, puede maquetar y diseñar documentos gráficos para hacer revistas, afiches, panfletos, flyers y publicaciones similares.
Se me ocurrió que lo que he ido aprendiendo sobre la creación de revistas no puede quedar sólo ahí. Ese conocimiento debe servir a mucha más gente interesada en crear sus propias revistas, por lo que empezaré una serie de tutoriales en los que iré explicando distintas fases y herramientas que pueden ser utilizadas para crear sus revistas. Lo importante aquí, es que todas las herramientas utilizadas en la serie de tutoriales van a ser libres, es decir, podrán distribuir sus creaciones sin limitaciones y sin estar atados a asquerosas licencias privatizadoras.
Es importante mencionar que a través del uso de herramientas libres, los medios que crearemos serán libres. Esto implica que nosotros seremos absolutos dueños de los contenidos que distribuyamos, lo que nos da un tremendo poder libertario. Si los medios de comunicación de masas nos ocultan información o no nos dan información de calidad, nosotros mismos debemos tomar la información en nuestras manos y comunicarla.
(Click en la imagen para ver la original en Flickr)
Sin agregar mucho más, ahora hay que mencionar los temas generales que se tratarán en esta serie de tutoriales:
- Maquetación de documentos con Scribus: Una de las áreas principales en las que trabajaremos será la maquetación de documentos. Por maquetar nos referimos a definir una estructura física sobre la que pondremos el contenido. Esto incluye definir espacios donde irán los títulos, los textos, imágenes de fondo, distribución de columnas y todo lo que tenga que ver con forma.
- Diseño de algunos elementos gráficos: Este tutorial no será principalmente sobre diseño gráfico, sino que se enfocará en la creación de una revista. Sin embargo, también se tratarán algunos temas sobre creación de gráficos para lo que se tocarán algunos programas como Inkscape o quizás GIMP (aunque en este último no tengo mucha experiencia). Quizás sean apartados dentro de esta misma serie de tutoriales o tengan sus series de tutoriales propias. Todo dependerá de mi tiempo.
- Obtención de recursos: Para una publicación necesitaremos tener un respaldo de elementos gráficos que nos sirvan para darle un mejor acabado a nuestras creaciones. Para esto, mostraremos distintas fuentes de las que obtener recursos como fuentes e imágenes que sean libres de uso.
- Otros: Hay muchos temas que no son de carácter técnico, que requieren bastante análisis en las fases de planificación de una revista como pueden ser el diseño de storyboards o establecer un equipo de trabajo con el que podamos trabajar en conjunto nuestra revista (Sí, necesitarán de un equipo de trabajo, así que empiezen a armar un grupo pequeño de gente con la que tengan un buen ambiente de trabajo para que su proyecto sea exitoso.
En general, estos temas se tocarán en los tutoriales y quizás otros más se sumarán en el camino. Espero ir los sacando de forma periódica y que a alguien le sean de utilidad. Si es así, estoy dispuesto a recibir sus comentarios y preguntas.
Pronto vendrá el primer tutorial en el que hablaremos de la planificación de una revista.
PD: Esperamos terminar nuestra primera edición de la revista para el día 10 de octubre, día en el que realizaremos el encuentro Regional de Software Libre en la Universidad Católica del Maule, en Talca. Si todo sale bien, ese mismo día estrenaremos la revista y posiblemente hagamos una charla sobre los temas de estos tutoriales. Aprovecho de dejar la invitación a cualquier persona que lea esta publicación a informarse en la página en Facebook de NULL (nuestro grupo de difusión de Software Libre) y a visitar nuestro sitio web donde pronto tendremos más información sobre el evento.
Detalles después de instalar Fedora 18
Ayer instalé Fedora 18 para poder actualizar todo de una vez y tener la máquina lista para empezar las clases, pero me encontré con un par de detalles que tuve que acomodar. Hago este post por si a alguien le sirven estas pequeñas configuraciones que hice.
Nota: Este no es uno de esos post tipo «qué hacer luego de instalar Fedora 18». Para eso hay unos posts bastante buenos para darle el puntapié inicial al sistema como este post que explica cosas útiles como instalar repositorios extras y códecs.
En este post se tratarán los temas:
1. Activar ejecución de archivos de texto ejecutables
2. Ocultar la barra superior
3. Montar automáticamente otras particiones con fstab
4. Activar «Cerrar Sesión»
1. Activar ejecución de archivos de texto ejecutables
Como hace poco empecé con Processing, una de las primeras cosas que hice fue descargarlo y ejecutarlo. Bueno, al menos intenté ejecutarlo. Resulta que cuando clickeaba la opción en Propiedades del archivo para ejecutar Processing (un script sh) para que el archivo diera la opción de ejecutarse como un programa, seguía abriéndolo como un archivo de texto sin preguntarme si quería ejecutarlo. Funcionaba si lo abría de una terminal y usaba el comando sh, pero siendo sinceros, me da una flojera tremenda hacer eso cada vez que quiero abrir el programa. Indagando un poco, encontré que esto se puede solucionar configurando directamente las variables de Nautilus en dconf, para lo que instalé el dconf-editor que permite modificar directamente estas variables.
La variable a modificar es:
org->gnome->nautilus->preferences "executable-text-activation"
Y se le debe dar el valor «ask» para que pregunte o «launch» para que los ejecute directamente.
2. Ocultar la barra superior
Una de las pequeñas manías ñoñas que tengo es aprovechar la pantalla al máximo y preocuparme de que se vea bien, por eso en Fedora 17 tenía instalada la extensión Panel Settings que se encargaba de ocultar la barra superior cuando no la estaba usando. Pero ahora, con el cambio a Gnome 3.6, la extensión está deshabilitada por lo que se debe usar la extensión Hide Top Bar que sí es compatible con esta versión y hace casi lo mismo.
3. Montar automáticamente otras particiones con fstab
Habemos muchos a los que nos gusta mantener varias particiones en el disco duro ya sea para tener varios sistemas operativos, o para tener nuestros archivos seguros. El problema de cuando uno llega a Fedora es que cada vez que uno quiere abrir los discos desde Nautilus, pide la contraseña del usuario para montarlos y bueno, me da flojera hacerlo todos los días. Además, cuando uno tiene su música en otra partición es incómodo tener que montar el disco duro para que las canciones aparezcan en la lista. Por eso, aquí está la forma de hacer que las particiones que tengamos aparezcan montadas al iniciar el sistema. Esto se logra editando el archivo fstab que está ubicado en /etc/fstab que se verá algo así:
# # /etc/fstab # Created by anaconda on Thu Mar 7 20:14:41 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=104c9caa-f63a-4ffc-83ee-846c9644ae7d / ext4 defaults 1 1
En el caso de que el documento se abra como sólo lectura, podemos abrirlo ejecutando sudo nautilus desde la terminal y buscando el archivo.
En este archivo, cada línea representa una partición a montar al inicio del sistema. Para más información sobre el valor de cada campo, Wikipedia lo explica. Por ahora, diremos que en orden son: dispositivo o partición, nombre del punto de montaje (que en Fedora 18 y 17 se hace después de /run/media/nombredeusuario/), sistema de archivos, opciones extras y un par de números que indican el orden en que se revisan las particiones al principio para ver si tienen errores. En mi caso agregué dos particiones: una de datos donde mantengo mis archivos principales y otra de W****ws (lo tengo instalado porque en la u nos hacen trabajar con él… ¡Malditos monopolios! [y bueno, además por Skyrim]), ambas particiones NTFS.
Al final, el archivo fstab de mi máquina quedó así:
# # /etc/fstab # Created by anaconda on Thu Mar 7 20:14:41 2013 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=104c9caa-f63a-4ffc-83ee-846c9644ae7d / ext4 defaults 1 1 /dev/sda2 /run/media/bruno/Datos ntfs defaults 0 0 /dev/sda1 /run/media/bruno/Windows ntfs defaults 0 0
Luego de reiniciar el equipo, las particiones aparecerán por defecto montadas.
4. Activar «Cerrar Sesión»
Antes, cuando empezó Gnome 3, la gente se quejaba de que no aparecía por defecto la opción «Apagar» y había que presionar Alt para activarla. Ahora por defecto aparece Apagar, pero no aparece Cerrar Sesión (aparece en caso de que uno tenga varias sesiones instaladas). A algunos no les molesta mucho pero yo tengo la costumbre de usar esa opción, así que para activarla hay que abrir dconf-editor y navegar hasta org->gnome->shell y marcar la opción «always-show-logout».
Espero que esto le sea de utilidad a algún Fedorillo que ande dando vueltas por ahí y si hay algo que quieran agregar, tienen los comentarios más abajo a su disposición 😀
Encuentro Regional de Software Libre UCM
¡Me entrevistaron, lo grabaron y lo subieron a YouTube! D:
Yo estaba bien con la parte de que me entrevistaran y pensé que con la cámara estaban tomando fotos para el diario de la u, pero al parecer hicieron un reportaje de nuestro evento.
Bueno, el Encuentro de Software Libre fue un evento que llevamos a cabo en la universidad con el fin de hacer difusión del uso de software libre y motivar a la gente a abandonar el software privativo. Aquí pueden ver el video que hizo el equipo de comunicaciones de la universidad acerca del evento.
Esperamos que este evento desde ahora en adelante se siga haciendo todos los años en la universidad, porque creemos que es importantísimo que se muestre a la comunidad que no se requiere estar dominado por licencias ni por un mercado de software para sacarle el máximo provecho a las herramientas tecnológicas.
- Link del evento
- Sitio web de NULL, grupo de Software Libre
- Página en Facebook de NULL
- NULL en Twitter
Bruno Faúndez Valenzuela 