Reunion de Feedback Entrevista con Marta 17/10

Nos juntamos Carolina Traboscia y Yo para repasar el feedback luego de la reunión con Marta del Miércoles 11/10.  Pasamos en limpio el resultado de dicha reunión y comenzamos a pensar posibles próximos pasos.

Como primer punto, llegamos a la conclusión de que funcionalmente estábamos en línea con las necesidades de la Fundación.

Nos queda pendiente profundizar con la información médica que sería importante registrar en la base.   Para ello nos pareció necesario tener una primer reunión con Daniela para que nos oriente o derive con profesionales de esta enfermedad.  Quedamos en hacer una conferencia con Barbara para unificar estrategia y comenzar a definir cuestiones formales del proyecto (Metodología de trabajo, etc).

 

 

Filtrar por direccion MAC. Primera Aproximacion.

La primera aproximación para filtrar por MAC utilizando un controlador SDN fue utilizando a Ryu como controlador. Mediante el siguiente script que se encuentra debajo.

En este comienzo lo que se realizo fue pasarle una dirección, como por ejemplo la “00:00:00:00:00:02” y tanto los paquetes de origen como de destinatario a esa MAC se ven descartados.

El resultado de esto, probandolo con una topologia de 5 switch y 5 host fue la siguiente:

(más…)

Reunión Interna de Equipo 28/10

Nos reunimos Andrés, Bárbara y Carolina para armar la estrategia para la reunión con Daniela, referente médica en este proyecto.

Los puntos a plantear en la reunión a coordinar con ella, en principio el martes 7/11 (sujeto a confirmación) son:

  • Validar los objetivos planteados por el equipo desde el punto de vista de los usuarios médicos
  • Cómo obtener información específica de la enfermedad a través de ella o contactos que pueda proveernos
  • Qué tipo de información se podría solicitar que carguen los usuarios médicos en la aplicación, con qué formato y los beneficios que traería esto para otros médicos e investigadores

Próximos pasos:

  • Confirmar fecha para reunión con Daniela
  • Reunión con Daniela
  • Validación interna de lo relevado en la reunión

Reunión Interna de Equipo 21/09

Nos reunimos Bárbara, Claudia, Andrés y Carolina con el fin de hacer una introducción al proyecto y organizar próximos pasos.

En base a la información recaudada por Claudia con la Fundación, se realizó un brainstorming sobre conceptos que la aplicación podría incluir con sus potenciales objetivos.

Siguientes pasos:

  • Reunión con Marta, referente de Comisión Directiva de la Fundación, para cotejar requisitos
  • Reunión interna para validar lo relevado en el punto anterior

 

Se adjunta minuta de la reunión.

G.U.A.D.A. – Configuración Arch Linux Raspberry Pi 3 – B

desde 2017-10-06 al 2017-10-25

Consideraciones iniciales

Consecuencia de la naturaleza del proyecto quedó definida la necesidad de un Sistema Operativo (SO) que cumpla con las siguientes condiciones:

  • Bajo consumo de recursos (Lightweight).
  • Simplicidad en el acceso remoto.
  • Alto nivel de control.
  • Ínfimo número de módulos preinstalados.

Considerando que Ubuntu es una distro bastante pesada y que cualquier alternativa con Interfaz de Usuario (UI, por User Interface) sería un gasto innecesario de recursos para el entorno de desarrollo en el que nos encontramos (donde aún no conocemos con cuánta performance necesitamos), la mejor alternativa que se nos presenta dentro del universo Linux y en base a la investigación realizada es ArchLinux, la cual es mega lightweight y permite una conexión simple por SSH.

Instalación

Primer acercamiento.

Comenzando con una SD Clase 10, la página de ArchLinux facilita un corto tutorial para la instalación en ARMv7, la arquitectura sobre el que está construido la Raspberry Pi 3 (RPi3), en su propia página.

https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3

Realizamos la instalación en la SD desde Elementary.io, una distro de Linux Debian.

Usando el comando fdisk -l pudimos mapear el nombre de la SD: mmcblk0. Así pudimos enviar las instrucciones a la memoria externa y crear dos particiones, una FAT32 de 100mb para el boot, y una ext4 para montar el sistema operativo.

Creadas las particiones se hizo posible montar las mismas al File System para instalar ArchLinux pero la partición ext4 comenzó a comportarse de forma anómala. No solo no permitía su montaje, sino que indicaba fallas lógicas al intentar re particionar.

Finalmente, luego de correr la herramienta fsck sobre la SD, encontramos altísimos valores de sectores defectuosos, lo que supuso el reemplazo de la memoria externa.

Una vez reemplazada la tarjeta de memoria, se siguieron los pasos recomendados en la web hasta el montaje de las particiones en el FS.

Las particiones boot y root son las mmcblk0p1 y mmcblk0p2 respectivamente; boot es una partición FAT 32 mientras que root es EXT4.

