Paso a Paso de mi Proyecto con el RaspBerry

Hola amigos, después de lo que a mí se me hizo una eternidad aparentemente ahora puedo empezar a dedicarme a lo concreto y a compartir mis esfuerzos, vaivenes consistiendo en logros y fallas.

Este hilo se va a dedicar a reportar paso-a-paso mis trabajos dentro del ámbito de mi sistema de control de escotas y de lograr una de los objetivos relacionados, el simular y verificar el control de escotas escribiendo este en el lenguaje de modelación "Modelica" usando como herramientas los productos "Mathematica y SystemModeler" de Wolfram. El Raspi es un sistema que la software de Wolfram apoya y hasta ofrece de forma gratuita para el Raspberry Pi, B+ o 2B su software Mathematica y su entorno y lengua de programación "Wolfram Language".

Para lograr este objetivo y limitándome al contexto de este hilo a temas relacionados al Raspi. Para ello, por un lado, tenía que avanzar mis trabajos relacionados a mi taller y en especial a mi laboratorio electrónico, cosa que describo en otro hilo.

24423627455_c1b312e767_c.jpg


En esta foto tomada esta noche pueden ver la placa del RaspBerry Pi B+ montada en una placa de madera que iré poblando con otras placas en el transcurso de este hilo. También me compré la nueva RaspBerry Pi 2B por ser tan económica, pero empiezo con esta por si la llego a destruir durante mi aprendizaje! A la derecha ven el dispositivo que me armé con la protoboard y no mas para mostrar una placa que permite junto con un cable especial que también tengo los 40 pines del Raspi con el protoboard! Así puedo armar circuitos usando el protoboard y mantener la placa Raspi distante. estoy considerando comprarme un empaque transparente para la placa para así tenerla mas protegida.

La instalación del sistema operacional Raspbian no la voy a describir en detalle pues la única posibilidad haciendo esto es hacerlo menos bien de la multitud de tutoriales disponibles en el Internet en general y en Youtube específicamente. Pero la instalación inicial que pueden apreciar en la pantalla usa la microSD NOOB de 8 GBytes, instalación que resulta en extremo sencilla. Raspbian se puede activar en uno de 2 modos, cada cual teniendo sus ventajas.

Aquella mas adecuada para la programación y los experimentos, al menos inicialmente es aquella no gráfica. Muestro aquí de como se ve esa interfaz pero usando ese modo dentro del ordenador y ejecutando la versión correspondiente de Python 3. Por eso en esta pantalla/ventana aparece la versión 3.5.1 de mi ordenador.

24315333172_007a372f4d_b.jpg


Con la instalación, partiendo de la microSD NOOB o descargando la imagen de NOOB del Internet, se instalan 2 versiones del lenguaje Python. Resulta que el lenguaje "Python" completamente compatible con el inmenso repertorio de software en el Internet es la vieja versión "2.x", siendo allí la versión actual instalada en la placa Raspi es la versión 2.7.3 y que ven en la vista "shell":

24056469369_f980c0466b_c.jpg


La misma versión de Python 2.7.3 pero en el entorno de Windows 7:

24128676220_003d245088_c.jpg


La nueva y más moderna versión 3.x y es en la cual me concentro en el ordenador bajo Windows 7 es la versión 3.5.1. Aquí una vez en la versión command line y en la versión IDLE:

24128972110_e9b2a9394b_z.jpg


Para el Raspi hice la actualización antes de decidirme por hacer este hilo por lo que solo puedo mostrar la versión ya actualizada 3.2.3 y que actualicé usando la siguiente sentencia en el raspi:

sudo apt-get install update Python3

En mi sistema algo no funcionó y tengo que entenderlo para saber que hacer. Sigo teniendo la version 3.2.3 y no la 3.3.

Otra cosa que he investigado es la posibilidad de escribir los códigos de mis programas en el ordenador y de tener ese entorno IDE dentro del ordenador, pero ejecutar los programas en la Raspi. Relacionado a esto está el deseo de también poder hacer el "debuging" dentro del entorno del PC pero el programa siendo ejecutado en la Raspi.

Buscando en el Internet y analizando para este propósito me encontré con el proveedor "Wingware" y me descargue la versión "Personal 5.1.9-1 (rev27910). hay que proceder como si se quisiera instalar la versión personal comprando la licencia y no la versión "Trial"! La versión descargada pinchando "Trial" me resulto en un archivo "zip" conteniendo un folder con todo y escribiendo que se pudiera sacar del "zip" a cualquier lugar en el disco duro y que no se requeriría una instalación. Pues bien, eso no funciona en el entorno de mi ordenador por la software de protección. Pero al iniciar la instalación de la versión "Personal" descargando como archivo "*.exe" permite activar el programa por 10 días de forma gratuita e indica la posibilidad de prolongar 2 veces para un total de 30 días! Vale la pena probarlo, pues el entorno del ordenador es bastante mas poderosa que lo que brinda la Raspi! ya iré contando mis experiencias!
 
Hola amigos, realmente creo que vale contar el estado actual! En general en mi proyecto de la construcción del modelo navegable de un velero siempre vuelve a confirmarse que un tema abre las puertas para ramificaciones!

En este caso finalmente mi entorno del taller y del laboratorio electrónico llego a un punto, lejos de haberlo completado, que puedo iniciar trabajos concretos. Así mis actividades en torno del uso de la placa Raspi, resultando que este entorno es apoyado por las herramientas de Wolfram Software que uso, ha vuelto a abrir un ramo de campos que tengo que investigar.

Como aficionado a la electrónica hacer parpadear un LED puro visto desde el aspecto de conectar a uno de los pines la LED y la resistencia es elemental. Gracias a las librerías disponibles para usar los pines del conector GPIO, que mi foco está en hacer ese ejercicio necesario para confirmar una base que funciona, combinándolo con el inicio de las actividades en torno al implementar un GUI!

También aquí vale mencionar que los materiales de información de como usar el "binding" llamado "tkinter", creo que la traducción apropiada del término inglés sería "conectar" objetos del GUI, llamados "widgets", como son Botones y elementos similares que en conjunto implementan el GUI, con las funciones o instancias de "objetos" del código escrito por ejemplo en el lenguaje "Python"!

Para aquellos de Ustedes no tan familiarizados con lo que son "widgets" y con la lengua de programación "Python, aquí una breve presentación:

"Widgets" son objetos como los "botones" que todos conocemos de las GUIs de Windows o Mac por ejemplo. Si con el ratón pinchamos uno de esos botones entonces el programa al que corresponden ejecuta una acción. Herramientas como "Tk", el cual está disponible en el entorno de desarrollo de Python, usa un programa que hace accesible la herramienta "Tk" al lenguaje de Python por medio de las funcionalidades de "Tkinter". Lo que se puede apreciar muy pronto, observando tutoriales en video disponibles en Youtube, Tkinter en combinación con "Tk" y Python conecta un elemento gráfico llamado widgets, aquí como ejemplo un "botón", con un módulo del programa escrito en Python. Así existen por ejemplo 3 parámetros que se pueden asociar a ese widget, "Button-1" = botón izquierdo del ratón, "Button-2" el botón céntrico del ratón y "Button-3", el botón derecho del ratón! Si ejecuto el botón izquierdo del ratón estando el cursor por encima de ese botón, entonces es ejecutado la función conectada a ese parámetro, "Botton-1".
Todo lo que normalmente exige una cantidad considerable de código como por ejemplo:
1.: Monitorear la posición del cursor en la pantalla y detectar que este se encuentra por encima del botón.
2.: Posicionar el botón en la pantalla aún si cambio las dimensiones físicas de la ventana.
3.: Detectar cuál botón del ratón se pincho, eso se denomina "evento".
4.: Habiendo detectado la acción del usuario de haber pinchado un cierto "widget" y por lo tanto haber sido confrontado con ese evento de haber pinchado uno de sus 3 botones el conectar este evento con cierta función de mi programa escrito en Python.
Todo esto ocurre de forma invisible para el programador con solo conector una función al evento correspondiente del "widget" que el usuario pincho!

