Bot Controlado por RF

[Mario]

Hola.

Yo también he trabajado con RF (casi en bots).

La idea era transmitir datos por medio de Hyperterminal de una PC a otra (lo que teclearas aparecería en la otra PC).

Yo utilicé el par de Rentron TWS-434 (434 MHz) y funcionaba bien hasta 1200 bps. La hoja de datos dice que hasta 2.4 Kbps pero yo tuve problemas con eso asi que lo dejé a 1.2K.

Una cosa interesante fue que (después de leer varios artículos en Internet) al colocarle antenas de teléfono (900 MHz) y dándole hasta 10 Volts al transmisor alcanzaba distancias de como 100 mts estando dentro del edificio (escuela) a 250 mts en campo abierto (las computadoras afuera y "viéndose").

Yo también tengo el libro ese de Amphibionics e Insectronics (y algunos mas) y son buenos para saber cómo y dónde comprar las "cosillas".

Sobre lo de que si son estándar o no...........................

Si pueden leer el libro Robot Sumo: The official Guide (Pete Miles, 2002), en el capítulo 10 explica los diferentes tipos de RF para sistemas R/C (27,40,50,72,75 MHz).

Les escribiré algo para que se den una idea:

Banda de 27 MHz
Se usa para vehículos de terrestres y aéreos. Usualmente se emplea en carritos ,tanques, botes y avioncitos de bajo costo. Empieza en 26.995 MHz y se divide en seis canales diferentes (50 Khz entre uno y otro). Estos usan AM o FM para transmitir.

72 MHz
Se usa solo para aviones. No se permite que los robots terrestres utilicen esta banda. Se divide en 50 canales que empiezan desde el 11 al 60. La frecuencia va desde los 72.010 Mhz hasta 72.990 MHz, espaciados de 20 en 20 kHz (tienen una banderita blanca con el canal en el que están).

Descanso 

75 MHz
Se usa para terrestres solamente. Se divide en 30 canales que empiezan en 75.410 MHz, se incrementan de 20 en 20 kHz hasta los 75.990 MHz. Los canales empiezan desde el 61 al 90 (tienen una banderita roja con el canal donde están).

50 MHz
Se usa para aéreo o terrena. 10 canales, 50.800 MHz (20kHz). Son canales de dos dígitos (00-09). Estos tienen una banderita negra.

Y los de Japón son de 40 MHz, Reino Unido 35 MHz, en fin, si tienen oportunidad de leer el libro mucho mejor.

También en Build Your Own Combat Robot (de Pete Miles y Tom Carroll 2002) en el capítulo 8 se explica lo mismo.

Otro libro donde una persona utilizó walkie talkies para mandar la información es Build your own All-terrain Robot (Brad Graham y Kathy McGowan 2004) en el capítulo 5 donde utiliza el DTMF de los walkie talkies para mandar comandos de ON/OFF  (utilizando codificadores/decodificadores DTMF).
Aunque solo lo propone como una alternativa quizá se pueda utilizar con el DTMFOUT del PICBasic Pro (quizá).

Quizá esto les sirva.

Apenas estoy autoenseñándome C (C Primer de Prata) asi que no entiendo mucho el código que colocan pero lo haré (algún día  ).

Sobre lo de transmitir con el Usart en Hardware...........
Microengineering labs dá varios ejemplos de cómo utilizar el Serin/Serout, Hserin/Hserout del PIC Basic Pro.

Al igual de Lordlafebre yo usé solamente el Serin (software) pero ahora que tengo de los 18Fs me pondré a ver si puedo hacer comunicación en hardware con Hserin/out (si me queda tiempo  ).

Una cosa mas:
Como yo tenía que transmitir un datos en full duplex usé infrarrojos (40kHz y 56kHz). Para transmitir en RF use Duplex. No podía transmitir porque el transmisor de una era igual a su receptor (solo tenía de 434 MHz para las dos PCs) asi que apagaba un receptor cuando transmitía y prendía el otro (usando las condicionantes de Serin). A lo que voy es que es muy (pero muy) recomendable "codificar" la información para no tener problemas si en un mismo cuarto están varios bots con la misma frecuencia (claro que si están con diferentes pues no hay problema).

La gran desventaja con estos transmisores es que son de ASK y cualquier variación (y me ha pasado) de voltaje hecha a perder la información.

¡¡¡¡¡¡¡Uffffff!!!!!!!

Nunca había escrito tanto en ningún foro.