Llegado el momento de realizar el wget, decidimos buscar en los repositorios de Arch por una versión más suitable para la RPi 3, ya que la versión recomendada en el instructivo era para un RPi 2.

https://archlinuxarm.org/about/downloads

Allí encontramos la versión más nueva para descargar – ArchLinuxARM-rpi-3-latest.tar.gz

Realizando el wget, descargamos el build y, siguiendo el instructivo de Arch, procedimos a ejecutar bsdtar. Sin embargo, el comando falló.

Investigando el error, encontramos un segundo instructivo, no oficial pero mejor explicado y que además, nos guiaba hasta llegar a la instalación de una interfaz gráfica:

https://www.zybuluo.com/yangxuan/note/344907

Seguimos el instructivo hasta llega a la instalación de XFCE4 y SDDM, con todo funcionando bien. Sin embargo, cuando intentamos poner en marcha la maqueta en un monitor el jueves 12.10 en el aula del C.I.D.I., el tty no levantó. Intentando solucionar el inconveniente, tuvimos una dificultad con la distro de Linux que usábamos para montar la SD, destruyendo las particiones de la PC madre.

Reconstruimos GRUB, Kernel y módulos y procedimos a instalar qemu para poder hacer chroot sobre la SD y debuguear el problema que impide que podamos levantar X nuevamente.

Instalado qemu-aarm64-static en el root sobre el que fue montada la partición mmcblk0p2, se siguieron las instrucciones al pie de la letra del apartado Using chroot de la documentación de Arch Wiki

https://wiki.archlinux.org/index.php/change_root

La primera tarea fue actualizar el SO con el comando pacman -Syu, principalmente para llevar X a su última versión y para blindarnos contra ataques sobre el exploit recientemente descubierto sobre WPA2 (planeamos usar el WiFi integrado de la RPi).

https://www.theverge.com/2017/10/16/16481136/wpa2-wi-fi-krack-vulnerability

Completada la actualización, el conflicto con la interfaz gráfica se solucionó sin tener que tomar ninguna acción adicional. Sin embargo, no fue posible conectarse a internet ni por WiFi ni por Ethernet.

Revisando el booteo, descubrimos el mensaje NET: no ethernet found. Estudiando sobre los pasos documentados, notamos que no montamos boot sobre root/boot al momento de llevar a cabo la actualización con pacman -Syu, lo cual generó severos conflictos con el hardware.

Profundización sobre la investigación.

A fin de resolver el conflicto de la forma más económica, decidimos realizar un build nuevo. Además, aprovechamos la oportunidad para reemplazar el formato ext4 en la partición mmcblk0p2 por el formato f2fs, que es un file system diseñado especialmente para periféricos de almacenamiento de tipo flash, lo que significa una mejora en el rendimiento total del SO.

Mientras tanto, pasamos a estudiar la guía que habíamos seleccionado y para nuestra sorpresa encontramos que, aunque detallada, se encuentra bastante desactualizada: la documentación de Arch Linux indica que muchos de los pasos que sugiere la guía no son necesarios porque, por ejemplo, libdri2 se encuentra integrado desde 2012; además, en el apartado de video, Wiki Arch indica que

 

The X.org driver for Raspberry Pi can be installed with the xf86-video-fbdev or xf86-video-fbturbo-git package.

 

Lo que significa que, con solo instalar Xorg de los repositorios de Arch, podríamos instalar XFCE4 y SDDM sin ningún problema.

Por otra parte, también leyendo la documentación en Wiki Arch ARM, encontramos que la versión del SO que estábamos usando contenía un disclaimer:

 

AArch64 Installation

This provides an installation using the mainline kernel and U-Boot. There is no support for the vendor-provided libraries, extensions, or related software. Some of the hardware on the board may not work, or it may perform poorly.

Follow the above instructions, substituting with the following tarball:

http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-3-latest.tar.gz

 

De la misma se desprende una potencial conclusión para los problemas que se estaban presentando en los builds que realizamos: la versión del SO era inestable y además, no era oficialmente soportada por los proveedores de libraries.

Rebuild en 32 bits.

Así fue que la nueva instalación se realizó usando http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-2-latest.tar.gz

La misma no solo quedó completamente funcional, sino además con un rendimiento un poco más sólido y veloz que con la versión de 64 bits. 

La configuración inicial de la instalación se llevó a cabo ejecutando tar xvzf sobre el archivo tar descargado. Luego se procedió a realizar las siguientes modificaciones:

  • editar /boot/config.txt  agregando las líneas:
    dtparam=audio=on
    hdmi_drive=2
    dtparam=sd_overclock=100
  • editar /boot/cmdline.txt sumando la línea:
    rootfstype=f2fs
  • editar /root/etc/fstab escribiendo:
    /dev/mmcblk0p2 / f2fs defaults,noatime,discard 0 0
    tmpfs   /tmp     tmpfs   nodev,nosuid,size=2G  0 0