Esto hace muy sencillo el sumar al código que usualmente hacemos como primer ejercicio, el parpadear de un LED un GUI!

Los problemas para mi en mi proyecto empiezan cuando pienso y considero la implementación de un GUI apropiado para los experimentos que tengo planeados! Yo quiero crear un GUI como los que conocemos de otras herramientas de software, donde es fácil usar y crear un panel instrumental. No mas hay que ver las funcionalidades en esto ofrecido por ejemplo de las herramientas de NI, "National Instruments"!

Lo primero que hice fue investigar las funcionalidades ofrecidas por Tk a través de Tkinter. Aquí existen 3 formas diferentes de implementar el diseño de un GUI. Pero realmente fuera de ofrecer métodos sencillos para definir la GUI se pueden usar los widgets posicionándolos usando un "grid". Grid es una estructura de tabla como lo conocemos por ejemplo de Excel. Los widgets disponibles de forma incluidas en tkinter según lo que mis investigaciones han dado al momento no incluyen un "instrumento" análogo a aquellos que se usan para indicar tensiones de forma análoga en un panel instrumental! Por otro lado widgets adicionales existen, pero identificar un paquete que incluya tales widgets no he sido capaz de encontrar. Adicionalmente se dificulta el asunto de una cantidad inmensa de paquetes para extender la funcionalidad puesta a disposición, pero que se subdivide en versiones que funcionan o solo con las versiones 2.x o de las 3.x de Python. Yo uso la versión 3.5.1

24475843062_1ec8352ae4_o.png


esta imagen, por bonita que parezca, no implementa widgets como la imagen de un instrumento análogo, sino solo como mostrar o datos digitales y imágenes creadas a base de datos que son mostrados en la pantalla como curvas para lo que se usa un widget llamado "Canvas"en Tkinter por ejemplo. Un instrumento análogo debería permitir definir entre que valores puede cambiar el dato y después poner la aguja de acuerdo al valor de los datos.

Claro, existen programas donde es posible crear datos basándose en gráficas vectoriales, pero debe haber alguna herramienta que ofrezca tal funcionalidad!

Para no limitar mi punto de vista en estas investigaciones conscientemente investigo que otras herramientas existen para crear el GUI que ejecutaré en la Raspi finalmente. "Qt" es un ejemplo. Pero también veo la posibilidad de crear el GUI usando herramientas disponibles en javascript. Aquí se gana el acceso a herramientas usadas para el diseño de páginas en el Internet. Pero es posible conectar widgets creados en tal entorno a Python y finalmente al nivel físico de mi placa Raspi? Será posible instalar y ejecutar todo esto en el entorno de la Raspi? Cual camino es el mas sensato a seguir? Aquí estoy abierto y a la espera de consejos de ustedes mis lectores del hilo!

También aquí entra a jugar la posibilidad de usar "Crossplatform" herramientas! Programar en el entorno de Windows 7 en mi ordenador y ejecutar y analizar el comportamiento en la placa Raspi! Como funciona todo esto si me decido por un camino en conjunto en el entorno ofrecido por la herramienta "Wing" de wingware que me acabé comprando una licencia personal no comercial por su apoyo de hacer "crossplatform" desarrollo del PC a la placa Raspi con Python!

Leyendo toda la información que publico ahora el asunto suena apto de crear problemas que no puedo solucionar! Claro, que una vez que mi placa Raspi se comunique con el ordenador por Wifi, que aprenda y logre implementar la funcionalidad de "crossplatform" de mi herramienta "Wing" implementaré aquella solución con foco en simple, que me permita controlar el parpadeo del LED por un GUI y actualmente no veo problema alguno en lograr esto con Python y Tkinter/tk. Pero lo que aquí pongo como prerequisito me exige a mi, por mi decisión de hacerlo en tal forma", entender como Samba o "sh" funcionan y permiten e implementan la comunicación entre mi Raspi y la herramienta Wing por la cual ya me he decidido!
 

Adjuntos

  • Qt related shots.png
    Qt related shots.png
    129.7 KB · Visitas: 14
Última edición:
Investigando las posibilidades para poder hacer girar una imagen dando un ángulo específico como ocurriría si representa la parte de la brújula que giro, me parecía una opción interesante poder hacer girar una foro. Claro, hacerlo en el ordenador usando Photoshop por ejemplo la cosa es clara. Pero teniendo como objetivo el hacer girar tal imagen de forma integrada en el GUI ya es otra cosa.
Me encontré ayer con la posibilidad de copiar una imagen a una matriz y de realizar la multiplicación entre la matriz que contendría todos los pixel de la imagen y una matriz "4x4" con la cual se puede definir libremente el ángulo de giro de la imagen que resulta! Habiendo tenido noción de esa técnica esta noche en la cama me vino el punto a la mente que para la placa RaspBerry Pi B+ y 2B tambien existe integrado el lenguaje "Wolfram" usado en la software Mathematica. Teniendo no solo una licencia legal de Mathematica 10 en el PC, sino también en las placas Raspi fui al programa y me encontré que allí existen las sentencias requeridas:

1. Import ["file"]: Siendo file el "Path" al archivo en la memoria del disco del Raspi (tarjeta Flash o como tengo pensado hacer en un disco duro conectado por USB).

2. ImageDimensions: Que me da el tamaño de la imagen en pixels (2D)

3. ImageData: que me crea una matriz donde se graban los pixels individuales.

4. ImageTake: Que puede captar los datos provenientes de la cámara fotográfica del Raspi.

5. ImageRotate: Hace girar la foto alrededor del centro de la foto.

6. Ahora no encuentro el nombre de la sentencia, pero también existe una sentencia para hacer girar la foto alrededor de un punto cualquiera a definir.

7. Finalmente existe la posibilidad de manipular imágenes con todas las funciones imaginables e inimaginables usados por aquellos dedicados a trabajar en gráficas.

Se que había la forma de usar las funciones de Mathematica y el lenguaje Wolfram desde el lenguaje de programación Python!

Sigo reportando mis avances!
 
