We can work it out

Facebooktwitterredditpinterestlinkedinmail

In English

Trabajar en grupo es algo que creo que, como Bartleby, preferiríamos no hacer. Pero es necesario sobrellevarlo con dignidad en cualquier entorno profesional. Si tienes la inmensa suerte de trabajar en un equipo en el que encajáis todos bien, sacando partido a las potencialidades de cada uno y aceptando vuestras diferencias y manías (sí, las tuyas también, todos tenemos una pedraíta a veces), disfrútalo y, sobre todo, cuídalo mucho.

Pero si no es el caso, y te toca trabajar con gente a la que no conoces, ahí van algunos trucos que a mí me funcionan, por si te ayudan. Están enfocados fundamentalmente a la carrera universitaria, donde tienes que aprender a manejarte en estas situaciones. De entrada, a lo mejor te parecen un poco estrictos o exagerados, pero si te fijas en realidad son bastante sencillos de implementar y a la larga evitan trabajo y, sobre todo, malos entendidos. Cuando pases a trabajar en una empresa, tendrás que adaptar estas ideas a ese entorno, que tendrá sus propias particularidades.

La causa más frecuente de problemas en un grupo de trabajo es la falta de comunicación dentro de una grupo (potencialmente explosivo) de personalidades y situaciones: se puede juntar gente cuadriculada, desorganizada, que trabaja además de estudiar, que se va a su pueblo los fines de semana, con horarios imposibles, con limitaciones de transporte, con situaciones personales complicadas. Y todo eso sin descartar a los vivalavirgen y los directamente jetas.

Como lo importante es sacar el trabajo adelante sin cargarte de más trabajo del que te corresponda y sin llevarte malos ratos (o muy pocos), yo haría lo siguiente:

1.- Tener una reunión inicial (presencial, online, mixta, como mejor os venga a cada uno), en la que:

· Se deciden cuáles son vuestros medios de comunicación: whatsapp, correo, teléfono…

· Se recogen las limitaciones de horas y fechas que tiene cada uno. Si no contestáis al whatsapp los fines de semana, lo decís. Si os vais de Semana Blanca a esquiar y no vais a estar para nadie, lo decís. Si trabajáis y durante el horario laboral no podéis atender el wasap o el correo, lo decís. No hace falta dar explicaciones o contar vuestra vida si no queréis, basta con que el resto del grupo sepa cuándo estáis accesibles.

· Sed razonables para no imponer como limitación vuestra algo que no es prioritario, y flexibles para aceptar la problemática de los demás.

2.- Se decide si se va a usar alguna aplicación colaborativa de organización (Milanote, Trello…) y un repositorio común de trabajo (Google, github…). Obviamente, si decidís usar alguna de estas herramientas, todo el mundo debe tener acceso, y se tiene que mantener actualizada.

3.- Se reparte el trabajo. Si el trabajo consta de varias tareas muy diferentes entre ellas, intentad aprovechar las habilidades de cada cual: hay gente mejor haciendo transparencias, otra prefiere presentar oralmente, otra programando… Obvio: el reparto debe ser equilibrado y consensuado, y todo el mundo debe estar razonablemente satisfecho con lo que le ha tocado. Aunque cada uno tenga su tarea, el trabajo es una entrega conjunta que debe tener un estilo coherente: se nota mucho (por ejemplo, en el estilo de redacción) cuando el trabajo no se ha revisado conjuntamente y es una unión de los trozos de cada uno. Además, puede ser peligroso si os van a examinar sobre ese trabajo: “es que eso no es de mi parte” no es una respuesta aceptable.

4.- Se establecen finalmente las tareas y sus responsables, y sus fechas y modos de entrega. Si la fecha de entrega final de todo el trabajo es X, conviene que vuestra fecha de entrega sea X-2 días, para así tener margen por si surgen imprevistos (que surgirán).

5.- Podéis discutir y negociar todo lo que haga falta, pero una vez se llega a un acuerdo, se respeta. Procurad que quede algún tipo de constancia por escrito de lo acordado y de que todo el mundo lo acepta (correo conjunto, herramienta de gestión…). En caso de dudas o conflictos posteriores, siempre os podéis remitir a ese acuerdo escrito (en vez del típico “yo te dije”- “tú no me dijiste”).

6.- Cualquier modificación a lo inicialmente acordado tiene que ser aceptada por todo el grupo. Recordad que la comunicación dentro del grupo es fundamental, no es bueno que haya “chupipandis” internas que vayan a su bola sin hablarse con el resto.

Una vez organizado y repartido todo el trabajo, si alguien no puede cumplir con su fecha de entrega, debe avisar a los demás lo antes posible para que podáis reorganizaros. La causa debe ser, obviamente, de fuerza mayor. Lo deseable es que seáis autónomos y re-repartáis (que me perdone la RAE) el trabajo, de manera que alguien se cargue más en ese momento a cambio de que el causante del cambio asuma más tarea después. Si no es posible y veis que no podéis cumplir el plazo de entrega, avisad cuanto antes a vuestro profesor/superior.