Para luego mover la carpeta /boot/* (con todo su contenido) a la partición mmcblk0p1.

Lo siguiente fue la instalación y configuración de los controladores de WiFi. Para ello se montó la tarjeta SD en el File System de la distro Elementary.io de la laptop soporte (usando chroot) y se ejecutó el comando:

sudo pacman -Syu networkmanager network-manager-applet

Luego, ya con la SD en la RPi3 se ejecutaron los comandos

systemctl enable NetworkManager systemctl start NetworkManager sudo ifconfig wlan0 up ifconfig wlan0

De manera que se pudo cargar el SSID y el password del WiFi local para continuar con las configuraciones.

Lo siguiente fue la instalación de XFCE4 y SDDM, con una instalación straight foward ejecutando simplemente el siguiente comando:

sudo pacman -S xorg-server xf86-video-fbdev xorg-xrefresh

La instalación se realizó sin inconvenientes.

Finalmente, estando todo listo para instalar Stellarium, realizamos la instalación directa desde el AUR (Arch User Respository) con el comando:

sudo pacman -S stellarium 0.16.1-1

 

G.U.A.D.A. – Plan Tentativo de Trabajo

Interfaz mínima.

  • Configurar RPi3 (ArchLinux). Testear openGL >3.0.
  • Carga Stellarium. Alternativa – Cart Du Ciel.
  • Interfaz Rpi3 / Arduino (sugerida: I2C).
  • Interfaz Stellarium / Arduino.

Mecanica Celeste.

  • Evaluación de mecanismos de seguimiento. Preparación de montura EQ3.
  • Definir resolución (sugerida: 150/f5). Construcción de mecanismos de rastreo celeste (posibilidad de uso de CNC).
  • Diseño de prototipos de estructura (CAD). Evaluar prototipos Open Source.
  • Evaluar consumo y facilidad de implementación de celda PELTIER.
  • Construcción de montura y presentación de la interfaz mínima sobre prototipo.

Implementación.

  • Stress test.
  • Evaluación en ciudad sobre objetos celestes notables.
  • Informe final.

 

G.U.A.D.A. – Presentación e introducción

En la siguiente se desarrollan las premisas y primer acercamiento al proyecto que preliminarmente lleva por nombre G.U.A.D.A: Unidad Avanzada para el Descubrimiento de la Astronomía (cuyas siglas recursivas G.U.A.D.A. serán usadas de ahora en adelante) y se basa en el Telescopio PiKon que la Universidad de Sheffield propuso en Festival of the Mind de 2014 y en ideas nuevas para optimizar, potenciar y diversificar su funcionamiento.

La propuesta pivota en la búsqueda de una solución práctica para un viejo conflicto en la observación celeste, principalmente entre la enorme comunidad no profesional, como es la dificultad de compartir comunitariamente la investigación visual espacial, cuestión fuertemente limitada por los instrumentos utilizados y por la aguda rampa de aprendizaje que exige la disciplina. Partiendo de ese nodo, G.U.A.D.A. es una idea basada en la necesidad de desarrollar herramientas que brinden accesibilidad al conocimiento, articulando sobre limitaciones técnicas actuales para la observación celeste de escala hobbista. Estructurado sobre desarrollos llevados a cabo en otras universidades del mundo, G.U.A.D.A. podría prestarse como una plataforma de aprendizaje y desarrollo del conocimiento constante, tanto sea en su construcción, su evolución o su uso una vez completada en cada una de sus etapas.

El proyecto además cuenta con varios puntos de anclaje donde el reciclaje y la sustentabilidad pueden entrar en juego, así como un espíritu Open Source y Open Hardware sobre el que se busca orbitar a fin de maximizar la accesibilidad para cualquier persona que busque acceder a la observación de los cielos nocturnos.

G.U.A.D.A. busca atacar varios problemas al unísono utilizando las ventajas tecnológicas disponibles que se basan en la potenciación de la observación en tiempo real, la facilidad de uso y la creación de la oportunidad de transformar la observación celeste en una actividad comunitaria. Las puntos de foco podrían ser:

  • Integración comunitaria a la observación celeste
  • Disminución de la pendiente de aprendizaje para el disfrute de la Astronomía, aportando a la accesibilidad científica de la comunidad no especializada.
  • Nueva herramienta para el aprendizaje, observación y estudio del Universo.
  • Permitir la portabilidad de aparatos astronómicos de gran desarrollo tecnológico con facilidad y robustez.
  • Plataforma de integración y desarrollo de nuevas tecnologías en óptica y Astrofotografía.
  • Servir de proyecto escuela y elemento integrador para distintas disciplinas académicas brindadas por la Universidad.

En la rama técnica, todo pasa por buscar soluciones de forma innovadora, tecnológica y sustentable. Los mismos serían:

  • Utilización de la potenciada Raspberry Pi 3B y el renovado Camera Module v2.1 para la mejora de la plataforma original PiKon en calidad de imagen.
  • Integración de una pantalla HD de visualización en tiempo real asociada al telescopio.
  • Desarrollo de una plataforma motorizada de seguimiento, desarrollada sobre Arduino.
  • Diseño de interfaz de control integrada con software Open Source Stellarium. Control táctil para la selección del astro al que observar. Creación de interfaz de comunicación Raspberry Pi – Arduino.
  • Estructura mejorada: muda del diseño Newtoniano del PiKon a un esquema Dobsoniano basado en impresión 3D. Estudio del potencial de reconfiguración para la explotación de múltiples distancias focales (característica casi inédita en telescopios terrestres de pequeña escala). Desarrollo de características portables orientadas al transporte de vehículos livianos (bicicletas o motocicletas)
  • Proyección en tiempo real de astros observados, explotando la conectividad HDMI o Stream WiFi sobre plataforma Raspberry Pi.
  • Potencial para integración en tiempo real de apilado de imágenes y post procesado, inédito para la observación celeste moderna.

G.U.A.D.A. está estructurado en varias etapas de evolución y revisión de objetivos y potenciales, convirtiéndolo en un proyecto ágil desde su concepción.

Muchos de elementos clave para el desarrollo ya están disponibles full time para la investigación y desarrollo del mismo como aportes al proyecto:

  • Impresora 3D de 20x20x27
  • Un módulo RPi 3 b
  • Camera Module v2.1 de 8mpx
  • Arduino Uno o Due, a la espera de confirmación de necesidad de potencia de cálculo necesaria y GPIOs
  • Pantalla Táctil de 7’ de Fundación Raspberry full compatible con puerto dedicado de RPi.

El potencial integrador multidisciplinar además genera una gran posibilidad para formar posteriormente nuevos grupos de desarrollo especializados en cada área que permitan apuntalar y potenciar el proyecto más allá de su estado de prototipo MVP (en español: Mínimo Producto Viable), siendo un proyecto enormemente enriquecedor y valioso para la comunidad científica y la sociedad en general.

ANDADOR – CODE v2.0

// Adafruit NeoPixel - Version: Latest 

#include <Adafruit_NeoPixel.h>

#define trig1Pin 2
#define trig2Pin 4
#define echo1Pin 3
#define echo2Pin 5
#define PIN 14
#define LED_COUNT 3

Adafruit_NeoPixel leds = Adafruit_NeoPixel(LED_COUNT, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  Serial.begin (9600);
  pinMode(trig1Pin, OUTPUT);
  pinMode(trig2Pin, OUTPUT);
  pinMode(echo1Pin, INPUT);
  pinMode(echo2Pin, INPUT);
  leds.begin();
}

void loop() {
  long distance1, distance2, color1, color2;
  distance1=callSensor(trig1Pin, echo1Pin);
  distance2=callSensor(trig2Pin, echo2Pin);

  color1 = checkDistance(distance1);
  color2 = checkDistance(distance2);

  if(color1 > color2) {
    pixelColor(color1);
  }
  else {
    pixelColor(color2);
  }

  Serial.print(distance1);
  Serial.println(" cm");
  Serial.println(" - ");
  Serial.print(distance2);
  Serial.println(" cm");

  delay(500);
}

int callSensor(int writePin, int readPin){
  long duration, distance;
  digitalWrite(writePin, LOW);// Added this line
  delayMicroseconds(10); // Added this line
  digitalWrite(writePin, HIGH);
  delayMicroseconds(10);
  digitalWrite(writePin, LOW);
  duration = pulseIn(readPin, HIGH);
  distance = (duration/2) / 29.1;
  return distance;
}

long checkDistance(long distance){
  long color;
  switch (distance) {
  case 1 ... 40:
    color = 0xFF0000;
    break;
  case 41 ... 70:
    color = 0xFFFB00;
    break;
  default:
    color = 00000000;
    break;
  }
  return color;
}

void pixelColor(long color){
  int i;
  for(int i=0;i<LED_COUNT;i++){
    leds.setPixelColor(i, color); 
    leds.show(); 
    delay(50); 
  }
}

 

ANDADOR – Code v1.0

// Versión 1.0 - 20170828

#include <Adafruit_NeoPixel.h>
#define trig1Pin 2
#define trig2Pin 4
#define echo1Pin 3
#define echo2Pin 5

#define PIN 14
#define LED_COUNT 3

Adafruit_NeoPixel leds = Adafruit_NeoPixel(LED_COUNT, PIN, NEO_GRB + NEO_KHZ800);

void setup() {
  //Serial.begin (9600);
  pinMode(trig1Pin, OUTPUT);
  pinMode(trig2Pin, OUTPUT);
  pinMode(echo1Pin, INPUT);
  pinMode(echo2Pin, INPUT);
  leds.begin();
}

void loop() {
  long distance1, distance2, color1, color2;
  distance1=callSensor(trig1Pin, echo1Pin);
  distance2=callSensor(trig2Pin, echo2Pin);

  color1 = checkDistance(distance1);
  color2 = checkDistance(distance2);

  if(color1 > color2) {
    pixelColor(color1);
  }
  else {
    pixelColor(color2);
  }
  /*
  Serial.print(distance1);
  Serial.println(" cm");
  Serial.println(" - ");
  Serial.print(distance2);
  Serial.println(" cm");
  */
  delay(600);
}