@cosmefulanito04: Desafortunadamente estar vigilando que no aparezcan promotiones de los productos de algún proveedor es algo importante para mantener la credibilidad de un foro! De ahí no solo que no te tomo mal el gráfico, sino que te preguntaría como lo has hecho?
Ahora el porque de mi foco en las herramientas de este proveedor, cosa que creía ya haber aclarado. Existen mínimo 4 candidatos de herramientas del tipo que necesito. Son de los proveedores Maple, Mathworks, Dassault con su producto Dymola y Wolfram, fuera de las herramientas que ofrece la misma institución que fomenta y desarrolla el lenguaje "Modelica"! maple es muy bueno y apoya lo que he decidido va a ser y es mi estrategia, pero prohibitivamente caro para la herramienta Maplesim, pero ahora tambien ofrece una licencia para uso no comercial de maple, que sería la equivalencia con Mathematica. Mathworks finalmente con sus productos Matlab, Simulink y un muy alto número de módulos ofreció su producto no comercial cuando ya había invertido en la licencia de Mathematica. Pero el lenguaje "Modelica" modela usando objetos acausales, donde la dirección y así lo que es "Input" y "Output" es implementado a la hora de compilar y de forma invisible para el usuario. eso permite reusar los objetos que se van desarrollando. Un buen ejemplo para comparar objetos causales, donde la dirección es imperativa a la hora de diseñar un modelo es un motor eléctrico:

Si le aplico la tensión a un motor DC aparee en la salida un torque físico. Si ahora uso ese mismo motor como generador, entonces como "Input" hay un "toque" físico que genera una "tensión" a la salida. la implementación de ambos casos en un lenguaje de modelación causal resulta en 2 modelos totalmente diferentes. En objetos acausales como los ofrece Modelica el modelo del motor DC queda siendo el mismo en ambos casos. Existen vídeos por ejemplo en el sitio de Maple donde se da el ejemplo que menciono.

Pero volvamos al tema de mi proyecto del diseño de mi sistema de control de escotas para el modelo de mi velero:

Quiero aplicar la técnica de diseño por modelación para diseñar una implementación de mi sistema eficiente y que entonces entenderé en un alto grado. De allí las herramientas en forma de los 2 productos de software que menciono se vuelven tal una herramienta de electrónica como lo es un soldador.

Ahora una componente esencial en el diseño de modelos es la verificación de los modelos comparando los resultados de la simulación de un modelo con los datos que se ganan de experimentos físicos. Los aspectos se pueden expresar usando 2 términos. HiL y SiL, o "Hardware-in-the-Loop" y "Software-in-the-Loop". No los explico ahora si no recibo la pregunta! Pero es de allí que mis experimentos físicos con el motor de paso y el sensor magnético angular, actor y sensor, son controlados y monitoreados por placas con controladores. Ya he presentado varias veces el diagrama de bloques de mi sistema de control de escotas y para no aburrirlos mas de la cuenta no lo repito aquí.
Para poder usar las placas y las herramientas de Wolfram tengo que aprender e investigar un cierto número de temas:

SystemModeler se comunica con hardware externa usando el protocola firmata. Cuando hacía mis estudios de como meterme en esta materia SystemModeler y la placa Teensy 3.1, un ARM Cortex M4 de Freescale si no mal recuerdo era el entorno en el cual se podía estudiar como eso se efectúa allí para aprender como puedo lograr comunicarme con las placas LPCXpresso1769 de NXP que utilizo.

Mathematica y el lenguaje de programación Wolfram Language son disponibles de forma gratuita como parte de la instalación de la distribución de Linux llamada Raspbian, nombre que combina Raspi y Debian! De allí mi decisión de adquirir la placa RaspBerry Pi B+ y posteriormente también la placa RaspBerry Pi 2B.

A razón de esto resultó que tenía que adquirir conocimientos de Linux y de la placa Raspi. En Raspi la lengua de programación mejor apoyada es Python que existe en las versiones 2.X y 3.x. de allí me embarqué en sendos cursos MOOC disponibles de forma gratuita de universidades gringas.

Finalmente estudiando Python para el Raspi para mi resultó evidente que sería un ejercicio que me gusta hacer el generar una GUI usando tkinter. Así se cierra el círculo de lo que presenté en mi última contribución, donde resultó que en la versión 3 de Python los elementos usuales para hacer girar una imagen no están disponibles en todas sus variantes. Investigando este tema fue donde realicé que mi herramienta Mathematica efectivamente ofrece las funcionalidades de forma súper sofisticadas. Como las interacciones con la software Mathematica con mi hardware son uno de los objetivos, así usando Mathematica para girar imagenes de fotos al mismo tiempo me permite empezar a familiarizarme con el tema de las interacciones de mis placas con la software Mathematica.

Ojalá tu muy justificada indicación que si no estaba promocionando los productos de un proveedor ojalá he podido explicar el porqué estas herramientas obligadamente tienen que ser parte de mi reporte en este hilo y de porque todos estos temas informáticos si son una parte de los trabajos electrónicos y así parte del tema de este foro y de allí concluyo mi justificación de mencionar y tratar estos productos en el contexto de mi reporte en este hilo!
 
@cosmefulanito04: Gracias por tu referencia a OpenCv. Estuve investigando que es, su ecosistema. Me pare e, justo en conexión con los tutoriales, un entorno muy recomendable para procesar imágenes. Pero me parece ser demasiado esfuerzo para mi, que no quiero meterme en la materia del procesamiento de imágenes, sino solo teniendo la necesidad de hacer girar imágenes para lograr, como en el ejemplo que usé en mi contribución, crear un GUI ópticamente atractivo.

Como para mi objetivo de la simulación y verificación de modelos uso la software de Wolfram, recuerda que Mathematica y SystemModeler son el entorno para crear, verificar y ejecutar los modelos para el diseño por modelación y Mathematica ya ofrece el entorno de procesamiento de imágenes en general y las funciones específicas que requiero, no veo la justificación de meter mas en el entorno ya restringido de un sistema embebido otra herramienta tan poderosa para una función que en mis objetivos es marginal.

Pero definitivamente OpenCv me parece interesantísimo como herramienta poderosa. Lo que también leí es que el entorno disponible de OpenCv y el binding de OpenCv con Python se limita en Marzo 2015 a la versión 2.7 de python. Ya existe este entorno para Python 3? El autor del blog menciona que en marzo del 2015 OpenCv 3.0 aun estaba en beta!
 
No me manejo con phyton así que no sabría decirte.

Yo lo uso tanto en C/C++ (linux), como en Visual C++ (windows) y sin problemas.

Para girar la imagen, simplemente tenés que llamar a esta función:

Código:
void flip(InputArray src, OutputArray dst, int flipCode)

El código sería algo así:

Código:
...
  Mat src= imread("Directorio de la imagen", 0); 
  Mat dst;

  flip(src, dst, 0);
...

Con esas lineas, en "dst" obtenés la imagen girada respecto al eje X. Para acceder a la nueva imagen tenés dos formas:

1- Directamente desde memoria RAM a través de un puntero.
2- Guardando el resultado en disco como una imagen con el formato que resulta más cómodo.

Para 1, al puntero se accede de esta forma:

Código:
void* ptr_dst=dst.data;

Para 2:

Código:
imwrite("Directorio de la imagen destino", dst);

Incluso la rotaciones que querés implementar a 90º/180º son sencilla de realizar si las imágenes son cuadradas (no requieren de librería alguna), simplemente se reorganizan los píxeles mediante el uso de for's, incluso para hacerlo más complejo, pero más abarcativo, se pueden usar matrices de rotación.
 