Si a pesar de todo esto algún miembro del equipo se desentiende, no cumple con lo acordado o sencillamente desaparece sin más (el ghosting está muy feo: una persona adulta va por derecho y avisa de que abandona el grupo, en vez de generarle un problema a compañeros -y al profesor- que no tienen culpa de nada), avisad inmediatamente a vuestro superior. Gestionar este tipo de situaciones también forma parte del trabajo en equipo, y tenéis que saber manejarlas. Como profesora, si dos días antes de una entrega os descolgáis con que no podéis hacerla porque fulanito o menganita hace dos semanas que no os responden a los correos, os diré que el fallo también es vuestro por no haberme avisado con tiempo.

PD: tu más mejor amigui del alma en la carrera puede ser un pésimo compañero de trabajo. Y no pasa nada, no es algo malo, sólo hay que hablarlo civilizadamente y no dejar que el trabajo dañe una amistad (que es mucho más importante).

PPD: esto es algo que cualquier adulto funcional debería aplicar, pero por si acaso. No se habla/escribe mal ni se cotillea a espaldas de nadie del grupo. Si tenéis algún comentario negativo o delicado que hacer, se dice educadamente y a la cara. En el ámbito académico es importante, pero en el ámbito laboral, todavía más: no seáis el compañero víbora y cotilla.

En Español

Team work is something I believe that, as Bartleby, we would prefer not to. But we have to bear with it with dignity in any professional environment. If you are lucky enough to work in a team where you all fit well together, making the most of each other’s potential and accepting your differences and quirks (yes, you too, we all are a pain in the neck sometimes), enjoy it and, above all, take good care of it.

But if this is not the case, and you have to work with people you have not met before, here you have some tips that work for me, in case they help you. They are mainly focused on college studies, where you have to learn how to manage in these situations. At first, they may seem a bit strict or exaggerated, but if you look at them, they are actually quite simple to implement and in the long run they avoid work and, above all, misunderstandings. When you go to work in a firm, you will have to adapt these ideas to that environment, which will have its own particularities.

The most common source of problems in a work group is the lack of communication within a (potentially explosive) group of personalities and situations: you can find people who are square-headed and others who are disorganised, people who work and also study, people who go back home at weekends, people with impossible schedules, people with conmute limitations, people with complicated personal situations. And all this without discarding the happy-go-lucky ones and those who simply have a nerve.

Since the main thing here is to get things done without overworking and without bad blood (or just a little), I would do the following:

1.- Have an initial meeting (face-to-face, online, mixed, whichever suits each of you best), in which:

· Decide how you are going to talk: whatsapp, mail, phone…

· The time limitations each one of you have are discussed. If you don’t answer the whatsapp at weekends, you say it. If you are going to ski during Spring break and you are not available for anyone, you say it. If you work and during working hours you can’t answer the wasap or mail, you say it. There is no need to give explanations or tell your life story if you don’t want to, just inform the rest of the group when you are accessible.

· Be reasonable so as not to impose as your time limitations something that is not a priority, and be flexible to accept the situations of your workmates.

2.- Decide whether to use a collaborative workflow application (Milanote, Trello…) and a work repository (Google, github…). Obviously, if you decide to use any of these tools, everyone must have access to them, and they must be always updated.

3.- The work is shared out. If the work consists of several very different tasks, try to take advantage of your different skills: some are better at making slides, others prefer to present orally, others excel at programming… Obvious reminder: the distribution must be balanced and agreed, and everyone must be reasonably satisfied with their share. Although everyone has their own task, the work is a joint delivery that must have a coherent style: it is very easily noticed (for example, in the writing style) if the work has not been revised and is just a concatentation of pieces. Also, it can be dangerous if you have to answer exam questions about the work: “I did not work on that part” is not the right answer.

4.- Finally, the tasks and the people in charge are established, as well as the dates and methods of delivery. If the final deadline for all the work is X, you should fixed an internal deadline of X-2 days, so you have a little more time in case unforeseen events arise (and they will).

5.- You can discuss and negotiate as much as you need to, but once an agreement is reached, you should respect it. Make sure that there is some kind of written record of what has been agreed and that everyone accepts it (cc-ed email, management tool, etc.). In case of doubts or later conflicts, you can always refer to this written agreement (instead of the typical “I’m sure I said”- “No you didn’t”).

6.- Any changes to the initial agreement must be accepted by the whole team. Remember that communication within the group is fundamental, it is not good that there are internal “evil cliques” that go their own way without talking to the rest.

Once all the work has been organised and distributed, if someone is unable to meet their deadline, they should inform the others as soon as possible so that you can reorganise yourselves. The cause must obviously be force majeure. It is desirable that you be autonomous and re-shuffle the work, so that someone else takes on more work at that time in exchange for the person causing the change taking on more work afterwards. If this is not possible and you find that you cannot meet the deadline, please inform your teacher/supervisor as soon as possible.

If, in spite of all this, a member of the team is not willing to do what was agreed or simply disappears (ghosting is a very mean thing: a grown-up person stands up and informs that he/she is leaving the group, instead of creating a problem for colleagues – and the teacher – who are not to blame for anything), inform your superior immediately. Managing such situations is also part of teamwork, and you need to know how to handle them. As a teacher, if two days before a deadline you say that you can’t do it because any Tom, Dick, or Harry haven’t replied to your emails for two weeks, I will tell you that it is also your fault for not having warned me in time.