int callSensor(int writePin, int readPin){
  long duration, distance;
  digitalWrite(writePin, LOW);// Added this line
  delayMicroseconds(2); // Added this line
  digitalWrite(writePin, HIGH);
  delayMicroseconds(20);
  digitalWrite(writePin, LOW);
  duration = pulseIn(readPin, HIGH);
  distance = (duration/2) / 29.1;
  return distance;
}

long checkDistance(long distance){
  long color;
  switch (distance) {
  case 1 ... 25:
    color = 0xFF0000;
    break;
  case 26 ... 50:
    color = 0xFFFB00;
    break;
  default:
    color = 00000000;
    break;
  }
  return color;
}

void pixelColor(long color){
  int i;
  for(int i=0;i<LED_COUNT;i++){
    leds.setPixelColor(i, color); 
    leds.show(); 
    delay(50); 
  }
}

ANDADOR – Andador con Detección de Obstáculos por Ultrasonido

Equipo:

  • Nicolas Saban
  • Esteban Buniak
  • Fabiana Fulgenzi
  • Martin Gonzalez Perna

Agosto 2017

Jueves 10

Primera toma de contacto con el Andador: constaba de un Arduino Nano v2.2 genérico con cables de múltiples colores soldados directo a sus pines de salida. Muchos cables estaban desoldados y los pines estaban bastante oxidados. Además, la placa que portaba al Arduino había sido lavada con solvente (por razones desconocidas), destruyendo casi todas sus pistas.