También podés rotar con otros ángulos, pero al rotar en un ángulo que no es múltiplo de 90, aparece el problema de cuantización de la posición de los pixeles, es decir por ej. el pixel [100; 100] luego de la rotación deberá tener una posición de [204,5; 180,34] (por decir algo). Ese valor decimal en la posición ocasiona agujeros en la imagen resultante, por el simple hecho de que hay forma de llevar al pixel a la posición [204,5; 180,34], como resultado se obtiene una imagen con agujeros, algo similar a esta:

nbs.png


out.png


Esa imagen resultante, luego de rotarla, se deberá interpolar para llenar esos agujeros. El OpenCv te hace todos esos pasos cuando le aplicás la rotación.

Hay otra solución más simple y rápida, que emplea las matrices de rotación de manera distinta (en realidad es lo mismo, pero juntando los pasos en una sola matriz), pero ocasiona un efecto serrucho muy notorio:

http://www.datagenetics.com/blog/august32013/index.html

res.png
 
Otra vez mil gracias por tus aportes. Actualmente vuelvo a tener problemas de salud lo que me tiene forzado a esperar hasta volver a ser capaz. Pero viendo lo que cuentas tendré que experimentar cual, de los varios caminos a Roma que también gracias a ti ahora conozco, me da la solución mas apropiada. Recuerda que los recursos de la Hardware en los sistemas embebidos es muy limitada en comparación a un PC.
Pero a razón de lo que voy aprendiendo puede que en el sistema que finalmente ponga en mi velero tambien la Raspi será un elemento. Fuera de que sus recursos en forma de memoria RAm y discos es mucho mayor. Empieza por el 1 GB de memoria RAM, sigue con la posibilidad de usar memorias Flash de hasta 32 GB y por encima de ese límite es posible usar mas memoria y acelerarlo usando sticks de memoria Flash. En mi laboratorio estoy por darle acceso al Raspi a un disco duro de 1 TB por USB, simplemente porque lo tengo disponible y sin usar!
Sigue las posibilidades que resultan de la funcionalidad de WiFi y de acceso al Internet que hasta podrían hacer posible controlar mi velero por una Tableta!
No existe situación mas atractiva para quien tiene como objetivo aprender y experimentar el tener muchas opciones a analizar! Mil gracias y ya reportaré nuevos progresos!
 
El problema de la rotación hace tiempo lo enfoque de otra forma (que también aparece en el enlace que has puesto cosme) básicamente lo que hacia para rotar era en lugar de explorar la imagen de origen para pintar la de destino, escaneaba la de destino píxel a píxel y realizaba la transformación inversa para ver cual era el píxel de origen. Como era de esperar casi siempre caía en un píxel de origen de valores fraccionales. El enlace que has puesto dice de calcular el color de píxel final en proporción a las áreas del píxel origen que caen en los cuatro píxeles vecinos. Yo lo que hacia era calcular el módulo de la distancia y normalizar la suma de las inversas de distancias a 1. De manera que por ejemplo si el píxel de origen era (2.4,3.7), la distancia con A(2,3) es 0.81 y su inversa es 1.234, la distancia con B(2,4) es 0.5 y su inversa es 2. La distancia con C(3,3) es 0.92 y su inversa es 1.08, y de D(3,4) distancia 0.67 y su inversa 1.49. Así sumando las inversas de las distancias queda 5.8 y dividiendo por ese valor me salen los pesos, así pues cada punto contribuye con su color en las siguientes proporciones A=21.3%, B=34.4% (el más cercano), C=18.7% (el más lejano), D=25.6%.

Luego también jugué con ciertos mapeos curiosos. Por ejemplo, en el mapa complejo generado por los puntos de escape de la circunferencia de radio 2, resultado de iterar Z(n+1)=Z(n)^2+C, donde C mapeaba la imagen de origen en el círculo de radio 1, y la imagen de salida se mapeaba en función de los valores de escape (o mejor dicho como de lejos quedaba el punto de escape pasadas X iteraciones), normalmente en ese mapa, en las vecindades de cada cero de la función iterada (para saber el cero en X iteraciones lo sencillo era deshacer la iteración en n pasos y calcular los ceros del polinomio resultante) normalmente se encuentra un subconjunto de "mandelbrot", pero al estar las coordenadas originales mapeadas con la imagen de inicio en el interior de cada subconjunto aparecía la imagen inicial repetida, girada y mayor o menor mente deformada. Fue un resultado curioso.

IMG_20160128_190723.JPG
 
Última edición:
Aquí las images tomadas de mi pantalla e utilizando Mathematica.

Primero importo la imagen con la sentencia:

data4 = Import["C:\\Users\\Hellmut Kohlsdorf\\Pictures\\foto Carina con Velas.jpg"]

El resultado en la foto:

24304205659_62c68e7e92_c.jpg


La próxima foto muestra esta girada por 10 grados:

24578981331_8dc9be0792_b.jpg


Existen además opciones para la sentencia del lenguaje "Wolfram Language" con el atributo "crop" se puede borrar el fondo por ejemplo dejando solo la imagen girada.

Así ya he podido verificar que el lenguaje disponible en la placa raspi con la software gratuita "Wolfram Language" tener la funcionalidad sin crear los "huecos"! Claro, tengo que poner el esfuerzo de aprender eso del "crop". Pero me he decidido por hacerlo en el entorno de la placa Raspi cuando haya echo los trabajos para poner mi entorno. Pero si por ejemplo en el caso de la brújula consideran que la parte del centro que gira es circular ya esos bordes no ocurren, al menos eso pienso que lo podré lograr.

Ya me empiezan a ocurrir usos de esto! Imagínense si monto una placa raspi con una pantalla en mi emisora de R/C, claro protegido de la intemperie, entonces podría ser posible ver la imagen de la brújula actualizada por los datos recibidos por ejemplo por WiFi desde el modelo mientras este navega!
 

Adjuntos

  • Imagen Importada.jpg
    Imagen Importada.jpg
    95.8 KB · Visitas: 5
  • Imagen girada 10 grados.jpg
    Imagen girada 10 grados.jpg
    114.9 KB · Visitas: 5
Me encontré con otro reto, cosa que tiene como efecto lateral, me mas aún me meto en lo de Linux y en ciertos detalles de la hardware!

Mi configuración de la hardware es la placa Raspberry Pi B+, una microSD de 8 GB y un disco duro de 1 TB conectado al Raspi por USB.

El problema resulta cuando quiero expandir la partición de datos, ahora en el disco duro. Se suma a ello que quiero hacer esto con la versión actual de Raspbian, la versión Jessi.

No tuve problemas al instalar en el pasado la versión Wheezy del Raspbian 100% en un microSd de 32 GB. Efectivamente el programa de configuración, raspi-config, ofrece esta funcionalidad expandiendo la partition de datos, por lo general la partición 2 para usar el total restante de la microSD.

Tampoco tuve problemas copiando la imagen de Raspbian Jessie al disco duro formateado con FAT32. Luego hay que copiar ciertos archivos a la boot partition de la microSD y modificar el texto en un archivo para registrar que el Raspbian encuentra el resto de los datos en el HDD conectado al USB. La rutina de inicialización del Raspi exige encontrar ciertos archivos en la boot partition de la microSD. Después recibe la información para seguir la inicialización del Raspbian con los datos que encuentra en un archivo que se tiene que copiar del HDD a la boot partición de la microSD. Como modifique la dirección todo funciona perfecto.

