domingo, 19 de febrero de 2012

Kamehameha


Hoy, para variar un poco los temas del blog, les platicaré sobre Kamehameha. Y para los fans de Dragon Ball que llegaron por el título del post, siento decirles que terminarán un tanto decepcionados, pues no me refiero a ese kamehameha, a.k.a, la onda destructiva de la tortuga.

A quien sí me refiero es (platillos y bombos por favor!) a Kamehameha I, o Kamehameha El Grande, el primer Rey de Hawaii, quien se encargó de unificar las islas y de crear una serie de relaciones que le permitirían a Hawaii permanecer independiente.

Entre sus logros, llegó a juntar un ejército de 10,000 soldados, cuando entre todas las islas Hawaiianas en ese tiempo (1795) no llegaba a los 250,000 personas. Con esos soldados fué invadiendo isla tras isla, hasta que las conquistó a todas excepto a la última, que al ver la cantidad de soldados y lanchas (sí, lanchas!), decidió anexarse al reino.

Luego, una vez unificadas todas las islas (nota, son 8, al menos las principales), se las ingenió para que los imperios coloniales de ese entonces, europeos ellos, no lograran anexarse su reino: determinó que nadie que no fuera hawaiano podría comprar terrenos en las islas. Sin embargo, no cerró las islas al comercio, sino que unificó el sistema legal y los impuestos, y con ellos comenzó a comerciar con Europa y Estados Unidos, lo que permitió hacer que el comercio en las islas floreciera aún más.

Y finalmente, de su historia bélica, le legó algo importantísimo para cualquier movimiento armado posterior: una ley conocida como "ley del remo astillado" o Mamalahoa, que, además de tener una historia bastante curiosa detrás, básicamente le da protección legal a los civiles en zonas de combate. Fué la primera ley en la historia que procuró el bienestar de los no combatientes durante un conflicto armado.

En conclusión, si estuviera él vivo, yo lo lanzaba para presidente. Pero como no, Dr. Mono para presidente.

sábado, 11 de febrero de 2012

Are you ready for Talentism?

Ayer, viendo el desierto de Google+, topé con un post bastante interesante, originalmente hecho por Tom Reilly y compartido por uno de mis contactos, Antonio Guzmán. Este habla sobre las nuevas necesidades económicas, tema a tratar en la próxima reunión anual del World Economic Forum.

Entre otras cosas, menciona que, con la crisis económica y el estado actual de la industria, en la que cada vez se requiere menos personal para ser más productivos, a nosotros estudiantes que seremos los nuevos profesionistas en muy poco tiempo, se nos presenta un panorama un tanto gris en el importantísimo asunto del empleo. ¿Qué hacer cuando las empresas ya no buscan tantas personas como antes, y cuando la competencia por esos puestos alcanza niveles de locura?