El cableado pasaba por dentro de la estructura del Andador, pero en muchos casos los colores de los cables de salida no coincidían con los que entraban en la tubería.

Los sensores ultrasónicos SH-04 estaban apenas soldados, así como los motores vibradores. Los pines de los leds se encontraban firmes, pero no fue posible rastrear cuáles eran los cables que salían del Arduino que correspondían.

Luego de relevar el estado general, el equipo decidió llevar a cabo modificaciones sobre la infraestructura del desarrollo a fin de optimizar su funcionamiento y el mantenimiento general.

El cambio más significativo fue el reemplazo completo del cableado general, así como modificar la fuente de alimentación del prototipo (que originalmente pensaba ser mediante pilas) a un modelo tipo powerbank de 5v del tipo que habitualmente se usa para cargar teléfonos celulares.

Se definió que la nueva instalación eléctrica debía estar dispuesta por fuera de la estructura, a fin de poder llevar a cabo modificaciones de forma más cómoda, además de considerar escenarios de mantenimiento o reparación del prototipo.

Jueves 17

Se completó el desarme y se preparó un nuevo cableado con cables rezagos de cable Ethernet. El testeo de los sensores fue exitoso, no así el test de uno de los motores vibradores: con 5v directo no reaccionó. Se imprimieron en 3D carcasa a los SH-04 con posibilidad de regular el ángulo de ataque.

El Nano v2.2 daba la respuesta eléctrica que ordenaba el software cargado; sin embargo, la placa soporte donde estaba soldado estaba en pésimas condiciones. Intentamos sin éxito soldar sobre la misma, pero la inexistencia de pistas fue un conflicto insalvable, por lo que se deshicieron las soldaduras y Esteban Buniak se ofreció a retirar el Arduino de su placa.

A fin de salvar el problema con el Arduino, se armó una estructura de prueba con un Arduino Pro Micro de reemplazo. Estructurado sobre una protoboard y con un cableado modelo, se diagramó la estructura básica del nuevo código. Además, se verificó que el WS2812 (led RGB) precisa una galería específica de Adafruit (library Adafruit_Neopixel.h) por lo que sobre el ámbito de pruebas se cargó un programa básico de testeo de la galería y se verificó que los leds funcionan correctamente, además de corroborar que si son instalados en serie pueden comportarse como un array de leds. Se imprimieron en 3D monturas para los tres WS2812.

El versionado de código no se logró documentar.

Jueves 24

Con la instalación nueva con cables Ethernet se procedió a la reconexión con el Arduino Nano desoldado. Sin embargo, los sensores repentinamente dejaron de funcionar correctamente. Se revisó la instalación eléctrica completa, lo cual develó un nuevo conflicto: El uso de cables Ethernet se mostró como una decisión poco práctica para el prototipo y el quebradizo alambre interno generó múltiples conflictos en la instalación provisoria.

Luego de múltiples intentos y revisiones de cableado, logramos aislar el problema: los pines del Arduino Nano fallaban en entregar los pulsos que el software usaba para las mediciones.