Mi Raspi con la versión del Raspbian Jessie es iniciado y aparece la nueva GUI, bastante mas sofisticada que la de la versión Wheezy! El problema ocurrió al querer expandir la partición de datos para incluir el resto del disco duro de 1 TB! Para hacer esto, lo que no funciona con la rutina que se utiliza para la microSD, en el Internet y en 2 libros que tengo se encuentra la forma de hacerlo. El problema es que tanto mis libros, como en el Internet no se encuentran tutoriales para expandir la partición de datos usando el Raspbian Jessie! Lo que me pasó, es que mi Raspi es inicializado y cuando debería aparecer la GUI en la pantalla, esta queda en negro y solo en la esquina superior izquierda de la pantalla aparece la imagen del cursor bölinqueando de forma irregular.

Mis investigaciones me llevaron a descubrir que existen 2 tipos de tablas de partición. La antigua "MBR" para la cual se utilizan ciertas sentencias y la mas moderna llamada "GUID". Ambas tablas son definidas por Microsoft y la GUID entre otras permite usar discos duros mas grandes. las preguntas ante las cuales me encuentro son:

1. Como reconozco si la partición en un disco duro es MBR o GUID? Ya he encontrado que tambien en la versión GUID existe una tabla MBR especial que tiene como objetivo permitir entornos viejos adaptarse al uso de la tabla GUID. También he encontrado informaciones de como poder identificar la tabla conectando el disco pre-formateado al ordenador con Windows.

2. Si una MBR o una GUID es usada, esto lo determina el sistema operacional o esta definido por el formateado del disco duro?

3. El listado de como expandir la partición de datos en el disco duro o flash stick es adecuado cambiando las sentencias como por ejemplo "fdisk" or "gdisk" y de la misma forma las otras?

4. Alguien ya tiene experiencia en este campo?

Un cordial saludo
 
Sigo reportando de mis investigaciones. Desafortunadamente mi salud los últimos días a impactado tanto mi habilidad de investigar y estudiar como el experimentar las cosas que voy descubriendo. Como siempre una situación como esta resulta en mi deseo de estudiar mas a fondo nuevos campos de conocimientos. Así ahora voy por aquí:

1. El desarrollo de las tablas de particiones por un lado resulta por la limitación que resulta de solo tener 32 bits para poner la dirección de un bloque en el medio de almacenamiento que da la bien sabida limitación de 2 TB para el tamaño del medio de almacenamiento de datos, sea una SD o microSD, sea un stick de memoria USB o sea un disco duro.

Las tablas de partición según el concepto MBR, "Master Boot Record", es el sistema que data desde los tiempos del DOS.
Las tablas de particiones GPT, "GUID Partition Tables", "Global Unique Identifier" fue adoptado primero por Apple en sus productos en 2005 y el PC dio ese paso en otoño del 2012 con Windows 8. Sin embargo también hay PCs mas antiguos que eran GPT compatibles. Para capacitar la compatibilidad con sistemas que se esperan una tabla de particiones MBR la tabla GPT empieza conteniendo los datos de partición de acuerdo al sistema MBR. Junto con ese cambio tambien se hizo la migración de los BIOS tradicionales al sistema nuevo llamado EFI. Así las tablas de particiones GPT pueden ser utilizada en sistemas con un BIOS tradicional. EFI esta para "Extensible Firmware Interface" y UEFI para "Unified Extensible Firmware Interface".

Esto según lo entiendo es de importancia, a pesar que el objetivo es usar Raspbian Jessie en la placa Raspi, porque para inicializar las memorias del Raspi se necesita otro ordenador, preferiblemente Windows. Mi ordenador ya es bastante viejo, tiene un BIOS del 2009, pero aparentemente es capaz de reconocer y usar discos duros con tabla de particiones GPT.

Otro aspecto que he estado aprendiendo se refiere al formato de formación del disco duro. El formato nativo de Linux aparentemente se llama ext4, pero requiere de un sector con formato FAT32. Si se forma la partición del disco duro y se desea que se pueda tener acceso a ella desde Windows lo normal es formatear esa partición 2, la partición de datos también usando FAT32.

El formato "ext4" de Linux, similar a las propiedades del formato NTFS, permite grabar datos adicionales que capacitan al sistema operacional una mayor seguridad del medio, fuera de lo de los límites de tamaño. He encontrado referencia que es posible capacitar Linux y Raspbian en especial aquí, para también poder utilizar particiones formateadas con NTFS.

Estas informaciones y mi estudio a largo trecho de ser completado de forma inicial de mis libros sobre Linux y el Raspi me están haciendo reflexionar sobre como sería la configuración de particiones y de su formato mas sofisticada y en consecuencia útil para mí. Recuerden que mi disco duro tiene 1 TB de capacidad y que el tamaño de la partición de boot en ese disco duro es de unos 100 a 200 MB.

No sería sensato formatear la partición de datos en ese disco usando "ext4" como formato nativo de Linux, tener una partición formateada en "NTFS" para poder intercambiar datos con el PC bajo Windows?

Otro idea que se está cristalizando en mi mente es la de hacer la instalación del Raspbian Jessie para la Raspi con varios pasos intermedios, pudiendo así verificar que he comprendido y puedo aplicar los conocimientos sobre Linux? La idea sería empezar instalando el Raspbian Jessie exclusivamente en mi microSD de 32 GB. Luego desde el entorno del Raspbian en la placa Raspi crear las particiones y formatear estas de acuerdo a las ideas que presenté arriba usando por ejemplo Firefox o Chromium como web browser para bajar del Internet las herramientas requeridas. Me parece que el entorno de Raspbian me permitiría usar las reconocidas capacidades de las herramientas disponibles allí.

Lo que tendría que analizar adicionalmente es el impacto que esto tendría en usar la IDE de WingWare, Wing, para programar y hacer los "debug" desde el entorno del PC.
 
Hola amigos
Me encuentro en el proceso de aprender como logro el objetivo que me he puesto y que presento ahora aquí:

Quiero desarrollar los programas para el Raspi en el PC y de ejecutar y "debug", búsqueda de errores y su corrección , usando una IDE en el ordenador. 2 IDEs se encuentran actualmente en el PC mio y los estoy estudiando:

1. Wing de Wingware
2. PyCharm de Jetbrains

Empecé usando Wing no mas familiarizándome con al herramienta y ahora lo interrumpí para estudiar PyCharm con la versión profesional en tiempo de 30 días disponible. La razón para esto es por un lado que para realmente entender el de como ejecutar programas escritos en Python 3 en un editor, parte de la IDE en el ordenador, dejando la ejecución del programa Python ser hecho por el interpretador Python en la Raspi. PyCharm hace esto realmente ejecutando el programa no en el PC, sino realmente con el interpretador de la Raspi en la Raspi. Para ello, al iniciar un proyecto se define que el interpretador a usar es el que se escoge libremente, sea en el PC, máquina local, o remoto. Allí se define en mi caso que quiero usar el interpretador en la Raspi. Para ello es necesario establecer el enlace entre la IDE PyCharm en el PC con el interpretador en la Raspi. El medio a usar es "ssh" y "SCP". Me varé estos últimos 2 días por falta de conocimiento tanto de "ssh", como del uso de "llaves" privada y pública.