PS: your college BFF can be a lousy co-worker. And that’s OK, it’s not a bad thing, you just have to talk about it in a civilised way and not let work damage a friendship (which is much more important).

PPS: this is something any functional adult should apply, but just in case. You don’t speak ill or gossip behind the backs of others in the team. If you have a negative or sensitive comment to make, you say it politely and to their face. This is important in the academic environment, but even more so in the work environment: don’t be the busybody viper colleague.

Los ingenieros y Cervantes

Facebooktwitterredditpinterestlinkedinmail

Este año hemos conmemorado los 401 años de la muerte de Cervantes y Shakespeare. Qué mejor momento para escribir este tocho-post sobre la importancia de la capacidad de comunicación en la ingeniería (y en cualquier otra profesión).

[Traducción: empecé a escribir este post en 2016, y no he podido acabarlo hasta ahora 😉 ]

En mis asignaturas le doy mucha importancia a la correcta redacción de informes escritos; posiblemente mis alumnos dirán que soy un poquito jartible con el tema 🙂 Pero es que no es una neura mía: son muchas las asignaturas de diferentes programas universitarios españoles que recogen esta competencia, y lo mismo ocurre con las universidades extranjeras. ¿Por qué? Pues porque expresarse de forma adecuada, tanto oralmente como por escrito, es un requisito para muchos puestos: vuestro trabajo en el mundo real va a implicar, sí o sí, tener que redactar informes y/o hacer presentaciones orales (y lo digo por experiencia propia, que también he trabajado en la empresa privada).

Por eso, aquí os dejo algunas ideas sobre el tema que creo que os pueden ayudar.

  • La ortografía es importante. Sí, lo es, de verdad. Todos respetamos el lenguaje matemático y seguimos sus normas, así que con el idioma debe ocurrir lo mismo. Y, por favor, que a ninguno se le ocurra decirme eso de que yo es que soy de ciencias, que me pone de muy mal café, igual que cuando escucho a alguien que no se maneja con matemáticas básicas decir lo de yo es que soy de letras. Los de ciencias y los de letras somos todos universitarios y debemos tener unos conocimientos elementales de lengua y matemáticas. Ideas a tener en cuenta:
    • Confiar ciegamente en el corrector ortográfico del procesador de texto que uséis es la receta segura para obtener un documento con las tildes mal puestas. Caso típico que nos puede ocurrir a los de Informática: práctica y practica son términos perfectamente válidos, el corrector no os va a avisar, y vais a entregar un informe de laboratorio con un hermoso “en esta practica hemos abordado…”
    • La RAE es tu amiga, y su diccionario online más aún 🙂 También es útil consultar la web de Fundeu.
    • Faltas de ortografía son todas, no sólo las “gordas”: hay que tener cuidado con las tildes también.
    • Respecto al uso de la tilde en los pronombres interrogativos y exclamativos, os remito a este completísimo enlace de Gabriella Literaria, donde se explica de forma clara y sencilla cómo deben acentuarse esos pronombres (nota: al final de ese post encontraréis la gloriosa regla cani que nunca falla ;))
    • También os recomiendo 70 trucos para sacarle brillo a tu novela: corrección básica para escritores, de la misma autora. La primera parte del libro se dedica a cuestiones de escritura general que nos vienen muy bien a todos.
  • Antes de entregar cualquier trabajo hay que leerlo. Parece un consejo del Capitán Obvio, pero es así.
    • Si es posible, además, es mejor leerlo en papel: las erratas destacan más, y es más fácil entender la estructura que hemos querido dar al texto (Mabbett I. W. (2007) “Writing History Essays. A Student’s Guide”, Palgrave MacMillan.)
    • Si es posible, es mejor dejar reposar el texto unos días y retomarlo después: veréis cómo aparecen (nuevas) erratas, y seguramente se os ocurrirán mejores formas de estructurarlo.
    • Si es posible, es conveniente que lo lea otra persona, aunque no tenga conocimientos técnicos: os puede decir si entiende lo que habéis escrito o no, y seguro que además os encuentra varias erratas (sí, otra vez).
  • Redactar no es lo mismo que hablar. Cuando hablamos, nuestro lenguaje corporal, expresiones faciales y entonación aportan información que no se percibe en un texto escrito. Además, el contexto es importante: en clase y en el laboratorio empleamos (todos, yo la primera) un lenguaje muchas veces informal, porque lo que nos interesa es entendernos en ese momento. Pero esa informalidad no puede trasladarse a un documento, mucho menos si es técnico:
    • No es nada conveniente incluir expresiones coloquiales. Si creéis que es imprescindible para explicar algo (aunque sería raro), entrecomilladlas.
    • Hay que vigilar mucho que usamos el lenguaje propio de nuestro campo de conocimiento. Por ejemplo, los alumnos de Informática debéis tener claro qué significan y cómo se usan conceptos básicos como variable, constante, tipo, algoritmo:

– “Realizar código”: no, el código se escribe o se implanta.
– “expresión matemática” no es lo mismo que algoritmo.
– “nº en positivo”: nº positivo.

  • Antes de escribir siempre es conveniente hacer un pequeño esquema con papel y lápiz (sí, esas herramientas analógicas tan obsoletas 😉 ). Ese esquema contendrá la estructura básica de apartados del documento, y las principales ideas que queráis contar en ellos. Es decir, primero hay que tener claro qué se quiere decir, y después ya se puede empezar a escribir.
  • La redacción debe ser lo más simple posible, sin sobrecargar el texto con explicaciones superfluas ni frases complejas (a mí, por ejemplo, esto me suele costar trabajo). Solución: primero redactas, y luego podas como si no hubiera un mañana.
  • Escribir bien es una habilidad que se va mejorando y puliendo con el tiempo, así que no hay que agobiarse inicialmente, sino aplicar estas ideas básicas. Y a partir de ahí, practicar, practicar y practicar.
  • Por si no lo he repetido lo suficiente a lo largo del texto, vuelvo a hacer hincapié: Murphy no descansa. Repasaréis diez mil veces el texto, lo dejaréis reposar, lo repasará alguien más… y una vez entregado, os daréis cuenta de que hay una errata. La probabilidad de que eso ocurra está muy próxima a 1. Pero, aun así, la diferencia entre un texto escrito a zorrombullón y un texto escrito con esmero y dedicación es enorme. Así que ya sabéis qué tenéis que hacer 🙂

[ACTUALIZACIÓN: Ya le he pillado al post una errata y una tilde mal puesta. Ains.]

Let’s talk

Facebooktwitterredditpinterestlinkedinmail


[In English]

Aquí van algunos consejillos que suelo dar a mis alumnos cuando van a presentar sus TFGs/TFMs, aunque creo que pueden servir para cualquier presentación más o menos reglada que vayan a dar.  Disclaimer: están basados en mi experiencia a los dos lados de la tarima, es decir, como ponente y como oyente, y como es mi experiencia, no todo el mundo tiene que estar de acuerdo, así que al que no le gusten, que no los use 🙂

  • Ensáyala mucho (pero mucho, mucho) para ajustarte al tiempo que tienes, demo incluida. Cronométrate para estar seguro de que cumples el tiempo, y si tienes a alguien a mano para torturarlo y ensayar con público, mejor.
  • Recuerda que la presentación la tienes que hacer mirando al tribunal, no a la pantalla de proyección.
  • En la primera transparencia tienen que aparecer el título del TFG/TFM, titulación, autor, y directores.
  • La última transparencia puede ser igual que la primera, y así se queda como fondo elegante mientras el tribunal te pregunta.
  • Si el presidente del tribunal, al introducir el acto, lee en voz alta el título del TFG/TFM, tu nombre, etc. , no los repitas tú al empezar la exposición.
  • La presentación debe seguir el mismo orden de apartados de la memoria.
  • Procura que en las transparencias haya un índice visible en alguna parte (a la izquierda, o arriba del todo, pequeñito en ambos casos). Así el tribunal sabe en todo momento dónde está.
  • No cargues mucho de texto las transparencias; pon la información básica imprescindible (imágenes incluidas), y el resto lo dices de viva voz.
  • Sé astuto: para aquellos puntos que te resulten más complicados de memorizar o explicar, deja en la transparencia la información que te resulta difícil. Vamos, que la transparencia sea como una chuleta (negaré haber dicho esto ante un juez ;))
  • Cuidado con las animaciones, no se trata de que la presentación sea una feria que agobie al tribunal.
  • Transparencias con fondo claro y letras oscuras, o con fondo oscuro y letras claras: como prefieras. Ten en cuenta, de todas formas, dónde vas a leer (Sala de Grado, aula, etc.). Quizás sea más seguro usar la primera opción, que suele dar menos problemas en todas las situaciones.
  • Si durante la presentación muestras algún vídeo de los resultados de tu trabajo, debes hablar mientras se está reproduciendo, por ejemplo comentando aspectos importantes del mismo o cómo se corroboran los resultados teóricos alcanzados. Lo más importante es no quedarse callado mientras el vídeo está corriendo.
  • Es muy normal que el tribunal esté tomando notas mientras estés hablando. No te agobies pensando que están anotando fallos. Lo más normal es que estén recogiendo algunas dudas que les surjan durante tu exposición para acordarse de preguntártelas después (y posiblemente no te las pregunten todas). Y también puede ser que estén anotando las cosas que les han gustado para felicitarte por tu trabajo 🙂
  • Durante la presentación, si te pones nervioso (todos nos ponemos nerviosos, no pasa nada), ten a mano una botellita de agua. Si es botella grande, asegúrate de tener también un vaso.
  • Finaliza la presentación dando las gracias al tribunal e indicando que quedas a su disposición para el turno de preguntas.
  • Deja que los miembros del tribunal acaben de formular sus preguntas sin interrumpirlos (incluso aunque estés deseando contestar porque te requetesabes la respuesta :))
  • Lleva siempre una copia de seguridad de la presentación en un pendrive, porsiaca 🙂


[En español]