Se realizó un programa sketch rápido iterando entre todos los pines, cambiando los valores de output a high (lo que provoca que los pines digitales entreguen 5v sostenidos). Las mediciones dieron como resultado que varios pares de pines no entregaban más de 1.5v, con intermitentes caídas hasta 1.3v. Verificamos que varios pines del Nano se encontraban muy dañados; posiblemente el paso del tiempo no le permitió resistir el stress recibido durante el desoldado de la placa original sobre la que estaba montado. Restará revisar si una limpieza profunda o un cambio de pines permite el salvado del controlador.

Se procedió a realizar una nueva instalación eléctrica, ésta vez usando cables multifilares, fichas housing dupont para las conexiones, el Arduino Micro Pro usado en los testeos como microcontrolador y una protoboard para el montaje de todas las conexiones, priorizando la modularidad para la instalación y reemplazo de piezas.

Además, se realiza una refactorizacion sobre el código del testeo del 17-8 a fin de proveer al programa de mayor cohesión. El código (Andador-code v1.0) se encuentra en la entrada correspondiente.

El diagramado del circuito se corresponde con el diagrama v1.0:

Diagrama temporal del cableado del prototipo

Jueves 31

Testeamos el nuevo Layout sobre el andador. Además de notar que los cables tenían una extensión algo excesiva, no hubo mayores inconvenientes en la presentación. Sin embargo, muchos de los pines no conectaban a fondo, propio de la arquitectura de pines y la ubicación del cableado respecto a los sensores. En varias oportunidades, los pines de los sensores ultrasónicos se desprendían o entraban en falso contacto, generando errores en las mediciones o desconexiones repentinas.

En los primeros momentos el sistema parecía funcionar exitosamente, sin embargo, se empezó a detectar problemas en las mediciones de los sensores de proximidad, que repentinamente comenzaban a disparar spikes o picos en las distancias de las mediciones, entregando datos aberrantes de forma aparentemente aleatoria.

Empezamos a monitorear qué sucedía sosteniendo los pines de conexión y las mediciones tendían estabilizarse, por lo que se procedió directamente a eliminar las fichas y soldar los sensores de forma directa al circuito.

Al energizar nuevamente el circuito, las deficiencias en las mediciones empeoraron, siendo prácticamente imposible devolver al andador a un modo operativo predecible debido a que el ruido introducido por las mediciones arruinaba el funcionamiento entero.

Se intentó entonces anular por software las mediciones aberrantes, pero éstas eran tantas, que el prototipo quedaba inútil, procesando y eliminando mediciones el 70% del tiempo funcional.

Finalmente, definimos reemplazar las soldaduras por pines dupont, reemplazar los cables que podrían estar comprometiendo el funcionamiento del prototipo e investigar con mayor profundidad la documentación relativa a los sensores SH-04 y los WS2812.

 

Septiembre 2017

Jueves 7

La documentación relativa a los WS2812 otorgada por Sparkfun nos ayudó a dar con la clave respecto a las mediciones aberrantes: el sistema de array de LEDs genera al momento de encenderse un pico de consumo mucho mayor del que era capaz de otorgar el Arduino (que estaba alimentando a todo el prototipo), generando que todo el sistema sufra de inanición eléctrica, y como consecuencia, provocando errores en las mediciones.

Para intentar saltar la limitación, procedimos a un cambio en la arquitectura del sistema, introduciendo una fuente de alimentación externa: Un powerbank que alimentara las lineas de corriente de la protoboard sobre la que se monta el circuito de conexiones primario.

Sin embargo, las mediciones desmesuradas seguían provocándose, principalmente sobre uno de los SH-04, por lo que se definió el reemplazo del sensor por un SRF-05. Curiosamente, las mediciones entregadas por este último se mantuvieron asombrosamente estables y casi sin aberrantes. Además se revisaron los ciclos de llamados a los sensores desde el software para intentar eliminar la posibilidad de overlapping entre pulsos de ultrasonidos (que un sensor tome la medición del otro).

Finalmente, se introdujo una resistencia de 3k Ohms en el pin data y un capacitor de 330F entre los pines VCC y GND de alimentación del circuito al array de Neopixels, a fin de suavizar todo lo posible el pico de consumo de los leds; la medida fue exitosa y el SRF-05 no volvió a dar errores de mediciones. Sin embargo, el segundo SH-04 si, por lo que se definió finalmente el reemplazo de ambos SH-04 por SRF-05.

Además, se definió descartar la introducción de motores vibradores en los manillares del andador, considerando que pueden provocar reacciones inesperadas en los usuarios, así como complicaciones innecesarias respecto al consumo eléctrico del prototipo.

Jueves 14

La nueva configuración no pasó los testeos sobre el prototipo. Las fichas, la disposición de los sensores y el cableado no contribuyen a la correcta medición, introduciendo exceso de ruido el sistema. También hay problemas con el cableado a los LEDs.

Entonces definimos retornar al modelo original, con sensores SH-04, revisando fuertemente las conexiones y los pines de conexión.