Así por un lado me puse a estudiar la literatura que tengo tanto sobre Raspi Raspbian y sobre Linux. Durante estas investigaciones aprendí que una vez que la Raspi sea accesible desde el Internet hay que dedicar esfuerzo para evitar abrir puertas a ataques desde el exterior y que pudieran utilizar esto para acceder nuestra red en la casa y sus PCs!

Pues bien, actualmente he aprendido como, de forma relativamente sencilla se generan las llaves privadas y públicas en el Raspi bajo el os Raspbian. Por otro lado acabo de descubrir para mi el como crear las llaves en el PC y de ponerlas en un lugar definido por mi.

El paso que tomaré después de lograr que la IDE PyCharm en el PC pueda ser configurada a usar el interpretador Python 3.4 del Raspi, dedicaré mis estudios a entender como hacer que la comunicación tengan lugar dentro de un "túnel" "VNC", Virtual Network Computing", conexión virtual de redes. Me explico. existe en el Internet la posibilidad de conectar 2 o más PCs y/o redes de PCs como si estos estuvieran físicamente en el mismo cuarto, creando un túnel VNC entre las redes o PCs y que las comunicaciones tengan lugar atravesando ese túnel estando así protegidas de ataques.

Sigo ahora primero estudiando como se reparten las llaves, privada y pública entre la Raspi y mi PC con Windows 7 Ultimate. Luego ya entendiendo esto seguiré con mis intentos de relacionar la IDE de PyCharm al interpretador del raspi! Aquellos de Ustedes que ya saben de esto, perdonen por presentar lo obvio. Pero es que yo no sé eso y me puedo imaginar que alguno de mis lectores de este hilo son tan sabios como yo! ;)

Una vez que haya entendido esto lo presentaré aquí con fotos. Pero es que hay gran trecho entre "lograr" un objetivo como el aquí presentado y el "entenderlo tan bien" que yo pueda presentarlo aquí!
 
Bueno amigos, mis avances son ultra lentos, pero quiero compartir lo que voy aprendiendo pasito por pasito!

1. Desde que uso la placa raspi con la versión Jessie del Raspbian mi conexión al Internet por WLAN dejó de funcionar. Aquí el como resolverlo! Quiero recalcar que antes con la versión "Wheezy" del Raspbian la conexión de WLAN a mi red casera y de allí al Internet funcionaba de forma automática. Hice muchos análisis y experimenté cambiando de módulo WLAN para USB!

"sudo iwlist wlan0 scan"

25256127945_46069be64b_c.jpg


En la foto pueden ver como entré la sentencia en mi Raspi y que respuesta recibió:

ESSID:"Internet"

Si miran la imagen pueden ver la línea que he escrito arriba e "Internet" es el nombre de mi red WiFi!

IE: IEEE 802.11i/WPA2 Version 1

Este renglón que aparece en mi pantalla representa describe el método usado para la autentificación en mi red "Internet"! Autentificación es el término que se usa para describir el proceso por el cual me identifico en la red WiFi y que evita que personas no autorizadas puedan accederlo! El método WPA2 es el método moderno y mas seguro.

El próximo paso es editar un archivo que al iniciarse el raspi también inicia la interfaz "WiFi:

"sudo nano /etc/wpa_supplicant/wpa_supplicant.conf"

Confieso que yo no uso nano, si no que me voy por el camino mas seguro para mi. Uso el editor "LeafPad" que viene con la versión Raspbian "Jessie"! y que se puede abrir o reemplazando en el renglón arriba "nano" con "leafpad". El archivo a editar tiene el nombre de "wpa_supplicant.conf". Para poder editarlo hay que hacerlo como administrador por lo cual el renglón se inicia con "sudo"!

network={
ssid="Internet"
psk="Password"
}

Una vez abierto el archivo aparecen algunas líneas y los 4 renglones de arriba aún no deben existir! Esos 4 renglones hay que escribir en el archivo al final de este.

Como pueden ver Aparece el nombre de la red WiFi, ustedes deben entrar el nombre de su entorno que apareció en la pantalla del raspi al entrar el primer comando y que aparece allí después del SSID! "psk", allí entran su clave. Como bien se pueden imaginar no lo publicaré aquí!

Una vez que grabaron el archivo con estos 4 renglones su sistema debería conectarse a la red WiFi!

Dejo por fuera la descripción de como inicializar su placa raspi. pues asumo que esto ya fue hecho. vale recordar que para abrir la pantalla de configuración inicial siempre puede volver a abrirse usando la sentencia:

"sudo raspi-config"

24629833283_8b82f35a6e_c.jpg


Como estoy seguro que ya lo saben:
El punto "1" aumenta el tamaño de la partición en la memoria micro-SD para que la partición ocupe todo el espacio restante disponible en la micro-SD. Algo importante para evitar que el sistema falle por falta de espacio utilizable en la microSD. >La raspi apoya microSD de hasta 32 GB y las de máxima velocidad, hoy es "categoría 10". Vale mencionar que mis investigaciones en el Internet dieron como uno de los resultados que es importante asegurarse que la calidad de la microSD sea alta. Mejor gastar un poco mas de dinero en su compra. También el máximo de velocidad es importante, pues es la velocidad de leer y escribir del y a la microSD que tiene gran impacto para la velocidad de ejecución de la placa raspi!
El otro aspecto importante usar un fuente de energía de fuerte para evitar que la placa muestre problemas en su función. Yo actualmente uso la de 2A! tengo la intención de cambiar de usar esa fuente y alimentar mis placas exclusivamente de mi fuente de alimentación de mi laboratorio que basa en una fuente de PCs de 600W. Aún estoy reflexionando como adaptar mi laboratorio con este objetivo! El asunto es que ciertas placas necesitan ser alimentadas de una fuente estabilizada, por eso la fuente de un PC, con 5 VDC como es el caso para las placas Raspi, los circuitos externos que conecto a mis placas Raspi solo con 3.3 VDC porque las GPIO no resisten 5 VDC. Otras placas que iré agregando a mis estudios, las del tipo "LPCXpressoxxxx" requieren también 3.3 VDC!
Como es bien sabido la ley de "Murphy" define que la probabilidad de error es cuanto mayor cuanto mas estragos cometa el error! Así estoy pensando como ingeniarme de diseñar unas tomas de alimentación que permitan alimentar varias placas a la vez ciertas tensiones y que la probabilidad de conectar de forma errónea sea mínima!

25138841922_68d8630e4e_c.jpg


Como pueden ver en esta foto mis esfuerzos para poder hacer los experimentos que requiero hacer para lograr mis objetivos! La foto muestra a placas de madera que conforman 2 elementos que usaré en mis experimentos. La ya mostrada componente con la protoboard y los 4 bujes, negro tierra, rojo 5 VDC, amarillo 3.3 VDC y verde los 12 VDC! todavía los colores no corresponden a los colores correspondientes en el listón de alimentación de mi laboratorio:

14005504208_f61b9ecbca_c.jpg