Here you can find some little tricks I usually give to my students when the moment comes to defend their Bachelor or Master thesis, though I think they could be useful in any formal presentation. Disclaimer: they are based on my experience on both sides of the story, that is, as speaker and as listener; since it is my own experience, not everybody will agree, so if you do not like them, simply do not use them 🙂

  • Rehearse a lot (I mean it, a lot), including a real demo of your work in case you also show it. Measure exactly how long it takes you to deliver the presentation; it would be great if you can find someone you can torture and rehearse with public.
  • Remember that you have to deliver your presentation looking at the committee, not to the projection screen.
  • The first slide should include the title of your Bachelor/Master thesis, the degree/master program, the author and the advisors.
  • The last slide could be exactly like the first one, so you have a nice background while the examiners ask their questions.
  • Your presentation should follow the same outline that the written dissertation report.
  • If the president of the committee reads aloud the title of your thesis, your name, etc. do not repeat them again when you begin to talk.
  • You should keep an index on the slides (tiny, on the left or at the top), so the committee can keep track of which point of your dissertation you are talking of.
  • Do not text-overload the slides; show only the basic essential information (including images), and explain the supplementary information aloud.
  • Be smart: those points of your presentation that are difficult to remember or explain should be written in your slides. To cut a long story short, the slides should be your cheat sheet (I will deny to have said this in a court ;))
  • Be careful with the animation of your slides: you don’t want to overwhelm the committee with a lot of special effects.
  • Design your slides with light background and dark fonts, or dark background and light fonts, as you wish. Anyway, you should consider the location where you are going to deliver your presentation. Maybe it is safer to choose the first option, that usually adapts to the lightning conditions of every place.
  • If you include a video showing the results of your work, you should talk while the video is playing; for example, you can comment the most relevant points of the video, or how your theoretical results are confirmed. The key point is not to be in silence while the video is still playing.
  • It is quite common that the committee jots some things down while you are talking. Do not get stressed thinking that they are recording your fails. They usually are gathering some notes about the doubts that arise during your dissertation, so they can remember them properly (and perhaps they do not ask all of those doubts). They also could be writing down those things they have liked the most of your work, so they can congratulate you for your achievements 🙂
  • If you are nervous during dissertation (it’s ok, we all get nervous in those situations), get a little bottle of water. If it is a big one, it is fine too, just use also a glass to drink.
  • End your dissertation saying thank you to the committee and saying that you are ready for the questions they might ask you.
  • Do not interrupt the committee members when they are asking you a question (even though you are willing to answer because you are going to nail it :))
  • Always have a backup of the presentation in a pendrive, you know, just in case 🙂

Android Studio + NDK + Windows 7

Facebooktwitterredditpinterestlinkedinmail


[In English]

Estos son los pasos necesarios para instalar Android Studio y NDK sobre Windows 7 (en colaboración con Juan Antonio Fernández Madrigal)