Revisado el sistema, fijando los sensores sobre el chasis del prototipo y regulando los ángulos, finalmente el andador funciona con buenas mediciones y el comportamiento respeta al programado.

Sin embargo, se descubrieron algunos puntos ciegos en el sistema y las mediciones sobre telas tienden a tener cierto delay.

Quedan por revisar detalles sobre el código, optimizar el uso de la energía y llevar a cabo una revisión completa del diseño y disposición de los elementos, a fin de mejorar la practicidad y estética del prototipo. El código (Andador-code v2.0) se encuentra en la entrada correspondiente.

Pruebas con OVS y Linux namespaces

Pruebas con OVS y Linux namespaces

Inspeccionamos el funcionamiento de Mininet al ejecutar sus tareas de forma manual.
Creamos los network namespaces que simulan los hosts.
Usando virtual ethernet conectamos los hosts a un switch OVS.


# crear namespaces
ip netns add red
ip netns add green


# crear switch
ovs-vsctl add-br OVS1


# crear interface virtual ethernet
ip link add eth0-r type veth peer name veth-r
# conectamos un extremo al namspace
ip link set eth0-r netns red
# conectamos el otro extremo al switch
ovs-vsctl add-port OVS1 veth-r


# repetimos para el otro namespace
ip link add eth0-g type veth peer name veth-g
ip link set eth0-g netns green
ovs-vsctl add-port OVS1 veth-g


# Levantar interfaces y asignar direcciones
ip link set veth-r up
ip netns exec red ip link set dev lo up
ip netns exec red ip link set dev eth0-r up
ip netns exec red ip address add 10.0.0.1/24 dev eth0-r
ip link set dev veth-g up
ip netns exec green ip link set dev lo up
ip netns exec green ip link set dev eth0-g up
ip netns exec green ip address add 10.0.0.2/24 dev eth0-g

Participacion en comunidad de desarrollo de Openstack

Para incorporarse en la lista de correo de Openstack de desarrollo debemos ingresar a la pagina http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

    1. en la sección Subscribing to OpenStack-dev tenemos que ingresar los datos solicitados y luego hacer click en el botón Suscribe
    2. revisamos la casilla de mail ingresada en el formulario y aceptamos la inscripción accediendo a la dirección que nos indica en el mail y haciendo click en el botón  Suscribe
    3. la lista nos enviará un mail indicando que ingresamos a la lista de correo
    4. para editar las opciones de suscripcion de la lista debemos ingresar a la direccion que nos aparece en el mail de bienvenida a la lista que se acemeja a esta http://lists.openstack.org/cgi-bin/mailman/options/openstack-dev/
    5. una vez que se accede a la página ingresar la contraseña que eligio en la pagina de suscripcion
    6. cuando accedió a la página para modificar las opciones debe tildar la opción Neutron (Details) y luego hacer click en el botón “Submit My Changes”

 

Otro lugar en donde se puede obtener información es:

Existe un grupo de usuarios de Openstack en Argentina en donde se realizan encuentros donde se dictan charlas sobre esta tecnología. La página del grupo es : https://www.meetup.com/es-ES/openstack-argentina/

Primeros pasos con Switch OVS

Luego de una lectura a la documentación de Open vSwitch y a diferentes tutoriales que explican su funcionamiento, se pueden seguir los pasos para virtualizar diferentes interfaces de red que se interconectarán entre sí a través de un switch (de forma similar a Mininet, pero directamente a través de Open vSwitch).

Siguiendo los pasos en el archivo antes mencionado, se puede obtener una topología como la siguiente y lograr conectividad entre los namespace rojo y verde.

Switch OVS
Switch OVS

 

El siguiente paso es implementar reglas de filtrado por MAC en el Switch OVS

 

EDIT: se publicó un script que ejecuta paso a paso el desarrollo de este experimento aquí

Resumen de primeros avances

Dado el retraso en publicar los informes de avance, sirva este primero como resumen del progreso hasta ahora.

Comenzamos junto con todo el grupo instalando el entorno en máquinas virtuales con Ubuntu 16.04 a través de VirtualBox. A lo largo de distintos ensayos fuimos conociendo las herramientas y familiarizándonos, lo que concluyó con la confección del informe Nº1, donde a través de Mininet y RYU especificamos una topología y configuramos los switches bajo distintos comportamientos.

Luego nos dividimos en diferentes grupos, y a partir de eso nos concentraremos en Open vSwitch.

Grupos de trabajo y áreas de desarrollo SDN & NFV

Quedaron definidas los siguientes grupos de trabajo y desarrollo hasta el momento:

> Grupo A
>> Area de desarrollo: Gestión y virtualización de infraestructura
>> Herramientas a utilizar: OpenStack
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Christian Andrés
>> Integrantes: Christian Andrés

> Grupo B
>> Area de desarrollo: Plano de Control / Controladores
>> Herramientas a utilizar: Ryu (Python) / OpenDaylight (Java)
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Matías D’amico
>> Integrantes: Matías D’amico / José Cahuana / Aldana Lacapmesure