La segunda placa tiene montados ya de forma fija mis 2 placas raspi, la B+ y la 2B. tengo 2, porque al poco tiempo de comprar la B+ salió la 2B y el precio tan bajo me hizo decidir comprar esta. Así ahora puedo también usar este entorno para aprender cosas que se beneficien de poder implementar las comunicaciones entre estas 2 raspi!
Las 3 placas de color blanco son el kit de evaluación mas actual de la empresa Trinamic, proveedor de mi control de motores de paso. Son la próxima generación después de la placa "stepRocker" que usé para mi tutorial avanzado sobre motores de paso en este foro! la gran ventaja de esta nueva versión es que la placa en el centro de las otras 2 permite acceder y observar todas las interacciones entre la placa de arriba, que contiene la componente del "controlador de motores de paso" la placa aquí de abajo que contiene el controlador ARM Cortex M4 de la antigua Freescale, hoy NXP! Tengo 2 analizadores lógicos:

25231236786_22cef97f6b_c.jpg


25139323592_7c64e58017_c.jpg


La razón de tener ambos analizadores lógicos tiene que ver por un lado por lo lento que soy capaz de avanzar en los trabajos de mi laboratorio por razones de salud y de allí que el desarrollo tecnológico sigue. Por otro lado el "Logic Sniffer" representa una herramienta barata teniendo en cuenta de lo que es capaz de hacer me convenció entonces comprarla. Una cosa de la que nunca pensé sería alguna vez en la posición de tenerlo. Por otro lado el "Logic Analyzer" es una herramienta multifuncional desarrollada por la empresa "Digilent Inc" y la empresa "Analog Devices". La conocí como parte de mis esfuerzos de estudiar electrónica análoga haciendo el curso gratuito disponible. Resulta que en lugar donde existía el curso "Real Analog - Circuits 1" ya no está. Pero buscando por Google se encuentra! Hasta mejor, se encuentra el curso 2 también y ademas una otra versión en el sitio de "Analog Devices"!

Volviendo a la foto de mi entorno de experimentos en mi laboratorio electrónico, adicionalmente a las 2 placas raspi y al kit de evaluación de Trinamic para motores de paso puse mis placas "LPCXpresso"! Así, una vez que haya aprendido como es la comunicación entre las 3 placas de Trinamic usando los analizadores lógicos entre otras muchas cosas, estudiaré como reemplazar la placa del controlador ARM Cortex de Trinamic con mis placas LPCXpresso. Probablemente pase al otro mundo antes de alcanzar estos objetivos. Pero el tiempo hasta entonces es rico en retos, rico en experimentar y rico en aprender!
 
Hola amigos, al volver a mirar la imagen en la contribución anterior donde en un módulo puse el protoboard, en otro monté las 2 placas Raspi que tengo, Raspi B+ y Raspi 2B, y tratando de ver como alimentar las placas y como tener control sobre cuales placas alimento y con que tensiones, mas el cableado que resulta de las 2 fuentes de alimentación conectadas a las microUSB correspondientes, el cableado a la pantalla para las Raspi, el cableado de hacer disponibles las tensiones al protoboard y el acceder las fuentes de tensión de mi listón de tensiones, mi mesa de trabajo empezó a ser similar a una tela araña. Si se considera aplicando la ley de Murphy que si es posible dañar placas por conectarlas a la alimentación eléctrica correcta esto va a ocurrir, empecé a reflexionar como mejorar el entorno!

Por un lado activando el server de SSL en las placas Raspi es posible usar una ventana en mis pantallas de Windows 7 para poner los "Desktops" de las placas Raspi allí y así economizar el cableado correspondiente. WiFi es la infraestructura sin cableado.

25491775351_8dd9cfac4d_o.jpg


El próximo paso fue el de "modernizar" el módulo que aquí en la foto muestro como esta atornillado a la pared lateral de mi laboratorio. esta primera versión permitía conectar 4 lineas independientes usando cables con enchufes banana a los bujes verdes y tener 5 enchufes hembra para atornillar cables de alimentación asignados a cada una de los 4 bujes. Estos enchufes atornillables solo son para el polo positivo. A la izquierda puse 12 enchufes atornillables a las que conecto tierra! El módulo a la izquierda lo construí para conectar mis cargador de baterías que usa esas pinzas con que se puede conectar a baterías de plomo. Ven los 2 tornillos M10 que reciben las pinzas y debajo 2 bujes, negro y rojo, donde aplico la tensión!

25288732630_8720963a8a_c.jpg


Esta foto muestra el panel que estoy armando. Equivalente al módulo de primera generación cada "línea" consiste de 1 par de bujes con su interruptor que permite activar o desactivar la alimentación eléctrica correspondiente. Faltan aún las LEDs RGB que acabo de ordenar de la China. Siempre una ira al lado derecho del interruptor. Voy a codificar las tensiones usando bujes de cierto color para cada una de las tensiones:

25465883282_c8332bdb2e_o.jpg


Así conecto por cable que estoy poniendo oculto a la vista las tensiones que tengo disponibles en mi listón de alimentación eléctrica:

-12 VDC, -5 VDC, Tierra, +3.3 VDC, +5 VDC, +12 VDC y +24 VDC

Adicionalmente voy a hacerlo posible conectar a un par de los bujes la tensión de hasta 40 VDC que me dan las baterías recargables de LiFePO4. Por eso 8 sets de bujes, interruptor y en el futuro la LED multicolor indicando cuando el interruptor esta en posición activa, la tensión está disponible en el buje superior y en los 5 enchufes atornillables. Los bujes inferiores siempre están activos, siempre y cuando la fuente de PC modificada esté encendida! Tengo pensado usar una LED para indicar que el panel está siendo alimentado!

La ventaja así es que en vez de tener todo el cableado entre el listón de tensiones y este módulo, la alimentación ocurre por un cableado fijo oculto para cada una de las tensiones! La otra ventaja es que puedo decidir cuales tensiones requiero para un experimento y solo activar estas, las LED RGB correspondientes se iluminan. Los interruptores me dan esta posibilidad.

24953869974_863b04e716_c.jpg


Aquí el panel visto desde abajo! Los bujes que aquí aparecen arriba son los de la otra vista del panel los de abajo y correspondientemente los de abajo! pero como siempre los problemas se identifican mirando en los detalles!

24959100233_4c43a180a3_c.jpg


Aquí los conectores a usar. En la foto del panel pueden ver como tentativamente usé el conector de la última imagen, arriba y a la izquierda. El conector color latón es el que pongo en los cabos de los cables que conectan las tensiones del listón a los bujes. Hay uno de estos conectores hembra en cada cabo de los cables! y pongo un conector del tipo a la izquierda abajo allí de donde saco la alimentación eléctrica. Así la conexión original queda sin modifican pero tengo ese enchufe macho para conectar el cable que va al panel.

Evidentemente el conector usado en el panel tentativamente es inadecuado! Necesito adicionalmente conectar el buje a uno de los polos del interruptor. Por eso el conector abajo y a la derecha es adecuado! De un lado conecta el cable que trae la tensión del listón de tensiones, y con un enchufe hembra correspondiente uso un cablecito que conecta el buje con el interruptor!

En el otro buje, aquel arriba en la vista de enfrente del panel también requiero de las 2 conexiones! La una para conectar el buje al otro conector del interruptor y la otra para conectar a los 5 enchufes hembra atornillables.

