En el anterior artículo hablaba de cómo hacer un robot con el que se pueda hacer vigilancias o inspecciones. El problema que tenía era que la cámara no mostraba las imágenes en tiempo real.
Aprovechando que la fundación Raspberry Pi ha sacado a la venta la nueva cámara que se acopla al dispositivo a través de su propio puerto, he adquirido una para hacer pruebas con ella y ver si era capaz de conseguir la ansiada retransmisión (o streaming) en directo.
Después de varias pruebas con vlc y el protocolo rtsp sólo había conseguido un flujo de imágenes con un retraso de 1 o 2 segundos, pero esto era insuficiente. Por suerte me encontré con este artículo que hablaba de hacerlo con netcat y mplayer. Configurando bien los parámetros se puede tener una secuencia de vídeo muy fluida, o lo que es lo mismo, streaming en tiempo real.
Primero desde el ordenador (ya sea linux, Mac OS o Windows -con este netcat-) ejecuto el siguiente comando:
Mac OS
nc -l5001|mplayer-fps60-cache1024 -
Linux y Windows:
nc -l-p5001|mplayer-fps60-cache1024 -
Es significado es que netcat escucha por el puerto 5001 y todo lo que reciba se lo pasará al mplayer por la entrada estándar. MPlayer espera una retransmisión de 60 marcos por segundo y guardará el contenido en un buffer de un mega.
Después desde la Raspberry Pi con el sistema operativo Raspbian ejecuto el siguiente comando:
El programa raspivid envía durante 1000 segundos una imágen de 640×480 píxeles volteada horizontal y verticalmente por la salida estándar y sin mostrar la previsualización. El netcat lo envía a la ip 192.168.1.37 por el puerto 5001.
El resultado es este:
Tanto el ordenador como la Raspberry PI están conectados al router y funciona bastante bien, pero para hacerlo mejor lo ideal sería conectar ambos por wifi mediante ad-hoc.
¿Quién no ha tenido alguna vez la necesidad de poder ver nuestra casa desde otro lugar (oficina, hotel, otra casa, etc), o poder hacer inspección de tuberías, respiraderos o sitios inaccesibles? La idea que planteo en este artículo es la de un coche teledirigido al que podemos manejar remotamente mediante wifi y que veamos por donde va.
El funcionamiento es sencillo: Por un lado con un programa en python que se ejecuta en la raspberry pi hacemos un servidor que reciba los comandos por tcp/ip, estos son enviados mediante el puerto serie de la raspberry pi al puerto serie del arduino, que será el encargado de manejar la motorshield para mover el conjunto. Por otro lado en la propia Raspberry Pi hacemos streaming de vídeo para que podamos ver a través de su webcam remotamente.
Todo está alimentado con una batería Lipo 7,4 V. (2S) de 1000 mAh. Por un lado está conectado directamente a arduino y por otro a un regulador UBEC para alimentar a la raspberry pi a través de los pines GPIO de 5v y GND.
La comunicación entre la rasbperry Pi y arduino se hace simplemente con un cable, ya que no es necesario ninguna protección al ser el pin TX de la raspberry pi el que se conecta al pin RX de arduino, y por tanto no hay riesgo con los voltajes diferentes.
El programa de Arduino es bastante simple, sólo comprueba si existe un byte en el puerto serie y si lo hay lo interpreta para saber qué movimiento hay que hacer con los motores. Se parte del byte 0×30 (0 en ASCII) y se comprueban sus bits:
Si el bit 0 está activado el coche va hacia delante.
Si el bit 1 está activado el coche va hacia atrás.
Si los bits anteriores están desactivados entonces el coche no se mueve.
Si el bit 2 está activado gira las ruedas a la izquierda.
Si el bit 3 está activado gira las ruedas a la derecha.
Si los bits anteriores están desactivados entonces la dirección el coche permanece recta.
int dirA =12;// sentidoint dirB =13;// direccion int speedA =10;// velocidad del motorint speedB =11;// parada o encendido de la direcciónint velocidad =150;// PWM del motor de tracción// El robot va hacia atrásvoid atras(){
digitalWrite (dirA, HIGH);}// El robot va hacia alantevoid alante(){
digitalWrite (dirA, LOW);}// El robot tuerce a la izquierdavoid izquierda(){
digitalWrite (dirB, LOW);}// El robot tuerce a la derechavoid derecha(){
digitalWrite (dirB, HIGH);}void setup(){// Configuración de las comunicaciones
Serial.begin(115200);// Configuración de los pines de la motorshield
pinMode (dirA, OUTPUT);
pinMode (dirB, OUTPUT);
pinMode (speedA, OUTPUT);
pinMode (speedB, OUTPUT);
digitalWrite(speedA, LOW);
digitalWrite(speedB, LOW);}void loop(){while(Serial.available()){int caracter = Serial.read();
caracter -= 0x30;if(caracter ==0){
digitalWrite(speedA, LOW);
digitalWrite(speedB, LOW);}else{if(caracter &1){
analogWrite(speedA, velocidad);
alante();}elseif(caracter &2){
analogWrite(speedA, velocidad);
atras();}elseif((caracter &3)==0){
digitalWrite(speedA, LOW);}if(caracter &4){
digitalWrite(speedB, HIGH);
izquierda();}elseif(caracter &8){
digitalWrite(speedB, HIGH);
derecha();}elseif((caracter &12)==0){
digitalWrite(speedB, LOW);}}}}
En el lado de la Raspberry Pi hay que instalar primero varias cosas:
Después hay que dar permisos de lectura y escritura al puerto serie:
sudochmod a+rw /dev/ttyAMA0
A continuación creamos un fichero llamado servidor.py:
importsocketimport serial
ser=serial.Serial('/dev/ttyAMA0',115200)
host =''
port =1976
backlog =5
s =socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.bind((host,port))
s.listen(backlog)while1:
ser.write("0")print"se espera una conexion"
client, address = s.accept()print"conectado " + address[0]while1:
data = client.recv(1)if data =='':
breakelse:
ser.write(data)
Este programa python se encarga de crear un socket tcp/ip que escucha por el puerto 1976 , cuando alguien se conecta a este puerto entonces permanece a la espera de recibir los bytes que posteriormente enviará a Arduino a través del puerto serie.
Finalmente crearemos un fichero llamado webcam.sh con el siguiente contenido (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
Este programa shell arrancará un servidor de streaming con GStreamer. De momento GStreamer es el software que conozco que funciona más rápido enviando imágenes con un retardo de 2 segundos, ffmpeg tenía un retardo de hasta ¡¡¡ 10 segundos !!!. La idea la cogí de aquí.
Ahora que ya tenemos lo necesario en nuestra parte del coche, necesitamos configurar el router para redirigir los puertos 22, 1976 y 5000 hacía la ip que tenga la Raspberry Pi.
Desde el ordenador remoto necesitaremos tener el programa VLC para el recibir el streaming, un cliente de ssh (en windows el mejor es el putty) y Processing para enviar los comandos.
Los pasos para hacer que nuestro sistema de televigilancia son los siguientes:
Conectar mediante ssh a la raspberry pi y ejecutar el comando:
sh webcam.sh
Abrir otra sesión de ssh y ejecutar el comando:
python servidor.py
Arrancar VLC y abrir una ubicación de red poniendo la siguiente línea, con esto podremos ver lo que hay frente a la webcam (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
tcp://192.168.1.133:5000
Arrancar el Processing con el siguiente programa y ejecutarlo (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
importprocessing.net.*;
Client myClient;int valor;void setup(){
size(200, 200);
myClient =new Client(this, "192.168.1.133", 1976);
valor =0;}void draw(){}void keyReleased(){if(key == CODED){if(keyCode == UP){
valor &= 0xFFFFFFFE;}elseif(keyCode == DOWN){
valor &= 0xFFFFFFFD;}elseif(keyCode == LEFT){
valor &= 0xFFFFFFFB;}elseif(keyCode == RIGHT){
valor &= 0xFFFFFFF7;}
myClient.write(valor + 0x30);}}void keyPressed(){if(key == CODED){if(keyCode == UP){
valor |=1;}elseif(keyCode == DOWN){
valor |=2;}elseif(keyCode == LEFT){
valor |=4;}elseif(keyCode == RIGHT){
valor |=8;}
myClient.write(valor + 0x30);}}
Si todo ha ido bien, ponemos la ventana de processing que nos ha abierto como activa cuando hemos lanzado el programa y pulsamos los botones de los cursores del teclado, momento en el cual veremos a través de la webcam (o en local si lo tenemos enfrente) cómo nos desplazamos.
Hace algún tiempo leí un artículo sobre un concurso para crear un robot con un coste de 10$ para el aprendizaje de robótica en escuelas con un coste admisible. Este concurso es el reto AFRON.
Así que me pareció una buena idea participar. Se me ocurrió que un robot muy simple de hacer pero que es un buen punto de partida para aprender es un seguidor de luz, donde los sensores del robot están buscando si hay un foco luz y cuando lo encuentran se dirigen hacia el. Me puse a buscar los componentes, a construir el robot y al final he terminado a L.I.O.S. (Light input output system):
Como se puede ver en el vídeo, las ruedas y el chasis son de cartón de una caja reciclada. Aunque no se aprecie, los sensores son LDR, los motores son dos servos trucados para rotación continua, el cerebro es un microcontrolador PIC 12F683, tiene dos diodos led para indicar el estado y una batería lipo de 3,7V. y 130 mAh para alimentar el sistema.
Funcionamiento:
Nada más enchufar la batería los leds parpadean varias veces. Hay dos LDR que el microcontrolador está comprobando constantemente; si este detecta que en uno de ellos hay una intensidad de luz grande, entonces enciende el led del lado del LDR y activa el servo del lado contrario (si la luz está a la derecha, entonces es la rueda izquierda la que tiene que moverse y viceversa); si ambos sensores detectan luz entonces los dos led se encienden y los dos motores se activan para ir recto; si no detecta suficiente luz entonces permanece parado y los leds apagados.
Consumo
En resposo consume 23 mA.
Cuando sigue una luz puede consumir hasta 300 mA.
La hoja del cutter es afilada, tener cuidado de no cortarse.
La aguja es muy fina, tener cuidado de no pincharse.
El pegamento es muy fuerte, tener cuidado de que no entre en contacto con los ojos y/o la piel.
La termocola está muy caliente, tener cuidado de no tocarla.
El soldador está muy caliente, tener cuidado de no tocarlo, de no ponerlo en contacto con el cartón y de evitar respirar el humo de la soldadura.
La batería lipo no debe cortocircuitarse, ni sobrecargarse por encima de 4,2V. ni descargarse por debajo de 3V.
Servos
Los servos contienen electrónica para manejar su sentido de rotación y tienen engranajes para aumentar su fuerza de tracción, sin embargo sólo pueden rotar 180º, por lo que vamos a modificarlos para que su rotación sea continua como la de cualquier motor.
Lo primero es desmontarlos extrayendo los 4 tornillos de su base y separar las tapas inferior y superior:
Después hay que extraer los engranajes. Uno de ellos contiene una pestaña para que haga de tope y no avance más (marcado con un circulo rojo):
Así es como queda al cortarla:
Por otro lado tenemos el potenciómetro. Aquí debemos desoldar los cables (las flechas verdes) y romper la pared que contiene las dos pestañas que también hacen tope (las fechas rojas):
Así es como quedaría la pared que comentaba:
A continuación debemos soldar las dos resistencias de 10KΩ formando un divisor resistivo en los cables que habíamos desoldado antes (el cable blanco entre las dos resistencias). Para aislar los contactos poner tubo termoretráctil:
También aislar el extremo con tubo termoretráctil:
Finalmente unir todos los engranajes de nuevo, meter la electrónica, poner las tapas y atornillarlas:
Chásis y ruedas
Imprimir en papel esta plantilla en DXF a escala 1:1 (yo he usado el programa de software libre LibreCad):
Pegar el papel con cinta adhesiva al cartón. Agujerear los círculos pequeños con una aguja y cortar las líneas con un cutter:
A continuación poner la aguja en el agujero de una rueda, poner pegamento en el brazo alargado de un servo e introducir el agujero central de este por la aguja hasta pegarlo a la rueda. Repetir el proceso con la otra rueda:
Quitar la pegatina del lateral del servo, poner pegamento en ese lateral y pegarlo en el extremo superior izquierdo de la superficie grande de cartón. Repetir el proceso en el otro lado con el otro servo:
Cortar levemente la superficie pequeña de cartón por el primer tercio, poner pegamento y adherirla a la incisión hecha anteriormente en la superficie grande de cartón (según la plantilla). Colocar las dos ruedas en los ejes del servo:
Agujerear 4 orificios entre los servos, introducir desde abajo los LDR, girarlos 30 grados desde el centro y pegarlos con termocola. Hacer dos orificios a cada lado, introducir desde abajo los diodos led y pegarlos con termocola:
Electrónica
Este es el esquema electrónico:
LDR
Soldar una de las patillas de cada LDR a VCC.
Soldar la otra patilla de cada LDR a un extremo de una resistencia de 10KΩ
Desde la anterior unión izquierda soldar un cable hasta el pin 7 del zócalo y poner tubo termoretráctil.
Desde la anterior unión derecha soldar un cable en hasta el pin 6 del zócalo y poner tubo termoretráctil.
Soldar el otro extremo de cada resistencia a GND.
Pegar las resistencias a la base con termocola.
SERVO
Pelar los cables y soldar el rojo a VCC y el marrón a GND de cada servo.
Soldar el cable naranja del servo izquierdo al pin 3 del zócalo y poner tubo termoretráctil.
Soldar el cable naranja del servo derecho al pin 2 del zócalo y poner tubo termoretráctil.
LED
Soldar un extremo de una resistencia de 180Ω a VCC.
Soldar el otro extremo al de otra resistencia de 180Ω.
Desde la anterior unión soldar un cable hacia la patilla del ánodo del led derecho.
Desde la anterior unión soldar un cable hacia la patilla del cátodo del led izquierdo.
Soldar el extremo restante de la segunda resistencia a GND.
Pegar las resistencias a la base con termocola.
Desde el cátodo del led derecho soldar un cable hacia el ánodo del led izquierdo.
Desde la anterior unión soldar un cable hacia el pin 5 del zócalo y poner tubo termoretráctil.
PIC
Soldar el pin 1 del zócalo a VCC y poner tubo termoretráctil.
Soldar el pin 8 del zócalo a GND y poner tubo termoretráctil.
Pegar el zócalo a la base con termocola.
Batería
Enchufar el conector a la batería y comprobar cual es VCC y cual GND con un polímetro.
Soldar un cable a VCC y otro a GND y juntarlos con el resto del circuito. Poner tubo termoretráctil.
Enrollar un trozo de cinta adhesiva y ponerla en la zona trasera de la base.
Poner la batería encima de la cinta adhesiva y enchufar esta al conector.
El compilador que se ha usado es el SDCC, que es software libre. Para compilarlo he usado el siguiente comando:
sdcc -mpic14-p12f683--use-non-free lios.c
Para subir el fichero .hex al PIC hay que tener un programador de PICs y un software que maneje el programador. Hay mucha variedad. Yo he usado el pickit3 de Microchip y su software para windows, pero hay otras alternativas más baratas que se pueden usar con software libre o gratuitas para linux, mac y windows.
Explicación
A grandes rasgos el funcionamiento es el siguiente:
Al enchufar la batería los leds parpadean 10 veces rápidamente. Los leds están en una configuración determinada para que si el pin del PIC está configurado como salida y la pone en alto luzca un led, si la pone en bajo luce el otro led; si está configurado como entrada (alta impedancia) los leds permanecen apagados.
Se activan las interrupciones del timer0 y del ADC. La interrupción del timer0 está configurada para que salte cada 0,1 ms. y sirve para contabilizar los tiempos en los servos. La interrupción del ADC salta cada vez que un valor ha sido leído en un LDR para activar el led asociado (si se traspasa cierto umbral), poner un valor en una variable de estado, cambiar el canal de ADC y leer el siguiente LDR.
En el bucle principal del programa se comprueba la variable de estado para saber qué servos deben activarse. La activación de los servos es distinta ya que estos están enfrentados y la rotación para ir hacia delante es diferente en cada uno. Para uno supone una señal alta de 1 ms y otra baja de 19 ms., mientras que para el otro supone una señal alta de 2 ms y otra baja de 18 ms.
Modificaciones:
Los sensores del robot son LDR, pero podrían haberse cambiado por dos CNY70 para hacer un robot seguidor de línea con el siguiente esquema:
Segunda edición donde nuevos ponentes darán charlas sobre temas tan interesantes como impresión 3D, robótica, electrónica, comunicaciones, modelos de negocio; talleres; mesas redondas; concursos; presentación de proyectos personales…
Si te gusta la tecnología, eres amante del DIY, quieres saber hacia donde va la sociedad del conocimiento libre no te puedes perder este evento. ¡¡¡ Sólo hay 450 plazas !!!
Constantemente recibo comentarios y a veces incluso correos electrónicos de gente que me pide cosas que se salen de lo razonable.
Algunos me piden que les traduzca todo el código fuente de C de un proyecto con PIC a ensamblador, otros que les haga una simulación de un circuito en Proteus, otros ni siquiera se leen el artículo y me preguntan cosas que aparecen publicadas en el mismo, alguno me ha pedido hasta que le documente el proyecto de fin de carrera de algún artículo que he publicado, también hasta que les haga un programa entero desde 0, entre otras muchas cosas que podéis encontrar por los comentarios de los artículos.
A mi no me importa ayudar y dedicar algo de tiempo a las dudas que tengan (como también podéis leer en los comentarios), pero la otra persona tiene que demostrar un mínimo de interés en hacer las cosas y motivación para hacerlas el sólo. Y es que parece que los que queremos divulgar algo por Internet tenemos todo el tiempo libre del mundo y ganas de hacer por amor al arte los que los demás nos pidan.
Esta clase de gente ha existido siempre y seguirá existiendo. Pero desde luego por mi parte siempre van a chocar contra un muro si lo que pretenden es que yo les haga su trabajo, ya se este por afición o por obligación.
Hace poco tuvimos en mi trabajo la necesidad de sustituir el proceso explorer.exe de un portátil para que sólo mostrase una ventana con 3 opciones y que el usuario no pudiese hacer nada más.
El explorer.exe es un proceso que cuando se ejecuta al principio muestra el escritorio de Windows y en las sucesivas ocasiones muestra el explorador de ficheros.
Se puede sustituir fácilmente accediendo a la entrada del registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon y modificando el valor Shell por otro ejecutable.
El ejecutable debe estar normalmente en la ruta C:\Windows y puede ser cualquier programa con interfaz gráfica. El nuestro creaba una ventana que ocupaba todo el monitor, con un logotipo de fondo, sin marco y tenía varios botones para cargar otras aplicaciones, reiniciar y apagar.
Para labores de mantenimiento teníamos un botón que debía poner el escritorio de Windows cuando se pulsaba, y lo lógico era pensar que si desde nuestra aplicación ejecutábamos el fichero explorer.exe se mostraría, pero eso no ocurría y solamente nos aparecía el explorador de ficheros. Al final comprobamos que este comportamiento se debía a que el proceso explorer.exe sólo muestra el escritorio de Windows si se cumplen dos condiciones:
Que no exista otro proceso explorer.exe ya ejecutándose.
Que en el registro de Windows que he puesto antes esté apuntando a si mismo.
Por ello lo que tendremos que hacer para mostrar el escritorio es cambiar la variable Shell del registro expuesto anteriomente a explorer.exe, ejecutar el fichero C:\Windows\explorer.exe y pasados unos segundos volver a modificar la variable Shell con el nombre de nuestro ejecutable para asegurarnos que en el siguiente arranque se vuelve a cargar nuestro programa.
Con este artículo termino de explicar cómo explotar todas las características de este marco digital. Este artículo lo dividiré en 3 partes debido a su extensión.
La primera parte consiste en explicar cómo usar la librería SDL (Simple Directmedia Layer) para dibujar en la pantalla. Lo bueno de esta librería es que es muy sencilla de usar y te facilita bastante el dibujar gráficos en la pantalla mediante programación.
La segunda parte trata sobre usar las entradas de información del marco. Se va a leer el estado de los 3 botones, del inclinómetro y la cantidad de luz que hay en el ambiente .
La tercera parte la he reservado para las comunicaciones. Dado que el marco tiene bluetooth y una tarjeta de red configurada voy a explicar cómo intercambiar información entre el marco y otros dispositivos.
1- Librería SDL
Antes de empezar a explicar, lo mejor será que ponga un vídeo, después el código fuente, a continuación cómo compilarlo, ejecutarlo y finalmente explicar su funcionamiento.
Para compilar el programa, copiad el código fuente y guardarlo en la carpeta minifs con el nombre pruebasdl.c, después desde ese mismo directorio ejecutad el comando:
Una vez se haya creado el fichero pruebasdl, descargarlo en el marco junto con las siguientes imágenes:
tal y como explicaba en el anterior artículo y ejecutarlo. Si todo ha ido bien veréis lo mismo que en el vídeo. Para salir del programa simplemente pulsar las teclas CONTROL y C simultáneamente.
[EXPLICACIÓN]
Explicaré cómo funciona el programa. Un buen tutorial de SDL en español lo podéis descargar de aquí.
Se declaran los punteros SDL_Surface, que son los que contendrán las imágenes y el buffer de la pantalla.
La función SDL_Init se llama con el parámetro SDL_INIT_VIDEO para inicializar la librería SDL internamente.
La función SDL_GetError devuelve una cadena con el último error ocurrido en la librería SDL.
La función atexit con el puntero a la función SDL_Quit se llama para que, cuando la aplicación termine, se llame a la función SDL_Quit y libere todos los recursos usados por la librería.
La función SDL_SetVideoMode se llama para inicializar el buffer de la pantalla con los parámetros de anchura, altura, profundidad de color y que use la memoria de vídeo con la técnica de doble buffer (haciendo un OR de los valores SDL_HWSURFACE y SDL_DOUBLEBUF). Esta función nos devuelve la estructura SDL_Surface de ese buffer de pantalla.
La función SDL_ShowCursor se llama con el parámetro SDL_DISABLE para ocultar el puntero del ratón en la pantalla.
La función IMG_Load se llama con la ruta de una imagen como parámetro para cargar la imagen. Esta función nos devuelve la estructura SDL_Surface de la imagen.
La función signal se llama con el parámetro SIGINT y un puntero a una función para que se capture la pulsación de las teclas CTRL y C. Cuando se pulsen se llamará a la función salida que simplemente cambiará el valor de la variable salir. Esto se usa para poder salir del bucle principal y terminar el programa de una forma limpia.
La función SDL_BlitSurface se llama con una imagen, un valor nulo, el buffer de la pantalla y una estructura SDL_Rect como parámetros. Esto copia la imagen en el buffer de la pantalla en el lugar indicado por la estructura SDL_Rect.
La función SDL_SetAlpha se llama con una imagen, con los valores SDL_SRCALPHA y SDL_RLEACCEL y un número como parámetros. Esto modifica la transparencia de una imagen (valor 0 para transparente y valor 255 para opaca). No funciona bien con los PNG, por eso la imagen del sol es un GIF.
La función SDL_Flip se llama con el parámetro del buffer de pantalla para traspasar todos los pixels del buffer de pantalla a la tarjeta de vídeo y así mostrarlos.
La función SDL_Delay se llama con un número como parámetro para parar la ejecución del programa durante un tiempo especificado en milisegundos.
La función SDL_FillRect se llama con el buffer de pantalla, una estructura SDL_Rect y un color como parámetros para que dibuje en la zona determinada por la estructura SDL_Rect un rectángulo con el color especificado. En las animaciones se usa para eliminar el dibujo anterior al que se va a pintar y así dar un efecto de movimiento.
La función SDL_MapRGB se llama con el formato del buffer de la pantalla y 3 números como parámetros. Sirve para mapear un color RGB al formato del buffer de la pantalla y así adaptarlo a su profundidad de color.
La función SDL_FreeSurface se llama con una estructura SDL_Rect como parámetro para liberar todos los recursos utilizados por esta.
Con todo esto hemos logrado dibujar en la pantalla imágenes png y gif, además de animar dos de ellas en un bucle (una haciendo círculos gracias a las funciones trigonométricas de seno y coseno y la otra a fundirse mediante transparencia) a la espera de que el usuario pulse la combinación de teclas CTRL+C para salir del programa.
2- Entradas de información
Al igual que antes pongo un vídeo, después el código fuente, a continuación cómo compilarlo, ejecutarlo y finalmente explicar su funcionamiento.
Hay que hacer lo mismo que en la COMPILACIÓN del apartado Librería SDL. Sólo que esta vez el fichero de salida se llama pruebaentradas y el del código fuente pruebaentradas.c.
[EJECUCIÓN]
Hay que hacer lo mismo que en la EJECUCIÓN del apartado Librería SDL, incluidas las imágenes si no las tenéis ya. Sólo que esta vez el fichero se llama pruebaentradas.
[EXPLICACIÓN]
En esta ocasión he aprovechado el código del anterior apartado y le he modificado para que responda a eventos. Ahora cada vez que se pulse un botón saldrá en la pantalla el icono correspondiente, se mostrará hacia que lado del marco está la gravedad y cuanta luz llega al sensor trasero.
Me centraré en explicar cómo he recuperado la información de las entradas de las que dispone el marco (botones, inclinómetro y fotoresistencia).
Si os acordáis en el primer artículo explicaba cómo acceder a la memoria del vídeo para escribir los píxeles de la imagen directamente en ella. Aquí lo que vamos a hacer es abrir el fichero /dev/mem ya que desde él podemos acceder a los registros del microprocesador que contienen la información de las entradas y poder configurarlas. Si queréis saber a fondo cómo funciona el microprocesador s3c2412 que gobierna el marco os podéis bajar su datasheet. Las entradas de los botones se pueden leer desde los pines 2, 3 y 4 del puerto F y las del inclinómetro desde los pines 9 y 10 del puerto G, en ambos casos son GPIO y los leeremos mediante polling. El valor de la fotoresistencia se puede leer del pin ADC0 y como indica el nombre es un ADC que leeremos igualmente mediante polling.
En la función inicializa_entradas inicializaremos los registros:
Con la función open abrimos el fichero /dev/mem como lectura y escritura.
Con la función mmap abrimos las posición de memoria 0×56000000 para poder acceder desde el espacio de usuario a los registros de configuración y de datos de los puertos GPIO y la posición de memoria 0×58000000 para leer los canales ADC. Estos números se pueden encontrar en las páginas 68 y 69 del datasheet que he puesto antes.
Para leer los puertos F y G debemos configurarlos antes. Para esto debemos acceder a las direcciones de memoria de configuración del puerto F (GPFCON 0×56000050) y del puerto G (GPGCON 0×56000060) e indicar qué bits serán de lectura. En el puerto F serán los bits 2, 3 y 4 por lo que el valor de configuración para este registro (según las página 275 del datasheet) será xxxxxx000000xxxx, o lo que es lo mismo, para dejar el resto de bits a su valor original y sólo cambiar los 6 bits de los botones hay que hacer una operación AND del valor 0xFC0F. En el puerto G serán los bits 9 y 10 por lo que el valor de configuración para este registro (según la página 276 del datasheet) será xxxxxxxxxx0000xxxxxxxxxxxxxxxxxx, o lo que es lo mismo, para dejar el resto de bits a su valor original y sólo cambiar los 4 bits del inclinómetro hay que hacer una operación AND del valor 0xFFC3FFFF.
Para leer continuamente el valor del canal 0 del ADC donde se encuentra conectada la fotoresistencia debemos configurar el registro ADCCON situado en la dirección de memoria 0×58000000. Lo inicializaremos asignándole el valor 0x7FC2 (según la página 420 del datasheet). Finalmente leemos el valor del ADC para activarlo.
En la función lee_entradas leeremos el valor de las entradas y los guardaremos en una estructura llamada ENTRADAS:
Accedemos a las direcciones de memoria de datos del puerto F (GPFDAT 0×56000054) y G (GPGDAT 0×56000064), extraemos uno por uno los valores de los pines con una operación AND, desplazamos esos valores mediante shifting hasta dejarlos en el primer bit y los vamos guardando en la variable correspondiente de la estructura. Los botones cuando están libres tienen un valor de 1, pero cuando están pulsados tienen un valor de 0. El botón izquierdo corresponde al pin 3, el botón central corresponde al pin 4 y el botón derecho al pin 2. El inclinómetro tiene un valor de 3 cuando el marco reposa sobre su base , un valor de 2 si reposa sobre el lado derecho y un valor de 1 si reposa sobre el lado izquierdo. No detecta cuando el marco reposa por el lado contrario a la base (que sería un valor de 0).
Para el ADC0 accedemos a su dirección de memoria de configuración (ADCCON 0×58000000), leemos su valor y comprobamos que el último bit está a 1 para saber si podemos leer el resultado de la conversión o todavía la está haciendo, si está a 1 leemos la dirección de memoria de datos (ADCDAT0 0x5800000C), nos quedamos con los primeros 10 bits y hacemos una conversión a 8 bits para que se pueda usar directamente en la función SDL_SetAlpha.
Con todo esto hemos modificado el programa del apartado Librería SDL para que ahora sólo represente las imágenes dependiendo del estado de las distintas entradas que componen el marco digital.
3- Comunicaciones
Como en los casos anteriores pongo un vídeo, después el código fuente, a continuación cómo compilarlo, ejecutarlo y finalmente explicar su funcionamiento.
Hay que hacer lo mismo que en la COMPILACIÓN del apartado Librería SDL. Sólo que esta vez el fichero de salida se llama pruebacomunicaciones y el del código fuente pruebacomunicaciones.c.
[EJECUCIÓN]
En el ordenador debéis tener bluetooth ya sea incorporado o mediante un usb y conexión a internet.
En el ordenador activar el ruteo de paquetes tcp/ip para la interfaz de red del marco (ejecutarlo todo como usuario root, en ubuntu con sudo -s)
En el marco activar la ruta por defecto de los paquetes tcp/ip
route add default gw 172.16.61.2
En el marco dejar visible a todos el bluetooth y permitir conexiones al marco
hciconfig hci0 piscan
En el marco mostrar la MAC ADDRESS del bluetooth (para saber a donde se debe conectar el ordenador por rfcomm)
hciconfig hci0
En el marco dejar en modo de escucha para rfcomm
rfcomm listen /dev/rfcomm0
En el ordenador conectarse al marco mediante rfcomm
sudo rfcomm connect /dev/rfcomm0 <MAC ADDRESS>
En el ordenador descargarse el programa screen (si no se tenía antes)
sudoapt-get installscreen
En el ordenador conectarse al dispositivo rfcomm0 con el programa screen
sudoscreen/dev/rfcomm0
En el marco ejecutar el programa
./pruebacomunicaciones
En el ordenador desde el programa screen escribir caracteres. ENTER para hacer salir el programa del marco.
Anotaciones
Tendreis que abrir una consola nueva tanto en el ordenador como en el marco después de ejecutar el comando rfcomm puesto que se queda permanentemente conectado hasta que se pulse CTRL + C.
Para salir del programa screen simplemente pulsad CTRL y A a la vez y después de soltarlos pulsad la tecla K.
[EXPLICACIÓN]
Por un lado se pretende conectar mediante bluetooth al marco usando las utilidades BlueZ mediante RFCOMM. Así conseguimos que desde nuestro ordenador podamos enviarle datos al marco.
Por otro lado pretendemos conectarnos a una página de Internet para recuperar una imagen y mostrarla en el marco.
La unión de ambas cosas es lo que habéis visto en el vídeo. Mientras escribo en el programa screen caracteres, estos se envían al marco mediante bluetooth. Despueś el marco los va concatenando y va llamando a una página web que he hecho a tal efecto para que vaya generando la cadena de texto en una imagen PNG. Esta imagen se la descarga el marco y posteriormente la muestra.
Gracias a las utilidades de BlueZ la conexión bluetooth ya se establece mediante comandos y nosotros nos tenemos que dedicar simplemente a abrir el fichero /dev/rfcomm0 y desde este escribir o leer con las funciones básicas que proporciona C para manejo de ficheros.
Las conexiones a Internet se consiguen mediante programación de sockets y esto nos da mucho juego para poder pedir información (descargar una imagen, llamar a un servicio web, etc.) y luego mostrarla en nuestro marco. En el ejemplo cuando se llama a la función carga_imagen hacemos una conexión http a http://www.sistemasorp.es/blog/imagen.php con la cadena pasada como parámetro y guardamos en el fichero texto.png la imagen PNG que se ha generado. No voy a explicar qué hace cada función de los sockets, pero si os recomiendo leer el mejor manual que hay en internet para saber cómo programarlos: Beej’s Guide to Network Programming.
Y aquí acaban esta serie de artículos esperando que os haya servido de ayuda para que podáis empezar a juguetear con el marco y sacarle muchas utilidades. Me gustaría que si hicieseis algo con el lo pusierais en los comentarios, además de vuestras dudas o lo que sea.
Hace tiempo que mi amigo Roberto quiso actualizar su cámara IP (la cual compró por recomendación mía). El caso es que al actualizar el firmware el proceso falló y la cámara quedó inutilizada. Así han pasado ya muchos meses hasta que hace unos días me encontré con esta página que hablaba de cómo recuperar una cámara Foscam FI8908W cuando el proceso de actualización de firmware ha fallado.
Lo bueno de esta página es que habla de que las cámaras foscam (y la zaapa ciprw es una de ellas con el modelo FI8901W) no mueren del todo, sino que tienen un puerto serie escondido al que se puede acceder y comunicarse con una consola para cargar un firmware. Yo me he comunicado con la cámara con un conversor serie TTL a USB:
La solución ya estaba, sólo tenía que conseguir el firmware de la zaapa (ya que otros no valen) y decirle a mi amigo que me dejase su cámara para arreglársela. Pero no ha sido así de fácil y he tenido que pelearme con varios frentes.
El primero es el servicio técnico de Foscam. En el comentario 101 del anterior enlace un tal David comentaba que Doris de Foscam había sido muy amable y que le había dado los ficheros de recuperación. Yo probé la misma suerte con el servicio técnico de Foscam y esta fué la primera respuesta que obtuve:
Hi,
We do not have a model No. FI8901W camera, could you please double check the model No.?
Es decir, que no saben ni los modelos que han fabricado. Le dije que si existía ese modelo de cámara en su marca y me contesto esto otro:
Hi,
Sorry for my mistake. We have stopped produce this product for a long time. We do not have the firmware now. Sorry for this.
Vamos que no querían ayudarme en nada (David, que suerte tuviste…).
Buscando por Internet unos ficheros de recupercación para la zaapa o para la FOSCAM FI8901W no encontré nada. Pero por suerte encontré esto otro. Una forma de extraer de una cámara que funcionase su firmware a través de la consola serie oculta. El proceso fue pesado: me tuve que bajar el kermit 95 y buscar cómo demonios abrir una consola serie, después esperé un rato largo a que se ejecutara el script, convertir con el jedit una salida en otro fichero y finalmente pasar el convertidor de hexadecimal a binario, el cual tuve que compilar, modificar y compilar de nuevo para que funcionase. Todo esto para que al final no se hubiera decargado correctamente el firmware linux.bin y romfs.img necesarios para reprogramar la cámara estropeada, dando esta errores nada más arrancar.
Parecía que no iba a dar con la solución, pero encontré un programa que te descargaba automáticamente los ficheros necesarios del firmware. Lo ejecuté y parecía que había hecho bien su trabajo, pero pasó lo mismo que en el anterior párrafo aunque esta vez sólo con el fichero linux.bin. Sin embargo gracias a esta otra página descubro que el fichero linux.bin es en realidad un archivo .zip y que lo que había hecho está aplicación es comerse los últimos 168 bytes, asi que leyendo la memoria de la cámara que funcionaba recuperé esos 168 bytes.
fx 6 romfs.img 0x7F0D0000 0x7F0D0000 -a
fx 7 linux.bin 0x7F020000 0x00008000 -acxz
Para Windows 7 como no existe el Hyperterminal, he usado el Tera Term.
Finalmente la cámara de mi amigo ha dejado de ser un pisapapeles y ha vuelto a funcionar, pudiéndola manejar ahora con Firefox, con su IPhone, etc.
Para evitaros las incomodidades por las que yo he pasado os dejo los enlaces de los ficheros de recuperación de la versión que le instalé a mi amigo y que es la última que proporciona Zaapa:
En el anterior artículo explicaba cómo instalar linux en el marco digital Parrot DF3120. En este explicaré cómo generar el toolchain para poder crear programas que funcionen en el marco digital. De paso crearemos una versión de la imagen más moderna para nuestro marco. El artículo original que lo explicaba es este, pero está desfasado y hay que hacer retoques para que funcione bien.
Lo voy a hacer todo desde mi linux Ubuntu 11.10, por lo que es posible que algunas cosas haya que modificarlas si usáis otra distribución.
Lo primero es instalarse usa serie de paquetes que son necesarios para que todo el proceso sea correcto:
A continuación hay que hacer un par de modificaciones:
Edita el fichero minifs/conf/board/df3120/config_busybox.conf y reemplaza la línea # CONFIG_CHMOD is not set por CONFIG_CHMOD=y
Edita el fichero minifs/conf/packages/05crosstools.sh y reemplaza la línea hset libtool url “http://ftp.gnu.org/gnu/libtool/libtool-2.4.2.tar.gz” por hset libtool url “http://ftp.gnu.org/gnu/libtool/libtool-2.4.tar.gz”
Edita el fichero minifs/conf/packages/11graphical.sh y reemplaza la línea hset libpng url “ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.4.8.tar.bz2″ por hset libpng url “ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.4.9.tar.bz2″
Después ya podemos ejecutar el script de la siguiente forma (Puede tardar varios minutos):
cd minifs
exportMINIFS_BOARD=df3120
./minifs_build.sh
Ahora vemos que entre otras cosas se han creado dos ficheros en el directorio build-df3120, un .img y un .plt. Pues bien con ellos hay que volver a hacer lo mismo que comentaba en el anterior artículo. Si todo ha ido bien veremos la nueva versión del firmware donde lo más destacado es que aparecen los mensajes de arranque:
Ahora vamos a compilar nuestro primer programa, y cómo no, tenía que ser un Hola Mundo:
Esto habrá generado un fichero ejecutable llamado holamundo, pero ¿cómo lo subimos al marco para ejecutarlo?. Pues bien entre otros comandos el marco tiene dos, el tftp y wget para descargar ficheros mediante el protocolo tftp y http respectivamente, por tanto hay que instalar un servidor web o tftpd en nuestra máquina linux.
Si hemos optado por el servidor web sólo hay que copiar el fichero holamundo al directorio /var/www. Si la elección ha sido tftpd entonces hay que copiar el fichero holamundo al directorio que se haya configurado.
Ahora tenemos que descargarlo desde el marco digital. Hacemos un telnet como explicaba en el anterior artículo. En el firmware actual todo el disco está montado como sólo lectura, por lo que tendremos que remontarlo como escritura también de la siguiente forma:
mount//-o remount,rw
Ahora nos vamos al directorio /tmp y descargamos el programa.
Para tftp el comando sería:
tftp -g-r holamundo <IP DEL SERVIDOR TFTP>
Para wget el comando sería:
wget http://<IP DEL SERVIDOR WEB>/holamundo
Ahora que tenemos el fichero, hay que darle permisos de ejecución y finalmente ejecutarlo:
chmod a+x holamundo
./holamundo
Obtendremos esto:
Ya hemos compilado nuestro primer programa y lo hemos hecho funcionar, pero claro, nos interesa que se pueda dibujar en la pantalla algo para ver cómo se ve en el marco. Lo primero que hay que saber es que la pantalla tiene asignado el dispositivo /dev/fb0 y que lo que tenemos que conseguir es acceder a su memoria para escribir directamente los colores. Esto se consigue de la siguiente forma:
Con la función open abrimos el dispositivo como lectura/escritura:
int g_fb = open("/dev/fb0", O_RDWR);
Con la función ioctl recibimos en una estructura información sobre la pantalla:
Ahora sólo queda dibujar los bytes en la memoria para que se vean reflejados como pixeles en la pantalla. Al poder representar la pantalla 64k colores estos se codifican a RGB mediante 16 bit con el formato 5-6-5 (rrrrrggggggbbbbb). Así el rojo es 1111100000000000 (0xF800), el verde es 0000011111100000 (0x07E0) y el azul es 0000000000011111 (0x001F). Por tanto cada pixel en la pantalla ocupa 16 bits.
Para probar todo esto he creado un programa que muestra un cuadro verde rebotando por el marco usando la técnica de doble buffer para evitar parpadeos:
#include <unistd.h>#include <stdio.h>#include <stdlib.h>#include <string.h>#include <fcntl.h>#include <linux/fb.h>#include <sys/mman.h>#include <sys/ioctl.h>char*inicializa(int*cuantos){char* buffer;int g_fb;struct fb_var_screeninfo var_info;
g_fb = open("/dev/fb0", O_RDWR);if(g_fb ==-1){printf("No se puede abrir /dev/fb0\n");
_exit(1);}printf("/dev/fb0 abierto con el handle 0x%x\n",(unsigned)g_fb);if(ioctl(g_fb, FBIOGET_VSCREENINFO,&var_info)){printf("No se puede obtener la información variable de la pantalla\n");
_exit(1);}printf("xres: %d\n", var_info.xres);printf("yres: %d\n", var_info.yres);printf("bpp: %d\n", var_info.bits_per_pixel);*cuantos = var_info.xres* var_info.yres* var_info.bits_per_pixel/8;printf("El tamaño del buffer de pantalla es de %d bytes\n",*cuantos);
buffer =(char*)mmap(0,*cuantos, PROT_READ|PROT_WRITE, MAP_SHARED, g_fb,0);if((int)buffer ==-1){printf("falló mmap().\n");exit(1);}printf("Pantalla devuelta\n");return buffer;}void cuadro(int x,int y,shortint*buffer,int color){int anchura;int altura;shortint*puntero;for(altura =0; altura <50; altura++){
puntero = buffer +((y + altura)*320);for(anchura =0; anchura <50; anchura++){*(puntero + x + anchura)= color;}}}void main(void){int indice;int cuantos;int x =0;int y =0;int suma_x =1;int suma_y =1;shortint*buffer =(shortint*)inicializa(&cuantos);shortint*ventana =(shortint*)malloc(cuantos);if(ventana == NULL){printf("No se puede crear el doble buffer\n");
_exit(1);}// fondo negrofor(indice =0; indice <(cuantos /2); indice++){
buffer[indice]=0;}for(;;){
usleep(10000);
cuadro(x, y, ventana,0);
x += suma_x;
y += suma_y;if(x >269|| x <0){
suma_x *=-1;
x += suma_x;}if(y >189|| y <0){
suma_y *=-1;
y += suma_y;}
cuadro(x, y, ventana,0x7E0);memcpy(buffer, ventana, cuantos);}}
Que ejecutándolo quedaría así:
En un próximo artículo explicaré como acceder a la interfaz con SDL, comunicarse con bluetooth mediante RFCOMM y obtener los valores de los botones traseros y del inclinómetro.
He adquirido el marco digital de fotos Parrot DF3120. Es un marco que por menos de 20€ puede representar fotografías en una pantalla de 320×240 (3.5″). Sus puntos fuertes es que tiene bluetooth para poder subir las imagenes desde, por ejemplo, un móvil y una entrada para tarjetas SD con la misma función.
Este marco ha sido hackeado y se le puede instalar un linux, con las ventajas que ello representa. El objetivo de este primer artículo es mostrar el proceso de instalación de linux y cómo acceder a este de una forma sencilla.
Lo primero es hacer un duplicado de disco del siguiente fichero: minifs-full-ext.img. Esto en linux, siendo root, se consigue con el siguiente comando (disco SD es el nombre que le haya asignado el sistema):
ddif=minifs-full-ext.img of=/dev/<disco SD>
Lo siguiente es actualizar el firmware del marco. Para ello hay que encender el marco sin ninguna tarjeta SD insertada y enchufar el cable usb. Cuando podamos acceder al contenido del disco, crear una carpeta llamada update y dentro de esta copiar el fichero parrotDF3120.plf. Después sacar el usb de forma segura y veremos que aparecen 4 cuadros en la pantalla (uno azul y el resto verde), momento en el cual ya se ha actualizado el firmware.
Ahora tenemos un modo de arranque dual. Por un lado si encendemos el marco sin más veremos su funcionalidad de siempre, es decir, se visualizarán las imágenes que tengamos almacenadas una detrás de otra. Pero si metemos la tarjeta SD y antes de encenderlo pulsamos los botones izquierdo y central de la parte de atrás y, sin soltarlos, encendemos el marco, se arrancará linux y busybox.
Finalmente para acceder a la consola en el modo linux podemos hacerlo de dos formas (la dificil y la fácil):
La dificil es sacar todos los tornillos para quedarnos con la placa y la pantalla. A continuación soldamos en los agujeros del J4 (la consola serie) los tres pines (1: GND, 2: RX, 3: TX) y nos buscamos un conversor TTL a puerto serie o a usb para poder comunicarnos con el dispositivo usando los siguientes parámetros de conexión: 115200 8,N,1 (recomiendo screen en linux o mac y putty en windows). Esta es la consola serie donde se ven los mensajes de estado del arranque y luego se obtiene una shell donde interactuar con linux:
La fácil es simplemente conectar el cable usb al marco y a nuestro ordenador, lo que nos configurará una conexión ethernet por usb llamada Ethernet Gadget, la cual será una tarjeta de red que debemos configurar con la IP 172.16.61.2 y la máscara de red 255.255.255.0. Si todo ha ido bien y hacemos un ping a la dirección 172.16.61.1 el marco nos debería responder. Finalmente para acceder a una shell sólo hay que hacer un telnet a la IP comentada.
Edición 22/01/2011:
En el marco vienen unos programas para probar la pantalla gráfica. Podeis ejecutar cualquiera de ellos: /usr/bin/plasma: Una bonita demo sobre el efecto plasma. /usr/bin/newvox: Un paisaje que si tuvieramos teclado podríamos recorrerlo.