Consideraciones previas

  • No es posible instalarlo en una máquina virtual, ya que el emulador necesita para funcionar virtualización, no disponible dentro de una máquina virtual.
  • Hacen falta bastantes gigas de disco para instalarlo todo, así que hay que asegurarse de tener suficiente espacio.
  • Aquí pueden encontrarse tutoriales para aprender a programar con Android Studio.
  • Bibliografía disponible en Jábega (catálogo de la Biblioteca de la Universidad de Málaga)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino[Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.

Primer paso: instalación de Java

  1. Obtener de el Java jdk 8 (a partir del 7 ya vale), no el jre, que sólo es el entorno de ejecución. En Windows 7 simplemente se baja y ejecuta el instalador .exe. Después es necesario incluir manualmente el path de Java (y de su directorio bin) en la variable de entorno de Windows 7 Path; si alguien no encuentra el path de Java, puede buscar dónde se ha realizado la instalación en Java Mission Control, el programa de configuración de Java que se instala también.

Segundo paso: instalación de Android Studio 

  1. Descargar Android Studio Bundle de la web (para Windows es un ejecutable), ejecutar el .exe y aceptar todo en la Standard Installation.
  2. Una vez instalado, ejecutar Tools -> Android -> SDK Manager  y marcar para instalar las build-tools 21 y la API 21. También es necesario instalar Froyo (2.2. API 8). Esto puede tardar bastante, sobre todo por wifi.
  3. En Configure->Project Defaults->Project structure completar los paths del SDK y de Java. Volver hacia atrás y empezar un nuevo proyecto (Blank Activity) que use la API 8 (Froyo). En el desplegable del rendering de la aplicación, usar la 21 en vez de la 22.
  4. En File -> Settings -> Build, Execution, Deployment -> Build Tools -> Gradle, activar la casilla Offline work (si no, la compilación y ejecución son lentísimas). El problema de la lentitud de Android Studio en Windows 7 y esta solución se comentan en este enlace de Stackoverflow.
  5. En Tools -> Android -> AVD Manager añadir, al Nexus 5 API 22, un Samsung Galaxy con la cámara trasera emulada. Desactivar la opción Use Host GPU. Es especialmente lento el arranque la primera vez y cuando se crea una nueva aplicación y tiene que empezar el indexado.

Tercer paso: instalación de NDK

  1. Este paso es muy sencillo: en Tools ->  Android -> SDK Manager-> SDK Tools -> Android NDK

Desarrollo de aplicaciones


[En español]

These are the steps to follow in order to install Android Studio and NDK on Windows 7 (post written in collaboration with Juan Antonio Fernández Madrigal)

Preliminary requests

  • This software cannot be installed on a virtual machine, since the emulator requires virtualization tools, which are not available in a virtual machines.
  • Both programs are quite demanding in hard drive space: be sure you have enough before you begin the installation.
  • Here you can find several tutorials to learn how to program with Android Studio.
  • Brief list of suggested readings (all of them available at Jábega, the catalogue of the Library of Málaga University)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino [Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.

First step: installing Java

  1. Get Java jdk 8 (though it works from jdk 7); it is important to choose jdk and not jre (jre is just the running environment). For Windows 7 just download and run the .exe file. After that, you have to manually add the path (and its bin folder) to the Windows 7 environment variable Path; if you do not know which is that Java path, you can check it using Java Mission Control, the Java configuration application that has been installed along with Java.

Second step: installing Android Studio

  1. Download Android Studio Bundel from the web (for Windows is an executable file), run the .exe and accept every default option of the Standard Installation.
  2. After that, go to Tools -> Android -> SDK Manager and check for installing the build-tools 21 and API 21. You also have to install Froyo (2.2. API 8). This can take a long time, especially if you are connected through a wifi.
  3. Go to Configure->Project Defaults->Project structure and add the paths of the SDK and Java. Go back and start a new project (Blank Activity) with API 8 (Froyo).  Choose, in the dropdown control  for rendering, version 21 instead of 22.
  4. In File -> Settings -> Build, Execution, Deployment -> Build Tools -> Gradle, check the Offline work box (if not, compilation and execution are painfully slow). This issue about Android Studio being so slow under Windows 7 and its solution are explained in this link at Stackoverflow.
  5. Add, using Tools -> Android -> AVD Manager, a new Samsung Galaxy device with emulated back camera. Uncheck the box Use Host GPU. It is especially slow when you run the emulator for the first time, and when a new app is created and Android Studio has to index from scratch.

Third step: installing NDK

  1. This step is a piece of cake:Tools ->  Android -> SDK Manager-> SDK Tools -> Android NDK

Applications development

 

Arduino + ROS Indigo 32 on Nootrix Virtual Machine

Facebooktwitterredditpinterestlinkedinmail
[In English]
ROS puede conectarse con un Arduino sin problemas. Mi objetivo es comprobar si esta conexión puede hacerse a través de la máquina virtual que proporciona Nootrix, ya que es la que utilizo en clase, puesto que facilita el trabajo con máquinas Windows, y también es más rápida y sencilla de instalar para los alumnos.

En mi máquina tengo instalado Xubuntu 14.04, uso Virtual Box 4.3.10, y la máquina virtual que he instalado es la de  ROS Indigo de 32 bits. Una vez que has instalado la máquina de ROS en Virtual Box, hay que seguir estos pasos:

  • Si tu usuario no está en vboxusers, añádelo  con sudo adduser tu_usuario vboxusers (o sudo usermod -aG vboxusers tu_usuario).
  • Arrancar la máquina virtual y escoger el Arduino de los dispositivos USB en el menú Dispositivos de Virtual Box.
  • Seguir las instrucciones de instalación de Arduino (con catkin); hay una pequeña variación en la máquina Nootrix: el directorio de sketches está en $HOME/Arduino.

Una vez instalados los elementos básicos para trabajar con Arduino en ROS, veamos qué hace falta para ejecutar uno de los ejemplos básicos incluidos en la instalación de Arduino: HelloWorld.ino, en el que el Arduino publica en un topic el  mensaje “hello world!”.

  • Seguir las instrucciones para ejecutar HelloWorld (importante: asegurarse que se han escogido las instrucciones para  Indigo).
  • Para averiguar qué dev utilizar: lsusb, y luego dmesg | grep tty.
  • Ahora hay que dar permisos a ese dispositivo serie, con cd /dev/ y luego sudo chmod 666 ttyACM0.
  • Después, pasamos el programa al Arduino, seleccionando bien el puerto.
  • Abrir un terminal con roscore.
  • Abrir otro terminal con rosrun rosserial_python serial_node.py _port:=/dev/ttyACM0.
  • Abrir otro terminal con rostopic echo chatter (chatter es el nombre del topic usado en el código .ino de ejemplo)
  • Aviso: como ROS está usando rosserial, el Serial Monitor de Arduino no funciona (al menos con Arduino UNO)

El resultado se puede ver en el vídeo al final del post 🙂


[En español]

ROS can be easily connected to an Arduino board. But I wanted to check if this connection could be done with the Nootrix virtual machine, the one I use for my classes since it makes easier to work with ROS if you have Windows machines, and it helps the ROS installation for the students.

My machine runs on Xubuntu 14.04, I use Virtual Box 4.3.10, and the virtual machine I have chosen is ROS Indigo 32 bits. Once you have installed the ROS virtual machine on Virtual Box, you should  follow these steps:

  • If your user does not belong to vboxusers  group, you should add it with sudo adduser your_user vboxusers (or sudo usermod -aG vboxusers your_user).
  • Run the virtual machine and choose Arduino from the USB devices listed on the Virtual Box Devices menu.
  • Go to  Arduino installation and follow those steps (use catkin); there is a sligth modification on the Nootrix machine: the sketches folder is stored in $HOME/Arduino.

Now we have all the basic elements to work with Arduino under ROS; let’s see what else we need to run one of the basic examples included with the Arduino installation: HelloWorld.ino, which makes Arduino publish a “hello world!” message in a topic.

  • Follow these steps to run  HelloWorld (it is important to choose the proper instructions, i.e., the Indigo ones).
  • In order to know which dev to use: lsusb, and then dmesg | grep tty.
  • Now you have to grant permissions to that serial device: cd /dev/ and then sudo chmod 666 ttyACM0.
  • Then you upload the program to the Arduino, choosing the right port.
  • Open a terminal and run roscore.
  • Open another terminal and run rosrun rosserial_python serial_node.py _port:=/dev/ttyACM0.
  • Open another terminal and run rostopic echo chatter (chatter is the name of the topic used in the .ino example code)
  • Warning: since ROS is using rosserial, Arduino’s Serial Monitor does not work (at least with Arduino UNO)

And voilà, here we have our Arduino publishing in a ROS topic 🙂

Arduino + Autodesk123

FacebooktwitterredditpinterestlinkedinmailHe descubierto Autodesk 123D circuits Electronics Labs, una aplicación en la nube donde se pueden implantar, programar y simular circuitos electrónicos en protoboard usando diferentes elementos, como Arduino. Aquí va un pequeño ejemplo de lo que se puede hacer.

I have discovered Autodesk 123D circuits Electronic Labs, a cloud application which allows to implement, program and simulate electronics circuits on a breadboard using different elements, like Arduino. Here you have a small example of what can be done.

Android Studio + NDK + Xubuntu 14.04

Facebooktwitterredditpinterestlinkedinmail
[In English]

Estos son los pasos necesarios para instalar Android Studio y NDK sobre Xubuntu 14.04 (en colaboración con Juan Antonio Fernández Madrigal)

Consideraciones previas

  • No es posible instalarlo en una máquina virtual, ya que el emulador necesita para funcionar virtualización, no disponible dentro de una máquina virtual.
  • Hacen falta bastantes gigas de disco para instalarlo todo, así que hay que asegurarse de tener suficiente espacio.
  • Aquí pueden encontrarse tutoriales para aprender a programar con Android Studio.
  • Bibliografía disponible en Jábega (catálogo de la Biblioteca de la Universidad de Málaga)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino [Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.

Primer paso: instalación de JAVA

  1. Bajarse de Sun el java jdk (a partir del 7 ya vale); no el jre, que sólo es el entorno de ejecución.
  2. Crear un directorio para el jdk  y descomprimir
  3. Si queremos activar los applets de java en firefox, hay que crear en donde firefox tiene los plugins (/usr/lib/mozilla/plugins) un enlace simbólico al plugin que trae el jdk para eso, que está en /dirjdk/jre/lib/amd64/libnpjp2.so. Luego se rearranca el firefox y se mira en about:plugins. También se puede ejecutar el programa jcontrol del directorio bin de java para establecer los permisos de seguridad que permiten ejecutar applets de algún sitio concreto.
  4. Añadir al final de ~/.bashrc las siguientes líneas, para que así Java quede visible para el Android Studio. Después, cerrar y abrir la consola y hacer echo $PATH y echo $JAVA_HOME para comprobar que todo ha ido bien:
    PATH=$PATH:/directoriodejdkbin
    JAVA_HOME=/directoriodejdk
    export PATH
    export JAVA_HOME

Segundo paso: instalación de Android Studio 

  1. Bajar el IDE completo (por ejemplo, el fichero android-studio-ide-141.1903250-linux.zip) de la web.
  2. Realizar la instalación siguiendo estas instrucciones.
    – Si Java no está bien instalado (ver Primer paso), al ejecutar en el directorio bin el comando ./studio.sh, aparece el mensaje “JDK Required: ‘tools.jar’ seems to be not in Studio classpath. Please ensure JAVA_HOME points to JDK rather than JRE.”
    – En Xubuntu me ha aparecido un mensaje de error debido al demonio iBus; en esta dirección se dan posibles soluciones al problema.
    – Escoger la instalación estándar.
    – Se da la opción de KVM para acelerar la VM (en mi caso, no la he activado porque aparentemente podría afectar a Virtual Box y no he querido investigar más; más info aquí)
  3. Cuando se abra el Android Studio por primera vez, escoger la opción Configure para definir el path del SDK y el JDK. Este paso también puede hacerse con posterioridad a la instalación: abrir Android Studio, escoger File-> Other settings -> Default Project Structure. El SDK está en un directorio que se ha debido crear en la configuración; el JDK, en el directorio donde se hizo la descarga según se explicó anteriomente (ver Primer paso).
  4. Para crear un proyecto:
    – Versión mínima escogida para teléfono y tablet:  Froyo
    – Tipo de actividad: Blank activity

Tercer paso: instalación de NDK

  1. Descargar el fichero adecuado y seguir estas instrucciones.
  2. Mover el directorio descomprimido a donde se quiera, y actualizar el path
    PATH=$PATH:/directoriondk
    export PATH

Desarrollo de aplicaciones

[ACTUALIZACIÓN]

He repetido la instalación en un Ubuntu Mate 15.04 vivid, y hay varios cambios respecto a la instalación comentada anteriormente.

  • Al instalar, aparece el error Unable to run mksdcard. La solución puede encontrarse en este enlace de Blascarr.
  • La API 2.2 (Froyo) viene desinstalada por defecto, así que antes de crear una aplicación nueva hay que instalarla usando Tools -> Android -> SDK Manager.
  • Respecto a la emulación, dos puntos a tener en cuenta:
    • He necesitado dar permisos a la carpeta system_images del directorio de instalación de SDK.
    • He intentado crear un AVD usando una imagen de 64 bits, pero necesita la KVM y como, aparentemente, KVM da problemas con Virtual Box, he preferido no instalarla. Consecuencia: la emulación va lentísima 🙁


[En español]

These are the steps to follow in order to install Android Studio and NDK on Xubuntu 14.04 (post written in collaboration with Juan Antonio Fernández Madrigal)

Preliminary requests

  • This software cannot be installed on a virtual machine, since the emulator requires virtualization tools, which are not available in a virtual machines.
  • Both programs are quite demanding in hard drive space: be sure you have enough before you begin the installation.
  • Here you can find several tutorials to learn how to program with Android Studio.
  • Brief list of suggested readings (all of them available at Jábega, the catalogue of the Library of Málaga University)
    • El Gran libro de Android : [actualizado a la versión KitKat y Android L Preview] / Jesús Tomás Gironés
    • Building Android apps / Mike McGrath
    • Manual imprescindible de desarrollo de aplicaciones para Android. Edición 2015/ Joan Ribas Lequerica
    • Profesional Android open accesory programing with Arduino [Recurso electrónico]/ Andreas Göransson,
    • Android Studio application development [Recurso electrónico] / Belén Cruz Zapata.


First step: installing Java

  1. Download java jdk from Sun (jdk 7 or later); it is important to choose jdk and not jre (jre is just the running environment).
  2. Create a folder and unzip (or untar :)) the Java jdk.
  3. If you wisht to activate the java applets in firefox, you have to create in the folder where firefox stores its plugins, a symbolic link to the plugin that the jdk offers, which is stored in /jdkfolder/jre/lib/amd64/libnpjp2.so. Then, restore firefox and check about:plugins. You can also run jcontrol in your Java bin folder, so you can set the permissions that allow to run applets from a known location.
  4. Append, at the end of ~/.bashrc, these lines, so Java can be available for Android Studio. Then, close and open again the terminal, and type echo $PATH and echo $JAVA_HOME in order to check that everything is ok:
    PATH=$PATH:/jdkbinfolder
    JAVA_HOME=/jdkfolder
    export PATH
    export JAVA_HOME

Second step: installing Android Studio

  1. Download the IDE (i.e., android-studio-ide-141.1903250-linux.zip file) from the web.
  2. Install the software according to this guideline.
    – If Java is not properly installed (see First step), when you run ./studio.sh in the bin folder, you get this message “JDK Required: ‘tools.jar’ seems to be not in Studio classpath. Please ensure JAVA_HOME points to JDK rather than JRE.”
    – Under Xubuntu I also get an error message due to the iBus daemon; this link offers several solutions to this problem.
    – Choose standard installation.
    – You can choose KVM in order to accelerating the VM (I have rejected this option, since -apparently- it could have an influence on Virtual Box, and I did not want to risk my virtual machine; more info here)
  3. When Android Studio opens for the first time, choose the Configure option so you can define the paths for SDK and JDK. This step can also be done after installation is completed: open Android Studio, then choose File-> Other settings -> Default Project Structure. The SDK is in a folder created in the configuration process; the JDK should be stored in the folder where you downloaded it (according to First step explanations).
  4. If you want to create a project:
    – Minimum version for phone and tablet: Froyo
    – Activity type: Blank activity

Third step: installing NDK

  1.  Download the right file and follow these instructions.
  2. Move the unzipped folder to your desired location, and update the path
    PATH=$PATH:/ndkfolder
    export PATH

Applications development

[UPDATE]

I have installed the Ubuntu Mate 15.04 vivid, and there are some changes from the previously commented installation.

  • During the installation process, an Unable to run mksdcard error arises. You can fin the solution in this link at Blascarr [in Spanish].
  • API 2.2 (Froyo) is not installed by default, so prior to create a new app you have to install it with Tools -> Android -> SDK Manager.
  • Regarding emulation, two aspects should be taken into account:
    • I had to grant permissions to the folder system_images inside the SDK installation folder.
    • I tried to create a new AVD with a 64 bits image, but it requires KVM and sice, apparently, KVM is not compatible with Virtual Box, I choosed not to install that image. Consecuence: emulation is very very slow 🙁

LabVIEW Datalogging and Supervisory Control + Arduino

FacebooktwitterredditpinterestlinkedinmailPor fin he vuelto al blog. Aquí tenéis una de las razones de mi ausencia: he estado trasteando con el módulo Datalogging and Supervisory Control de LabVIEW (version 2009) para diseñar sistemas SCADA, integrando también un Arduino. ¡¡Feliz Semana Santa :)!!

Finally, I have managed to get back to blogging. Here you have one of the reasons of my leave: I have been diving into LabVIEW’s Datalogging and Supervisory Control module (2009 version) in order to design SCADA systems, using an Arduino too. Have a happy Easter :)!!