Pero no es todo esto! Necesito poner la LED RGB entre el buje superior del panel visto de adelante y un cableado de tierra que tengo que tener disponible para cada par de bujes. Así tengo que determinar que valores de las resistencias que controlan la cantidad que fluye pasando por cada elemento "R", "G" y "B" para tener como resultado que la LED se ilumine con el valor de color deseado! El determinar el circuito y los valores de la resistencias, siendo la tensión otra en cada par de bujes será un agradable ejercicio con el protoboard.

Claro, exagerado como soy tan bien reflexiono si no uso un µControlador con muchos PWMs para generar el color! Tengo suficientes AVR atmega8 en mi inventario! Además ese camino me ofrecería la posibilidad de determinar la tensión actual en todo momento y el valor de la corriente que fluye!

Como ven por mi forma de proceder hasta este aspecto lateral de mi laboratorio electrónico ofrece interesantes posibilidades!
 
Hola amigos, finalmente llegaron los primeros 4 tipos de parte que compré en Conrad. He estado pensando en que orden presentar las fotos y las explicaciones. Me he decidido empezar por el final, el estado actual de cosas:

25382122800_ba8e1d9a16_c.jpg


25382492970_3efb1f524c_c.jpg


25382514180_ed6cb37ce3_c.jpg


25382753880_bb15e2bced_c.jpg


La primera foto muestra el panel con los 2 conectores machos soldados a las bujías. La intención, como le escribí la última vez es poder conectar 2 cables con enchufes hembra. Para poder soldar esos conectores al alma de las bujías taladré un hueco en un madero de tal forma que me sea posible depositar el conector como lo muestra la próxima foto. Me costo varios intentos realmente taladrar a ese punto, me pasaba. Así al soldar el conector primero puse el soldador sobre la punta de la bujía aplicando un poco de estaño al soldador. Así, cuando el estaño se escurre sobre el alma de la bujía esta es lo suficientemente caliente para aceptar el estaño y hacer una conexión eléctrica buena. Cuando el alma de la bujía, siendo grande en comparación al conector no es calentado lo suficiente entonces el estaño queda formando una gota, en el otro caso se escurre limpiamente como se ve en la primera foto creando una conexión eléctrica de buena calidad. El termino para el mal estado es una soldadura fria, al menos traduciendo literalmente!

La otra foto muestra el conector antes de ser soldado!

Me quedaba la impresión de no haber reflexionado totalmente para definir la solución! Las LEDs RGB, capaces de generar cualquier color, no llegarán antes de unas semanas. También las soldaduras usando estaño no son capaces de resistir estrés mecánico como ocurre aplicando y removiendo los conectores hembra que irán conectadas a los 2 conectores macho de cada bujía. Por lo tanto requiero trabajar de tal forma y secuencia que en lo posible no tenga que desconectar los enchufes para no dañar la soldadura! Por otro lado quiero usar el panel antes de que lleguen las LEDs. Pero si conecto los cables que vienen del listón de tensiones, o no puedo volver a poner el panel sobre mi mesa de trabajo para la instalación de las LEDs y quien sabe que otras cosas se me ocurran. Recuerden que esto ya es el panel versión 2!

El problema no es el como implementar soluciones, lo que consume mucho tiempo, al menos así me ocurre a mi, es identificar posibles problemas! Así lo que he decidido es que voy a hacer una caja de distribución en tal punto cercano al módulo del panel que pueda desatornillar los cables que vienen del panel, dejando aquellos que vienen de la fuente atornillados.

También he decidido que le pondré al panel bujes con tierra adicionales para tener disponibles bujes banana por si os requiero. Además voy a poner una LED roja que indique si el panel está siendo alimentado del listón de tensiones. La razón es que quiero economizar el consumo de energía eléctrica solo encendiendo la fuente de PC modificada cuando la necesite. Entonces y solo entonces esa LED roja estará iluminada indicándolo!
 
Injustificadamente mi contribución poniendo unas preguntas sobre el RaspBerry Pi Zero fue cerrada. Por eso repito mi pregunta aquí, aunque realmente tiene más que ver con mi taller que con este proyecto específicamente. Me beneficio por haber seguido investigando el tema en otras partes por ser censurado aquì!

El RaspBerry Pi Zero, que aparentemente se ofrece a precios entre los 5 USD y 14 Euros, a tenido tal recepción positiva que los inventarios en todas partes ya no tienen producto. Ojalá vuelva a haber inventario lo antes posible. Mientras tanto voy a usar mi Raspi B+. Lo quiero usar en conjunto con AVR mega8 controladores para controlar el color de 8 LEDs RGB con cátodo y al tiempo monitorear el valor de las 8 tensiones y la corriente que fluye por cada una de estas tomas que mi panel puede manejar.

Son 3 PWMs por LED para un total de 24 PWMs y 16 ADCs para monitorear las tensiones y corrientes. eso sobrepasa lo que el RaspBerry Pi puede hacer, verdad?

La razón por la cual debe ser una Raspi encargada de manejar todo lo relacionado al panel es que así, beneficiandome de los trabajos que hago con la Raspi en el contexto de este proyecto de poder controlar el Raspi del panel que conectaría a mi LAN local por WiFi y que usando TightVNC resulta en una ventana del PC mostrando el desktop del Raspi del panel! Todos los trabajos de programación y de resolver errores, debugging, los haría desde el PC usando PyCharm!

Así, mi flamante Panel, sin requerir su propia pantalla o display podría generar un GUI en una ventana del PC donde me mostraría los datos de tensión y corriente y donde podría "jugar" con los colores de las LED RGB!

Así pues comparto con Ustedes los resultados de mi investigación sobre el Raspi Zero para mi panel como parte de mi taller. Pienso, ya que estoy obligado a meter este tema en este hilo, presentar fotos y progresos en este otro proyecto aquí!
 
Última edición:
Estoy avanzando con el panel para llegar al punto de poder utilizarlo para empezar a experimentar con la LED RGB y luego con la Raspi y PWM para poder controlar el color de la LED RGB.

25832939655_945d25e427_c.jpg


Quiero mostrar aquí el como procedo con el cableado del panel. A la izquierda esta el listón de bujes atornillables y de allí van los cables coloreados a sus respectivos enchufes. Por ser el mejor visible tomo el de color rojo, +5 VDC, los otros 3 son:

verde: -12 VDC
blanco: -5 VDC
azul: + 3.3 VDC
rojo: + 5 VDC

La alimentación del par de bujes asociado a la tensión de +5 VDC, rojo, es conectado a la izquierda abajo, lo que es el buje inferior. A la inmediata derecha vemos el cableado a una de las conexiones del interruptor y por encima el cableado que une el otro polo del interruptor al buje superior, enchufe a la izquierda en la foto. Allí use el conector especial que me da otro conector. Ese conector adicional lo vemos a la izquierda de donde conecta el cable que viene del interruptor. Allí conectaré la LED y su circuito que indicarán de forma visual cuando el buje este activo a razón de la posición del interruptor! A la derecha vemos el segundo conector del buje superior. Allí conectaré los 5 enchufes atornillables asociados a esta tensión.
 

Adjuntos

  • Conexiones del panel1.jpg
    Conexiones del panel1.jpg
    148.7 KB · Visitas: 6
Atrás
Arriba