Publicado por: Jimmy_pop en 11 de Septiembre de 2004, 09:09:00
El primer problema, el mayor problema, es q un robot así es muy dificil q obtenga informacion fiable y es q los metodos mas sencillos de obtencion de informacion de trayectoria son de bucle abierto, es decir no hay una compensacion del error q se comete de medida y es algo q se va propagando y se inestabiliza hasta convertir los datos en basura inutil. Los sistemas basados en vision artificial tienen la ventaja de tener una realimentació intrínseca q evita la propagacion de errores, no obstante son los cracks de consumir recursos como ladrones y ser mas complejos q meterla por el agujero de una aguja, otros metodos basados en sonars e historias varias se pueden refinar hasta el punto de elaborar por metodos estadisticos o redes de neuronas y interpoladores de muchas clases dan muy buenos resultados. No obstante nosotros íbamos a hacer algo bastante mas modesto y es q cuando tienes 2 meses para hacer algo... y es la 1a vez q tocas un microcontrolador y es la primera vez q soldas algo y es la primera vez q etc etc no estás para mandangas.
Qué hicimos? Usar un vehiculo con 2 ruedas motrices/directrices, el tipico robot mouse, con 2 motores independientes y dos encoders con una cierta precision. Y usando el microcontrolador Pic16f877 hicimos q se integrara la trayectoria por el metodo de euler (patillero) para saber por donde pasaba nuestro bicho. Esto se hacía con un bucle de control y toda una parafernalia q hacía q nuestro cacharro
se programara en distintas capas de software (siempre he querido tener la oportunidad de hablar de capas de software) hicimos una capa crítica de tiempo real q hacía todo lo serio y lugo una capa de aplicacion con una especie de interprete de logo donde se podia programar los algoritmos q debia seguir el bicho para moverse.
Los mapas consistian simplemente en un log de puntos registrados con informacion sobre colisiones. Se nos dio des de buen principio la orden de usar eso en un pc y así lo hicimos.
Nuestro robot iba conectado a un pc mediante un cable de serial, llamadle cordon umbilical q subministraba la corriente al bicho y además hacía de soporte de las comunicaciones con el pc. El pc actuaba pasivamente y se limitaba a recibir los datos de posicion q recibia del robot y elaborar un mapa q mostraba graficamente en pantalla.
Hicimos varias pruebas de algoritmos para recorrer el espacio. Y fue bastante guapo poderlo ver en el monitor en tiempo real como se movía (se veía incluso dibujo del robot representado como un rectangulo moviendose y girando en tr,.)
En fin una pijada. Al final se lo quedó mi compañero q era quien pagó la mayor parte del material :P y yo me quedé con los conocimientos y con ganas de hacer otro mas pequeño y mejor mecanicamente (había algun problemilla con las ruedas.)
Si os interesa ya escribiré otro dia comentando como se integraba la trayectoria pq es bastante interesante (con unos lookup de sin y cos).
Os dejo unas fotos donde se aprecia el bicho en 2 fases de su creacion y un detalle de la rueda y del encoder casero q montamos (solo 2 divisiones pero una reduccion q daba creo q 6 bits por vuelta de rueda).
see ya y hasta otra
foto1 foto2 foto 3
Publicado por: manex_1987 en 11 de Septiembre de 2004, 13:20:00
Yo tambien voy a hacer un robot tipo mouse (tengo ciertos problemillas porque no se que material usar, ni la parte mecanica, ni...) . Y el uso, al principio seria simple, pero quiero convertirlo en un robot que mapee un lugar.
Tengo bastante organizadillo el proyecto, y lo unico que me falta es el "empujoncito" con un hada magica que me de la carcasa del robot, y la parte mecanica... aunque no descarto "degollar" un juguete o usar piezas lego...
En mi caso, lo haria usando un 18F458, que, usando Pbplus, me proporciona aritmetica (sin,cos,tan,asin,acos,atan,exp,log,ln,x^y,sqr...) en coma flotante de la buena... con 4 decimales creo... (ni tablas lookup ni nada) y supongo que con 16K de memoria, y a 40mhz (10MIPS) no habra problemas de procesamiento...
Me gustaria poder usar un PIC16 de 18 pines... pero los PIC18 te proporcionan una velocidad y un rendimiento increibles.
Me has dado bastantes ideas al respecto de mi proyecto (que seguramente queda aparcado al empezar el cole, osea ya), espera mis consultas de robotica en este subforo jejeje.
sinmas, un saludo!
Publicado por: Carlete71 en 11 de Septiembre de 2004, 13:34:00
Interesante proyecto
Yo no he hecho robots, pero me gustaría.
Saludos,
Publicado por: wofer en 11 de Septiembre de 2004, 17:59:00
He construido un robot de 4 ruedas al ke me gustaria implementarle un programilla para ke pueda rastrear,pero estoy muy verde en ese aspecto.De momento lo unico ke hace es rodar "sin ton ni son" por casa evitando obstaculos.
Saludos!!
Publicado por: Jimmy_pop en 12 de Septiembre de 2004, 05:37:00
manex, yo tb he pillado una muestra de uno de la serie 18 atraído por la posibilidad de tener mas velocidad y mas intrucciones (yum
) No obstante te advierto que lo unico q haces es tener el doble de instrucciones por unidad de tiempo... eso está bien.. pero hablar del doble no es hablar de 4000 veces mas. Lo digo pq si bien los cacharros estos trabajan a alta velocidad y en algunas aplicaciones hay tiempo de sobras y se pueden hacer maravillas, cuando uno hace una aplicacion de tiempo real como controlar varios motores o hacer una integracion numerica en tiempo real para determinar la trayectoria y todo eso, necesita hacer una operacion ciclica cada cierto tiempo de tiempo pero lo mas rapido posible y muchas veces hay restricciones q te obligan a tener un bucle q dure muy poco y te caben entonces un numero limitado de instrucciones y parece que no pero a veces falta tiempo. Y claro, calcular un seno o un coseno con coma flotante en un bicho de estos, si bien es posible, es una quema de recursos bestial pero bestial de cojones, y yo sinceramente creo q hay q renunciar a eso.. y aun q sea menos comodo usar coma fija y usar alguna tabla.. q si la usas combinada con algo de interpolacion te da una precision bastante buena.Por otro lado, comentando lo de la integracion de la trayectoria. Yo lo que hice fue plantear la cinematica del vehiculo, es decir, teniendo en cuenta que el aparato se movía con 2 ruedas q podían girar a velocidades angulares distintas, deduje la ecuacion del movimiento q relaciona la velocidad del vehiculo en un momento determinado con la velocidad de rotacion de las dos ruedas. Eso da lugar a una ecuacion relativamente simple q te dice q la velocidad del centro del aparato en un determinado instante es ni mas ni menos q una suma de las velocidades angulares de las dos ruedas multiplicada por el radio de las ruedas y divididas por un factor constante q no recuerdo (la distancia entre ruedas creo). Y esa velocidad hay q proyectarla en una base vectorial solidaria al suelo de la habitacion para saber la velocidad respecto el sueloy poder sacar de ahí la posicion. Una vez obtenida esta expresion, se ve que para conocer la posicion del vehiculo en un determinado momento (aqi empiezan los problemas serios) hay q integrar una expresion q depende en cada instante del seno y coseno del angulo del vehiculo respecto una direccion fija de la referencia del suelo... o dicho en otras palabras para este caso concreto... el vehiculo es no-holonomo y por lo tanto es jodido de cojones saber donde coño está.
FINALMENTE xD esto da lugar al problema en mayúsculas de nuestro amiguito robot y es q para medir la posicion tenemos q basarnos en lecturas indirectas: de rotaciones de las ruedas y estimar así las velocidades angulares y estimar mediante una integracion casera por el metodo de euler la trayectoria del bicho. Esto se puede hacer cogiendo la ecuacion de la velocidad y aproximando las derivadas como si fueran constantes durante el tiempo de un ciclo de integracion y ahí se simplifican cosas. Pero nos da lugar a error.
El error en éste problema proviene de muchas fuentes. Hay error en el calculo, hay error en el modelo (las ruedas nunca seran perfectamente circulares, la distancia no es lo q nosotros llamamos distancia etcetcetc) Hay tantas fuentes de errores, q por mucho q refinemos la precision de nuestros calculos.. siempre tendremos un error q se nos irá a infinito y por lo tanto el mapa será tarde o temprano una mierda. El problema es insalvable por este camino y la unica solucion es tener una realimentacion des de fuera q nos dé algo sobre lo q corregir este error. Y la idea mas simple q se me ocurre (aun q pueden haber mil inventos) es tener un punto o mas de referencia en el suelo q nos diga algo. Esto es, una base q esté quieta q nos diga cada cierto tiempo a qé distancia estamos de ella o alguna historia así. Con esto se puede compensar el error de calculo y los errores inevitables en el modelo mecanico y elaborar un mapa tan grande como deseemos.
No sé si me he explicado bien. La verdad es q tengo la impresion q doy una imagen de hcer dificil lo q es facil pero yo creo q justamente lo erróneo es considerarlo simple. El tema éste es jodido pero bien jodido, yo recomiendo tragarse algun libro de control o leer por internet (pq hay informacion en muchos sitios) sobre control, para tener una idea de los conceptos estos de realimentacion y propagacion de error.
xcierto, para empezar a abordar el problema antes q hacer prototipos e historias yo recomiendo pillar lapiz y papel y estudiar la cinematica del vehiculo y sacar estas ecuaciones, es la mejor forma de saber a qé nos enfrentamos y empezar a hacer cálculos. Yo tuve un modelo cinematico y dinamico del bicho y me propuse controlarlo... al ver q mi modelo pecaba de no-lineal demasiado dejé de lado el intentar hacer un estudio de control muy analítico pero conservé las ecuaciones para tener una noción de como funcionaba el bicho, a partir de allí en paralelo elaboré el prototipo y desarollé el software mas simple para luego volver a la cinematica y desarrollar el algoritmo de integracion (q es muy simple de implementar).
en fin, hasta otra ;D
pd. por si estais muy locos, os dejo aqí algo de mi mierda por si quereis darle una ojeada, ya aviso q no es ninguna maravilla, pero sé q da rabia cuando lees por ahi q la gente hace cosas y cuenta cosas y no da nada a lo q agarrrarse xD Hay 2 imagenes donde sale un diagrama del bicho y las ecuaciones de la cinematica de éste (la aceleracion es util para desarrollar la dinamica) y luego hay el programa en asm del robot... es largo y coñazo y con comentarios y nombres en catalán... q dios os pille confesados xD
zip con estas 3 cosas
Publicado por: manex_1987 en 12 de Septiembre de 2004, 06:30:00
Bien, me has metido la mosca, y en el proteus estoy realizando una prueba con un 18f458 a 40mhz. Someto el numero 54.63 a diversas operaciones aritmeticas:
COS 54.63 = 0.4637ms de ejecucion = 463us
SIN 54.63 = 0.4256ms de ejecucion = 425us
TAN 54.63 = 0.9367ms de ejecucion = 936us
LOG10 54.63 = 0.451ms de ejecucion = 451us
LN 54.63 = 0.414ms de ejecucion = 414us
SQR 54.63 = 0.345ms de ejecucion = 345us
------------
Es una perdida bastante de tiempo (aunque para operaciones puntuales no es mucha), pero la precision que brinda el seno en coma flotante de este micro es impresionante. Hice un programa que enviara una onda completa de seno al ordenador, y luego en excel la comparé con la onda que genera el mismo PC. Son absolutamente iguales! Me agradaria colgar el documento en el foro pero no me deja...
Ayer probé las interrupciones multiples del 18F458, y consegui manejar los pines INT0 e INT1 con facilidad... se me ocurre que estos serian las entradas de los encoders...
Ah, y quien quiera rendimiento de verdad, que salte al barco de los DSP...
salu2!
Publicado por: Jimmy_pop en 13 de Septiembre de 2004, 14:17:00
lo de girar en quieto yo tambien lo hice porque implementé de mala manera unas rutinas q hacían una realimentacion negativa con solo 3 niveles de actuacion en los motores (aun disponiendo de un conversor D/A de pwm digno y puentes en H para gobernar los motores DC) y punto, pero no tiene porqué ser mucho mas dificil de implementar un control de angulo y avance al mismo tiempo; si hubiera tenido tiempo hubiera intentado hacer lo q quería en un principio que era desarrollar dignamente un estudio de control del vehiculo y hacer un algoritmo de control serio basado en la descripcion q tenía en espacio de estados de la dinamica del mismo... pero bueno 2 piedras tuve q apresurarme y sudar de esto.
lo de los tiempos me ha dejado un poco frito, segun estos datos el chip calcula un seno en 4500 instrucciones (segun mis calculos caseros), me gustaría q me linkaras alguna web de esta librería q usas pq stoy flipando que se pueda hacer eso en coma flotante... no digo q no eh, pero quisiera verlo pq me interesa .
y lo del dsp... tengo ganas de probar algun dia de programar un bicho así.... no he tenido la oportunidad de realizar demasiados proyectos de electronica pero estos chips tienen muy pero q muy buena y pinta para cosas de control como éstas tienen q ser brutales.
see ya
Publicado por: navi84 en 20 de Septiembre de 2004, 14:19:00
Para muchos será una chorrada pero para los que no, se lo explico, es algo básico de dinámica pero yo lo explico como puedo:
ADJUNTO IMAGEN DE EXPLICACIÓN
Cuando en nuestro robot conocemos la velocidad de dos puntos del mismo podemos conocer en este caso la de cualquier punto de él (interesa la del centro del eje que une las ruedas en la mayoria de los casos). Es muy sencillo, conocemos la velocidad de las ruedas que es igual a su velocidad angular (velocidad con que giran (rad/s) o bien en rpm, Hz, o cualquier otra...) multiplicada por el radio (como ya han explicado anteriormente).
Entonces [V = w * r] para cada rueda que seran distintas si son giros abiertos o iguales y contrarias si giran sobre el centro del eje (ojo porque para poder multiplicar a machada hay que estar en rad).
Si unimos vectorialmente estas velocidades y hacemos que esta linea corte a la perpendicular a la misma obtenemos el centro instantaneo de rotacion (CIR) respecto al que gira el conjunto del robot describiendo una circunferencia (centro de la curva).
Analiticamente y para implementar el software ¿cómo calculamos esto y la velocidad del centro?
Pues dado el angulo "beta" su tangente es la velocidad de cada rueda dividida por la distancia de cada una al CIR, tg"beta"=Va/dist(a-CIR)=Vb/dist(b-CIR) y asi para cualquier punto de la linea que los une como P.(la tangente es la velocidad angular tambien).
Por lo tanto Va/Vb=dista/distb
y como la distancia (a-CIR)= dist(b-CIR) + distancia entre ruedas(D) podemos calcular el CIR. En principio no interesa.
Facil, ¿no?
Pues venga que acabo, si ahora situamos un punto de referencia en la rueda B existe la relacion de que (Va-Vb)/D=(Vp-Vb)/0.5D por lo que despejando obtenemos que Vp=2Va-Vb entonces ya conocemos la velocidad del centro de nuestro robot.
Ahora dejo caer algo más sobre velocidades, desplazamientos, etc. Con cualquiera de estas velocidades podemos calcular la velocidad angular con que gira el "bicho" alrededor de su CIR, cualquier velocidad dividida entre su distancia al CIR. De esta manera podemos conocer el arco que describe si la multiplicamos por ejemplo por el tiempo y asi sabemos cuantos radianes o grados hemos girado (es el mismo angulo). La distancia que recorre la tomamos respecto al punto P (centro) bien con el arco o con la Vp multiplicada por el tiempo (ojo porque no es lineal).
Pues bien, si estamos utilizando encoders, por ejemplo, podemos adaptar lo explicado para saber cuanto recorre cada rueda, de aqui sacar su velocidad y luego el arco que ha descrito para saber lo que ha girado... a darle imaginación.
Yo lo utilizo en una plataforma robot (todavia no autonoma) y creo que va bien y es sencillo aunque yo no lo haya explicado del todo bien, sobretodo al final, pero bueno hay queda la cosa y si alguien tiene dudas pues que pregunte, que somos muchos los que podemos responder.
No puedo subir la imagen y eso que pesa 39 KB pero bueno, seguiré probando
Publicado por: Nocturno en 21 de Septiembre de 2004, 00:50:00
Interesante la explicación física que has dado sobre el movimiento del robot, se ve que te lo curraste, monstruo.
Publicado por: Jimmy_pop en 23 de Septiembre de 2004, 07:54:00
Bueno navi, lo q has dicho está bien, la verdad es q hay poca información sobre mecanica en la red o por lo menos es mucho mas dificil encontrarla que encontrar buenas webs con circuitos y tonterias varias para hacer robots. Un dia podemos currarnos si estamos muy aburridos algun texto mas o menos digno para explicar 4 cosas. Por otro lado quisiera añadir que estas operaciones se pueden hacer de forma exageradamente simple y que si se eligen adecuadamente los radios y las distancias entre las ruedas se puede lograr que las multiplicaciones y divisiones pasen a ser bitshifts y el resultado es gloria.
Y bueno nocturno, que ejem :$ uno de los fallos que tenía el robot era en la parte mecanica, que dejaba un poco que desear. Como se ve, había una rueda detrás y delante no tenía rueda... y pusimos un clavo ¬¬. Efectivamente se quedaba atascado y daba problemas :C Pero bueno ese es un tema que no nos preocupaba en exceso porque para las demostraciones teníamos una sala con un suelo muy liso y tiraba bien. De todos modos, si hicieramos ahora un robot seguramente puliríamos ese tipo de detalles como tambien buscaríamos otros motores mas dignos.. pq los que tiene q son como de juguete y llevan engranajes cutrisimos hacen un ruido de la ostia.
cya
Publicado por: manex_1987 en 23 de Septiembre de 2004, 13:47:00
Muy buena la explicacion!
salu2
Publicado por: navi84 en 23 de Septiembre de 2004, 16:31:00
Tanto estudiar algo tendria que aprender... Si creo que a muchos de los que empiezan a construir bots o no se atreven o se quedan atascados con la parte mecánica, tanto a nivel estructura por no saber por donde empezar como a nivel de dinámica. Muchos se complican demasiado con la primera cuando realmente para empezar solo es necesaria una estructura simple, bien alineada y dejarse de florituras si no eres un manitas. Para lo del movimiento solo hay que saber un par de cosas básicas, como las que he intentado explicar (aunque no del todo bien) y ser capaz de desarrollarlas para sacar resultados más que decentes.
Me apunto a lo del tutorial
Yo estoy en camino de conseguirlo, despacio pero con buena letra
Publicado por: manex_1987 en 25 de Septiembre de 2004, 08:31:00
Era para deciros que mi proyecto ya ha empezado, la base, en contrachapado 7mm, ya esta hecha, y ahora me falta acoplarle los motores.
No se como acoplar el eje del motor con un eje lego, se os ocurre alguna idea????
Publicado por: Nocturno en 25 de Septiembre de 2004, 11:13:00
Si son de distinto tamaño, hay un rudimentario sistema que funciona bastante bien, y además te permitirá funcionar aún cuando no estén situados en una posición perfectamente alineada. Se trata de buscar un trozo de macarrón de goma cuyo hueco interior ajuste más o menos bien en los dos ejes. Le echas un poco de pegamento rápido y metes los dos ejes dentro del macarrón de manera que quede un poco de espacio del macarrón sin nada dentro en la parte central, unos 3 o 4 mm. De esta manera, el movimiento giratorio del eje del motor se transmite al macarrón y de este al otro eje, pero con la flexibilidad de la goma se corrigen defectos en la alineación de los ejes.
El otro método que he utilizado a veces, y también es muy barato, aunque sólo válido para ejes iguales es utilizar la parte interior de una "ficha de empalme" de las que se usan en las instalalaciones eléctricas. Las hay de calibres importantes, hasta de 8 mm. por lo menos. Es muy simple, alineas los ejes y atornillas cada uno a una entrada de la ficha de empalme, a la que habrás liberado de toda su parte plástica.
Supongo que habrá métodos más eficaces y profesionales, pero segúramente serán más caros que estos. Ya me contarás cómo te ha ido.
Publicado por: manex_1987 en 25 de Septiembre de 2004, 14:30:00
Aun asi igual uso ruedas normales... que me recomendais para un motor con reduccion 1:192? Una rueda grande (un CD) le daria velocidad...
saludos!
Publicado por: Nocturno en 26 de Septiembre de 2004, 01:39:00
Publicado por: manex_1987 en 26 de Septiembre de 2004, 06:34:00
espero vuestras ideas... salu2
Publicado por: Jimmy_pop en 26 de Septiembre de 2004, 16:23:00
yo para unir ejes distintos de diametro parecido voto por lo del macarron... pq además si se atascan las ruedas hace de limitador de par y al ser flexible además hace de filtro pasa bajos de impactos xD
yo vi unos q hicieron un cacharro tb con ruedas de cd"s y tuvieron q meter una especie de cruz (tipo las de los servos) para poder fijarlo a un eje. Claro q tb puedes desmontar algun lector de cd"s y quedarte con las piezas que los agarran xD yo hace nada desmonté 3 lectores que iba a tirar para quedarme con los motores (<-- y rima). *
De todos modos, según qué quieras hacer con el bicho ten cuidado pq los cd"s si bien es verdad que tienen ventajas como rueda por tener un diametro muy preciso (al tener que girar a alta velocidad los fabrican con el centro de masas muy bien situado para evitar vibraciones y disgustos en los lectores) tambien tiene desventajas por el poco agarre que dan, prueba a ver que tal ;D
silla
* qé opinais del tema reciclaje electronico? tenemos que hacer un post sobre esto pq da mucho de sí
Publicado por: Nocturno en 26 de Septiembre de 2004, 16:52:00
Publicado por: manex_1987 en 12 de Octubre de 2004, 07:42:00
Ahora lo siguiente, solucionar los problemas que tengo con el 16F88 y las comunicaciones RS232...
salu2!
Publicado por: Nocturno en 12 de Octubre de 2004, 09:08:00
Publicado por: manex_1987 en 12 de Octubre de 2004, 13:00:00
Ya os dire la marca, es un pegamento de esos que tienes que juntar dos substancias y mezclarlas, se seca enseguida por lo que haces la mezcla y te dura un suspiro fresca.
salu2
Publicado por: Nocturno en 12 de Octubre de 2004, 14:03:00
Publicado por: paymer en 12 de Octubre de 2004, 14:08:00
A mi tambien me va lo de los microbots y hace algun tiempo construi uno con piezas de Tente de cuando era niño y un par de cajas reductoras (que a pesar de hacer ruido no van del todo mal).
La idea era hacer un microbot programable con teclado y lcd de tal forma que se pudiera programar con ordenes sencillas tipo logo:
Avanza 100,gira izda 20,para,pausa, etc.
la parte mecanica a pesar de ser algo "chapucilla" no iba del todo mal, la probe con una pequeña placa con un 16f84,un puente H integrado y unos encoders caseros fabricados con la optica sacada de un raton y puestos en uno de los engranajes intermedios de las cajas reductoras utilizando los agujeritos que tienen los engranes asi ganaba precision al tener mas impulsos por vuelta de rueda.
Hize unas pruebas de la mecanica y los encoders y la cosa funciono bastante bien a la hora de medir distancias cortas ahora en distancias largas hay el mismo problema que he leido mas arriba dado las imprecisiones de la mecanica los errores se van acrecentando mas y mas.
En cuanto al software lo llevo a medias este debe de corren en un 16f877 ya q el 84 se queda corto.El editor de ordenes esta hecho y se pueden introducir comandos via teclado matricial y representarlos en un lcd de 16x2 esto lo tengo simulando en Proteus.
De momento el proyecto esta parado por falta de tiempo pero a quien le pueda interesar que me lo diga y le mando lo llevo hecho.
Un saludo para todos.
Pd: habia puesto tres fotos del cacharro pero no me deja subirlas porque dice que no hay espacio.
Publicado por: manex_1987 en 13 de Octubre de 2004, 13:47:00
El 16F88 me esta dando tantos problemas, que me parece que voy a dejarlo y me curraré el robot con el 18F458. Y me da una pena tremenda, porque el 16F88 es la leche, con VCC y GND conectados ya me funcionaria a 8mhz... (ni MCLR ni cuarzo, como ois).
El jodido 16F88 no me manda nada con SEROUT, pero con SERIN obedece! joder...
Paymer, es una idea buenisima, yo en un principio quiero programarlo basicamente, no obstante luego le ire añadiendo funciones progresivamente. Y entre ellas se encuentra la que tu dices... pero mediante ordenador. Y si profundizamos mas, podriamos poner modulos aurel a cada lado, y currarnoslo pero inalambricamente, pero bueno paso a paso todo...
salu2
PD: A ver si mañana, que tengo clase de electronica en el cole, puedo preguntar al profe si me deja las instalaciones para hacer una PCB como dios manda... que para el robot vendria de puta madre...
Publicado por: manex_1987 en 13 de Octubre de 2004, 14:54:00
Aver si el cole me deja sitio para proseguir con el proyecto!
salu2
Publicado por: Jimmy_pop en 26 de Octubre de 2004, 07:09:00
me alegro de ver q estais tramando proyectos parecidos, yo estoy muy inactivo ultimamente, lo ultimo q hice fue una placa rancia para intentar hacer de nuevo un robot, ésta vez partiendo de lo aprendido anteriormente con la esperanza de ir mas ágil. en un momento de euforia hice esta placa rancia... aqí se confirma que vale la pena currarse un pcb pq la alternativa es volverse loco.. yo intenté buscar la maxima compacidad e hice esta aberracion con soldaduras aéreas, vale la pena verlo para reirse de ello:
estaba pensada para ser usada en plan modular en proyectos con el pic16f877 q me ha tirado bastante bien.
xcierto, he leído q tienes marrones con el serial no? yo perdí un fin de semana como un loco porque no me funcionaba y no sabía q coño pasaba.. ya no recuerdo qé fallo cometí al programarlo era algo muy triste y me tuvo de culo muchisimo.. el dia q pude usar un osciloscopio y encontrar el problema fue un alivio tremendo.
nada, saludos, veo q estamos hablando de cosas muy offtopic os buscaré en otros posts xD
see ya