PD: Si tienen oportunidad lean este libro "Mobile Robotic Car Design" de PushKin Kachroo y Patricia Mellodge, yo voy a la mitad y está buenísimo, tiene lo que nunca había visto en un libro de este tipo: diagramas de bloques retroalimentados con su función de transferencia (si, función de transferencia) simulada en MatLab.
Usan un DSP de Motorola (en C) combinado con un PIC 16F874 (en ensamblador).

PD#2:
Me pueden decir cómo hacerle para que si hay respuestas me llegue la notificación a mi correo electrónico normal (no el de miarroba). Antes me llegaba cualquier actualización de tema a mi correo y ahora tengo activado el botón de notificar pero no me llega nada al correo, tengo que entrar al foro, luego al perfil para ver si hubo respuestas.

¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Uffffff  otra vez!!!!!!!!!!!!!!!

[Algec]

Bien, ya esta casi listo me falta el cheqeo de errores, pero he tenido que modificar el programa de recepcion porque no funciona, o no se como funciona la siguiente funcion.
A ver si alguien sabe como va eso, el orden de los bits que supuestamente carga porque a mi no me trabaja

shift_left(buffer,2,bit);           

EN cuanto este listo los pego emision y recpecion y si alguien me dice como, pego el proteus para que se pueda verificar

[kain589]

Esa instruccion desplaza a la izquierda la variable "buffer" que es de "2" bit y le mete el valor de la variable "bit":

shift_left(buffer,2,bit);     

Ayer mismo estuve usando esa funcion, porque tengo un programa que tambien hace la recepcion que traduje de un codigo en basic pero que no entiendo demasiado,y me extraño el hecho de que en un desplazamiento se introdujeran bit

EDITO-> "buffer" que es de 2 Bytes, me he equivocado al escribir

[Algec]

Es lo que se supone que hace, pero no se porque no lo hace bien. En algo falla mi programa.
Si lo hago trabajar con variables bit y las visualizo en una lcd recibe correctamente todos los bits, pero si uso esa funcion la variable buffer no se modifica.
No me gusta la idea de usar una variable tipo bit por cada bit recibido por lo que seguire trabajando sobre ello.
¿Alguien tiene una pista de que pasa?
Ya funciona bien el emisor tanto para IR como para RF en codigo RC5 controlando incluso si se dejo una tecla pulsada o es una nueva pulsacion.
En el receptor tanto IR como RF (es exactamente igual solo cambia que en IR llegan los datos invertidos por el receptor IR que funciona asi) me falta el testeo de errores a mitad de recepcion, y quitar el problema de usar 11 variables tipo bit y cargarlas a un par de enteros, uno con la direccion y el otro con el comando.
En cuanto este listo y chequeado lo subo

[kain589]

La verdad es que yo le he intentado dar forma de bucle a mi codigo usando esa instruccion, incluso comando = comando<<1 (asi llamo yo a mi variable) habiendo hecho previamente la OR de comando y el bit recibido y no hay manera(ahora que lo pienso puede ser porque en este caso hago la OR de datos de diferente tamaño, probare a darle forma de int8). Yo lo hago asi, pero me parece poco "elegante" esta solucion:

Uso las variables sistema(tv,vcr...) y comando(la orden en si) , defino sus bits:

Código: C

1. //Deben ir despues de la variable que mencionan
2. #bit comando0 = comando.0
3. #bit comando1 = comando.1
4. #bit comando2 = comando.2
5. #bit comando3 = comando.3
6. #bit comando4 = comando.4
7. #bit comando5 = comando.5
8. #bit comando6 = comando.6
9.  
10. #bit sistema0 = sistema.0
11. #bit sistema1 = sistema.1
12. #bit sistema2 = sistema.2
13. #bit sistema3 = sistema.3
14. #bit sistema4 = sistema.4

Y despues voy cogiendolos uno a uno:

Código: C

1. ::::::::::::::::::::::::::::::::::::
2. while (sensor_ir == 0 && contador < glitch){
3.          ++contador;
4.          }
5.       if ( contador < glitch){// para que vaya a inicio usar variable 1bit
6.          Error_glitch();
7.          }
8.       //actualiza sistema
9.       comandoA = comando;
10.       sistemaA = sistema;
11.       //retardo
12.       delay_us(400);
13.       //toma bits
14.       captura_bits();
15.       comando6 = !valor;//complementa
16.       captura_bits();
17.       tog_bit = valor;
18.       captura_bits();
19.       sistema4 = valor;
20.       captura_bits();
21.       sistema3 = valor;
22.       captura_bits();
23.       sistema2 = valor;
24.       captura_bits();
25.       sistema1 = valor;
26.       captura_bits();
27.       sistema0 = valor;
28.       captura_bits();
29.       comando5 = valor;
30.       captura_bits();
31.       comando4 = valor;
32.       captura_bits();
33.       comando3 = valor;
34.       captura_bits();
35.       comando2 = valor;
36.       captura_bits();
37.       comando1 = valor;
38.       captura_bits();
39.       comando0 = valor;
40.       //ha habido fallos?
41.       if ( fallo ==1){
42.       comando = comandoA;
43.       sistema = sistemaA;
44.       }
45.       //toma de decisiones_vamos a encender led del puerto
46.       if ( comando == xx){}
47. :::::::::::::::::::::::::::::::::::::::::::

