Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Buenas a todos, me llamo quique y soy nuevo por el foro...escribiendo, por que llevo mucho tiempo leyendolo.
Me he arrancado a escribir por que estoy realizando mi proyecto fin de carrera (estoy terminando mis estudios de ingenieria industrial).
Mi proyecto consiste en la construcción de un microrobot. Este microrobot cuenta con una placa, bueno en realidad son dos. La primera se utiliza para el control de los motores y los sensores del robot y la segunda es el cerebro digamos. De la primera no tengo problema ya que tengo los planos ya que voy a utilizar los planos de la sky293, una placa desarrollada para el skybot, un robot de caracteristicas similares al mío en la autónoma de Madrid diseñado por obijuan, miembro de este foro.
El problema viene en al segunda placa, voy a utilizar para controlarla un micro pic 16f876a, y para conectarlo al pc un usb. No es necesaria la conexión por rj11 para la programación ya que vamos a utilizar un bootloader para poder cargar los programas por usb. Vamos a utilizar un conversor usb-serie (ft232rl de ftdi ) para poder conectarlo al pic y luego una serie de conectores bus de 10 pines para poder conectarlo con la placa antes mencionada.
El robot se va a conectar al pc mediante un módulo de radiofrecuencia, en concreto uno que distribuye microchip y del que ya se ha hablado en el foro. El módulo en cuestión es el mrf24j40ma. Lo tengo desde hace 1 mes...y sinceramente no he sido capaz de hacer nada más que jugar a encender y apagar luces con el entre las placas que acompañan a los módulos. Las placas que acompañan a los módulos son parte del kit picdem que trae dos módulos completos y dos placas con un 18f4620 para poder trastear un pcoo con ellos...pero no he conseguido nada.
En definitiva estoy bastante atascado por que no se que hacer con los módulos ni nada si alguien me pudiese ayudar le estaría muy agradecido.
Un saludo y perdón por todo el rollaco pero entiendo que cuantos más datos dé mejor se entenderá mi problema. Si necesitais algun dato más o los planos o lo que sea pedidmelos y os los proporciono encantado.
Para esa potencia de cálculo también está la beagleboard, que con un DSP es bastante más capaz, y cuesta incluso menos:
http://www.beagleboard.org " onclick="window.open(this.href);return false;
aún así, y dada la utilización, los SO como el linux o guindous trabajan en 'tiempo irreal' y no me parecen más adecuados. La solución ante tales 'prisas', suele basarse en otros sistemas algo más complejos, habitualmente FPGA's y similares, que tienen bastante más potencia de cálculo para estos menesteres. Claro que con el Sr. Hardware hemos topado, y sin librerías.
La CMUCam 3, tal y como han confirmado, lleva un ARM7TDMI de Philips, de los de antes de NXP. Hoy por hoy sigue siendo algo muy cañero (hasta 72MHz - MIPS, alrededor de 50MIPS reales), pero dada su falta de soporte interno para DMA (si la memoria no me falla) y para otras 'delicatesen' que mejoran las prestaciones, aún podría ser mejor (llámese Cortex M3, como el STM32 de ST, o el nuevo SAM3 de Atmel). Eso sí, si sabes programarlo, tienes todos los recursos para tí solo, sin tener que compartir nada con el (IT)SO.
Bueno, siempre puedes instalar un S.O. en tiempo real. No obstante por las pruebas que he visto en la BaegleBoard con OpenCV no se obtiene buen rendimiento, principalmente porque no se hace uso del DSP y creo que tampoco de la unidad NEON de cálculo, ya que para eso se necesita usar precisión simple y creo que OpenCV usaba otro tipo de datos (presumiblemente de precisión doble).
Una de las cosas que tengo como pendientes es portar las rutinas más básicas de OpenCV al DSP de la beagle board (que por cierto es un TMS320C64x+, ahí es nada), con eso se debería de aumentar el rendimiento muchísimo. De todos modos, para que os hagáis una idea de la diferencia de usar el DSP a no usarlo os dejo un video de una empresa española que fabrica una placa basada en la BeagleBoard:
smBHyXLZ5uQ
Jeje, creo que ya llegamos otra vez a la madre del cordero; me explico. Presumo que la libreria openCV está pensada para trabajar en entornos "experimentales" pero no a nivel de produccion. Si haces un programita en .net o visual basic o devcpp con la librería, si va muy lenta la cosa, pues te compras un pc más potente y ya está; es que tu ordenador es "lento".
Así lo que se fomenta es el "consumismo" y la "no exigencia" de que un software haga su cometido mejor. En muchos casos, y sin entrar a ver el código fuente, añadiendo flags al compilador para que alinee el código a la plataforma destino y desenrrolle bucles, se pueden alcanzar mejoras sustanciales, y el programa que no "rulaba" bien en tu pc va mejor o ya cumple con los requisitos.
Si el paso anterior es opcional para un pc, para un sistema empotrado es "mandatory" . El compilador ha de ser muy bueno para explotar todo el hardware con un software "genérico" ( véase MMX,SSE, etc los compiladores siempre van detrás de los fabricantes). Además, las librerías siempre suponen un "overhead" que es difícil de salvar.
Por lo que yo tengo visto, para muchos algoritmos de VA se puede trabajar en aritmética entera, y para temas màs complejos se necesita como mucho simple precisión ( fft,autovalores, autovectores, resolución de "constraints" y demás matemáticas).
Efectivamente, por eso la unidad NEON cobra todo su sentido en esta plataforma. La beagle board trae una VFPU que tarda del orden de los 20-30 ciclos de instrucción para los cálculos, sean del tipo que sean, si solo requieres precisión simple entonces tira de la unidad NEON que hace las operaciones a razón de 1 o 2 ciclos de instrucción. El compilador GCC trae soporte para todo esto, aunque también depende de si tu código se puede almacenar en forma de vectores, que no siempre es posible.
De todos modos, lo de las librerías por supuesto que es así, pero también hoy día lo que prima es la rapidez de desarrollo. Yo personalmente prefiero que gaste tiempo la CPU antes que yo, ya que mi tiempo es muy valioso. Esto por supuesto dentro de las limitaciones de la aplicación, ya que si tienes unas exigencias habrá que cumplirlas y puede que entonces toque optimizar y demás.
¡Un saludo!
Buenas de nuevo chicos vuelvo a molestaros retomando el tema de la comunicacion inalmabrica...me gustaria leer en el pc a traves de los modulos de radiofrecuencia que poseo(mrf24j40ma) un sensor en mi placa y no tengo muy claro como he estado investigando y creo qeu seria utilizando la fujncion GetShortRAMAddress pero no lo tengo muy claro, alguien podria echarme un cable?<Por pequeño qeu sea estaría muy agradecido
gracias
saludos
Buenas de nuevo chicos vuelvo a molestaros retomando el tema de la comunicacion inalmabrica...me gustaria leer en el pc a traves de los modulos de radiofrecuencia que poseo(mrf24j40ma) un sensor en mi placa y no tengo muy claro como he estado investigando y creo qeu seria utilizando la fujncion GetShortRAMAddress pero no lo tengo muy claro, alguien podria echarme un cable?<Por pequeño qeu sea estaría muy agradecido
gracias
saludos
Solo puedo recomendarte que mires bien cómo funciona el tema de MyApp de Microchip y que te revises bien los documentos y ejemplos que te dan. Siendo para un PFC deberías de ser capaz de entender la mayor parte de lo que ahí pone.
Yo aún no he trabajo con estos módulos, por lo que poco puedo ayudarte más. Aquí tienes un hilo que puede que te sirva (aunque no usa un protocolo de Microchip, sino envío y recepción directa de datos): http://foro.webdearde.com/viewtopic.php?f=3&t=2821 " onclick="window.open(this.href);return false;