> Grupo C
>> Area de desarrollo: Protocolos de control / Plano de datos (Switch virtual)
>> Herramientas a utilizar: OpenvSwitch
>> Funciones: Conocer al detalle las funcionalidades de las herramientas / Participar en las comunidades de desarrollo / Interactuar con los demás grupos para lograr el objetivo final propuesto / Postear los avances semanalmente
>> Referente Grupo: Nicolás Pucci
>> Integrantes: Nicolás Pucci / Alejandro Dini

> Colaboradores
>> Función: Recopilación y documentación / Armado de informes
>> Integrantes: Jonathan Rómbola / Ana Gisel Padilla / Leonardo Galarza

Propuestas y objetivos de trabajo para SDN & NFV

Líneas de trabajo para ciencia aplicada:
1) Desarrollo de aplicaciones que hagan uso de plataformas existentes
>> Objetivo 1: Integrar aplicaciones sobre el controlador mediante el uso de API
>> Objetivo 2: Integrar aplicaciones sobre el gestor de infraestructura virtual mediante el uso de API
Posibles aplicaciones que se pueden desarrollar:
> Firewall
> Balanceador de carga
> NAT
> Control de sesiones
> Auto-provisioning
> Reutilización de ancho de banda
> Restauración de servicios por redes alternativas

2) Integración de plataformas de software existentes (Switch/Router + Controlador + Cloud)
>> Plano de datos –> Switches/Router: OpenvSwitch
>> Plano de control –> Controladores: OpenDaylight, Ryu, ONOS, Floodlight
>> Gestión de infraestructura virtual –> OpenStack
>>> Objetivo 1: Integrar Mininet + OpenDaylight
>>> Objetivo 2: Integrar OpenDaylight + OpenStack
>>> Objetivo 3: Integrar Mininet + OpenDaylight + OpenStack
>>> Objetivo 4: Integrar Dispositivos embebidos (TP-LINK + OpenWRT + OpenvSwitch) + Mininet + OpenDaylight + OpenStack

3) Desarrollo de hardware para SDN (CPE, switch, router)

Líneas de trabajo para investigación:
1) Adaptación de protocolos para que trabajen sobre SDN
2) Mejora de métodos de trabajo/algoritmos para las aplicaciones que se desarrollen
3) Proponer arquitecturas para extender el uso de SDN a otros tipos de estructura de redes
4) Participación activa en foros de desarrollo existente

Firewall con Ryu

Se utiliza la aplicacion de Ryu “rest_firewall.py” y el programa postman para manejar comandos rest.

Se crea una topologia de un switch y tres host.

“sudo mn –topo single,3 –controller remote –mac”

Luego se configura la versión de openflow que se va a utilizar.

“ovs-vsctl set Bridge s1 protocols=OpenFlow13”

Al comenzar el firewall bloquea toda comunicación y desactiva el switch.

Podemos activar el switch mediante:

“http://localhost:8080/firewall/module/enable/0000000000000001”

El estado se puede ver:

“http://localhost:8080/firewall/module/status”

Luego se añaden las reglas para permitir la conexión entre host haciendo un post:

“http://localhost:8080/firewall/rules/0000000000000001”

Pasandole por parámetros en la casilla “body” el parámetro de origen, destino y protocolo:

{“nw_src”: “10.0.0.1/32”, “nw_dst”: “10.0.0.2/32”, “nw_proto”: “ICMP”}

La regla debe ser bidireccional, se debe crear hacia ambas direcciones.

{“nw_src”: “10.0.0.1/32”, “nw_dst”: “10.0.0.2/32”, “nw_proto”: “ICMP”}

Con esto previo, se crearon dos reglas, uno para permitir ICMP de 10.0.0.1 a 10.0.0.2 y de 10.0.0.2 a 10.0.0.1.

Luego podemos probar que esto funciona, viendo no bloqueamos la comunicación entre el host 1 y el 2 pero no existe ninguna regla con el host 3 entonces no puede llegar hacia el.

Para eliminar una regla se puede hacer un delete:

“http://localhost:8080/firewall/rules/0000000000000001”

Agregándole en body, el ID de la regla:

{“rule_id”: “1”}

{“rule_id”: “2”}

Routeo dinámico en SDN

Luego de realizar diversas pruebas con las implementaciones RouteFlow(https://github.com/CPqD/RouteFlow/wiki/Tutorial-2:-rftest2) y pwospf (https://github.com/mininet/mininet/wiki/Pee-Wee-OSPF-(PWOSPF)), las cuales se encuentran deprecadas y no se ha logrado resultados satisfactorios. Hemos logrado realizar la prueba que funciono tal cual lo esperado utilizando el protocolo OSPF en un lado de la red y BGP en otro lado de la red (https://github.com/edwinsc/mininet_ospf_bgp), el diagrama de red es el siguiente :