Se requiere un nuevo modelo de empleo. No es sostenible la situación actual, y seremos nosotros quienes tendremos que dar el salto hacia el nuevo paradigma. Dado que ellos pueden decirlo mucho mejor que yo, anexo una parte del documento (encontrado en http://www.weforum.org/content/great-transformation-shaping-new-models):


"The key to mitigating a catastrophic situation is to provide young people with the capability to create their own jobs: to move from the pure concept of unemployment to the concept of micro-entrepreneurship. This will require fundamental changes in educational systems, nurturing a societal spirit of entrepreneurial risk-taking, allowing true gender equality – to integrate the other half of hidden talents – and making innovation and the support of innovation a key imperative in public and private life. The success of any national and business model for competitiveness in the future will be less based on capital and much more based on talent. I define this transition as moving from capitalism to “talentism”."

¿Te sientes listo para el cambio?

miércoles, 8 de febrero de 2012

Software y Mecatrónica.

Me gustaría hoy tratar un tema que es de especial interés para mí: la carrera de Ingeniería Mecatrónica.
Tal vez muchos de ustedes, lectores, no conozcan lo que es eso, o piensen que sólo se trata de robots. Para los que sí saben, enhorabuena, mas les contaré algo que tal vez no conozcan.


Al ritmo en el que los nuevos dispositivos mecatrónicos van encontrando un lugar en las industrias y en los productos que consumimos en la actualidad, se vuelve cada vez más importante la velocidad de desarrollo del producto, y por supuesto, el conocimiento y la práctica de metodologías de diseño que permitan ahorrar tiempo y esfuerzo del desarrollador. Ya no se trata de reinventar la rueda cada vez que se diseña algo, sino el realizar el mejor diseño inicial posible y continuar construyendo sobre lo antes hecho.


Esto quiere decir que nuestros primeros diseños, a pesar de ser (quizás) hechos sin experiencia previa, deben ser cada vez más flexibles, fácilmente mantenibles y escalables. Asimismo, la participación de los sistemas de información en procesos y productos mecatrónicos es cada vez mayor, por lo que las metodologías que se aplican en esa área también deben comenzarse a implementar en la mecatrónica. Así que, partiendo un poco de mi experiencia en el desarrollo de software, trataré de analizar el diseño y construcción de un dispositivo mecatrónico de acuerdo a principios de diseño que faciliten eso.


Primeramente, comenzaremos definiendo los conceptos de diseño de software y sus analogías en el contexto mecatrónico.


Inicialmente se tiene la capa de infraestructura en software. Esta usualmente se refiere a la última capa del sistema en la que se lleva a cabo operaciones de persistencia de datos, es decir, se guarda y obtiene la información contenida en las variables del sistema, ya sea en un sistema de archivos o en una base de datos. Esto podríamos verlo en un dispositivo mecatrónico como la última capa posible de nuestro sistema, los que nos permitirían guardar y obtener información acerca de nuestro dispositivo. En otras palabras, serían los sensores y actuadores de nuestro dispositivo. Viéndolo así, un sensor nos permitiría obtener información mientras que el actuador permitiría "guardar" una variable de nuestro sistema. 


A continuación, se encuentra una capa a veces llamada dominio y otras veces llamada lógica de negocios. Es en esta capa donde se encuentran las clases dedicadas a hacer que se haga algo en el sistema. En otras palabras, si hablamos de un sistema de administración de empleados, en esta capa se deben implementar las cuestiones que permiten administrar empleados, cuestiones que si bien están ligadas con la capa de infraestructura, no dependen de ésta. Por ejemplo, no nos importaría cómo están guardados los datos, sino el saber que si debemos trabajar con ellos, estarán estos disponibles de cierta manera (e.g. como objetos o instancias de una clase Empleado). En un dispositivo mecatrónico encontramos un gran parecido, por ejemplo: ¿qué tal si, ante una petición expresa de un cliente se requiere instalar un sensor distinto al de todos los demás productos del mismo modelo? Sería necesario reprogramar todo para asegurarse de que funcione. En cambio, si se diseña la programación del producto o proceso de tal manera que sólo sea necesario modificar la información concreta del sensor, sin modificar lo que otras capas más abstractas esperan de él, el mantenimiento y/o desarrollo de nuevas versiones del producto se vuelve increíblemente sencilla.


Siguiendo, podemos definir una capa llamada de aplicación. Es en esta capa donde se introduce el concepto de API (Application Programming Interface), concepto fácilmente resumible: es una serie de librerías que implementan funciones útiles para el desarrollo de sistemas basados en ella. Un ejemplo son las Collections de Java. Éstas son una serie de estructuras (muy) útiles para el desarrollo de sistemas, como listas ligadas, pilas, colas, entre otros. Esto le permite al desarrollador pasar menos tiempo implementando estructuras de datos necesarias para su programa y más tiempo pensando en el correcto modelado, diseño y lógica de su aplicación. La idea detrás de estas API es ofrecer una interfaz fácil de usar para obtener acceso a los datos del sistema, con el objetivo secundario de permitir a terceros construir sus aplicaciones con los datos de tu sistema embebidos (como el API de Facebook, que te permite crear tus "aplicaciones" en Facebook mismo, utilizando los datos que Facebook tenga sobre tus usuarios), o crear aplicaciones para tu sistema, como versiones para móviles de redes sociales, como Twitter. En un sistema mecatrónico, la capa de aplicación es una capa invisible: existe sólo como software, usualmente en el controlador del sistema (que no sólo funciona como intermediario, usualmente tiene también las funciones propias de un controlador, con su propia ley de control). Al final de esta entrada me ocuparé de un ejemplo concreto y bien conocido de la mecatrónica y se disectará a fin de encontrar las diversas capas de las que les hablo.


Finalmente, se encuentra la capa más conocida (debido a que es la capa visible después de todo el proceso), la interfaz de usuario. La función de esta capa es fácilmente intuida: trata sobre la manera de presentar la información del sistema al usuario y en ocasiones permitir que éste interfiera en el funcionamiento del sistema. En otras, la interfaz es la única manera de que el sistema funcione, es decir, sin interfaz el sistema no está completo, es inútil. En la mecatrónica, nos encontramos con una flexibilidad inmensa al implementar una interfaz. Como ejemplos, fácilmente podemos pensar en LED's indicadores, displays de 7 segmentos, LCD's, pantallas sensibles al tacto, luces, sonidos, movimientos, entre otros. Todos los anteriores muestran información sobre el proceso o producto al usuario, pero no permiten modificar la operación de éste. Sin embargo, con interfaces como joysticks, botones, switches, controles (como los de Wii), interfaces basadas en la comunicación con otros dispositivos como celulares, tablets y computadores, entre otras, usualmente nos es posible modificar el comportamiento de nuestro dispositivo o proceso mecatrónico. Esta capa entonces no se preocupará de qué sensores, actuadores, microcontrolador o elementos en general contenga nuestra creación, sino que sólo será el puente entre el usuario y el API.


Entonces, ya sabemos cómo podemos dividir nuestro producto o software y en qué capas usualmente conviene hacerlo. Ahora veámoslo concretamente en el siguiente caso: un robot móvil.
Al tener un robot móvil nos encontramos con diversas cuestiones: peso, volumen, instrumentación, procesamiento, entre otras. Así que apliquemos el enfoque de capas al proceso de diseño.
Si lo que buscamos es un software con las características previamente mencionadas (flexibilidad, facilidad de manutención, facilidad para añadir nuevas funciones, etc) para el robot, entonces debemos pensarlo como una serie de capas que se comunicarán entre sí. 



  • Primero: capa de infraestructura. Requeriremos crear métodos o funciones que nos permitan mover nuestros motores. No importará qué motor usemos al final del proceso si éstas funciones son bien diseñadas. Una función así sería aquella que, con sólo requerir una velocidad de entrada, fuera capaz de calcular la frecuencia del pulso necesario para lograrla, teniendo en cuenta dentro de la misma función el tipo de motor que se eligió, y las limitantes de éste. Lo mismo sucede con los sensores, si al inicio se decide utiliza un sensor analógico cuya salida se encuentre entre los 0 y 5 V, si después lo cambiamos por uno cuya salida sea distinta, sólo será necesario modificar la función que trate con él. Un ejemplo, al utilizar un sensor de temperatura analógico tendremos una salida entre un valor mínimo correspondiente con la menor lectura posible del sensor y el valor máximo, que corresponde a la mayor temperatura que permite medir el sensor. Una función abstracta que nos sea útil es aquella que al llamarla nos regresaría el valor de la temperatura en grados celsuis. Para quien la llama no le importa si el valor máximo es 5 V o si es 3 V, porque la lógica detrás de la conversión se encuentra en la función, por lo que podríamos cambiar el sensor y sólo modificar ésta.
  • Una vez construida la interfaz entre el software y el hardware, pasemos a la lógica de negocios. Ahora será necesario para nosotros construir funciones que estén más relacionadas con la actividad a realizar. En este caso, podríamos definir una función mover, que al ser llamada con una velocidad y dirección como argumentos, llamaría a su vez a las funciones de motores de la capa de infraestructura de tal manera que nos permitiera avanzar en la dirección deseada con la velocidad deseada, sin preocuparse de qué motor se utiliza. 
  • Posteriormente, construiríamos nuestra RobotAPI. Ésta constaría de todas aquellas funciones que nos permitieran saber el estado del sistema, en este caso las lecturas (útiles) de los sensores, aquellas que nos permitieran modificar algún parámetro del sistema, por ejemplo, a qué región de lecturas de un sensor infrarojo corresponde un color blanco y a qué un color negro. Finalmente, están aquellas que nos permitieran realizar alguna acción, como la anteriormente definida, mover.
  • Para terminar, definimos qué tipo y protocolo de comunicación se tendrá con el mundo exterior (RF, Bluetooth, WiFi, RS232, USB), y construimos una interfaz en un dispositivo compatible con dicho protocolo para observar el proceso o dispositivo trabajando, y si es el caso, modificar su operación.
¿Cuáles son los beneficios de hacerlo así? Si se trata de un ejercicio académico que no recibirá mayor atención después de entregado, entiendo que sea difícil encontrarle utilidad al procedimiento mencionado. En cambio, si se trata de un sistema de manufactura, es importante que así sea, puesto que no se trata de un sistema desechable, sino de uno cuyo desempeño debe ser medido al segundo y debe permanecer operando continuamente el mayor tiempo posible, en un esquema a largo plazo donde deben contemplarse repuestos de máquinas, máquinas nuevas y distintas a las que fueron consideradas en el proceso de diseño, y sobre todo, aquellas situaciones imprevistas.

¿Qué piensan ustedes?