Como digo no me gusta ese algoritmo, aunque aqui no uso la variable sistema en otros caso si; el bit de toggle no lo uso; este codigo lo pase de uno en basic por eso no lo entiendo demasiado. Una parte que me llama la atencion es el bit 6 de comando que creo que no es el, no sé. Falta parte de codigo si quieres lo subo entero

[dogflu66]

Ya tengo a Miguelito funcionando por RF en una primera versión del programa... lo próximo será añadir el control de los motores por PWM...

http://www.mytempdir.com/672042

[dogflu66]

Voy a generar un frecuencia de unos 30hz para controlar los motores por pwm, que eso son unos 33mSg que divididos entre 255 (0 motor sin voltaje y 255 motor alimentado siempre) pasos de velocidad seria 0,12 mSeg, todo esto siempre +- porque depende de la base de tiempos del timer… voy a ver si hay interacción entre el RS232 y el PWM…

[Algec]

Ya esta hecho todo, tanto en IR como en RF.
Funciona en proteus perfectamente.
Donde quereis que lo suba? y ¿como?

[Algec]

Veamos si puedo subirlo, por favor si alguien lo estudia que me diga si localiza errores
Los ficheros van comentados linea a linea
Añadi la libreria LCD con la que compile los ficheros, los .c, los .hex y el ejemplo de proteus
Solo se puede probar el RF el IR modula a 38 Kh y no funciona en la simulacion pero en real debe ir bien.
Estoy probando en real ya comentare

[Algec]

Bien ya me dio tiempo a chequearlo con modulos RF Aureal y he hecho unas pequeñas modificaciones en el codigo. NO afectan al funcionamiento del sistema en general, y asi funciona perfecto.
Lleva testeo de errores, deteccion de tecla mantenida pulsada etc.
Probado como digo fisicamente con modulos aureal y va bien. La parte de IR no esta probada porque no tengo un mando que envie ese protocolo pero debe funcionar igual de bien ya que son similares.
PEgo los ficheros definitivos de prueba para quien quiera usarlos

[dogflu66]

Enhorabuena Algec, yo estoy incorporando control de velocidad por PWM para los motores y después de esto sustituiré las teclas por mandos analógicos.. y asi sucesivamente hasta tener un  verdadero radiocontrol tan completo como los del mercado…. Jeje, por lo menos eso espero…

[Algec]

Exactamente en lo mismo ando yo, pero me voy una semana de vacaciones asi que lo aparcare un poco.
Cuando vuelva espero ver posteado tu codigo y que lo mio te haya servido para algo.
De camino comprare dos antenas de 433 ya que las pruebas las hice sin antenas y funcionaba
Asi que con antenas debe ir de lujo.
Ando con el control de los servos pero como soy asi como soy quiero hacer una funcion en que se le pase los parametros angulo y velocidad de giro. Algo asi como

servo(N_de_servo,angulo,velocidad)

 y que el servo llamado se posicione en ese angulo a la velocidad reuqerida.

Ademas como soy asi quiero que el angulo concuerde con la realidad independientemente del tipo de servo que se use, para lo cual definiria unos ajustes al principio, que los habria que poner de forma experimental para cada modelo de servo, probando con un programita de testeo con una aguja y un angulo.
asi corresponderia 1 a 1º y 180 a 180º.
Bueno que en eso estoy.
Gracias

[dogflu66]

Pues si no quieres no es necesario que compres las antenas, ya que con cable unifilar con una longitud de 17cm va igual de bien que con las antenas, y que no sea muy grueso, yo utilizo uno de unos 0,6mm +- para que quede recto pero se doble con facilidad si golpea con algo... y que disfrutes esa semanita pana...

[Algec]

He vuelto de mis mini vacaciones, esperaba ver algo mas posteado.
Se ha parado el proyecto de hacer la rutina de control de servo?
YO empezare mañana si puedo.

[LordLafebre]

Hola:

Yo tambien me pongo hoy con eso, aunque ya tenia hecho un programa pero no lo encuentro, miestrastanto hare un pequeño programa para controlarlo desde el PC, en unas horas contare novedades.