Ya sabemos q hay q hacer cuando no hay yerba...
pri-con-pri!

ingresé reclamo en el correo número 15807

se van a poner en contacto conmigo...

chicas

queria ver un poco cual es el plan, asi somos todos felices.

supongo que ya deben haber hablado d esto.
hay plan?
quienes tienen vacaciones?

a mi me gustaria arrancar el lun 16 de enero.
q dicen?

yo arranco a laburar ahi, solo 6hs por dia, o sea que me queda un buen rato cada dia.

en la cortita pensaba afanarles el gps cuando llego, y llevarmelo para arg, asi le meto al sw para eso.
tmb adaptar el imu_comm al mongoose, o sea que tengo xa divertirme.
igual en cba no creo que labura tanto...

tarjetas microSD

llevo algunas?
la mia creo que se hizo mierda, o algo del estilo.
mi beagle arranca, pero no le gusta lo que encuentra en la SD.
tengo q comprar otra xa probar, valen tipo 6-7 USD.
el lunes se supone que hay ofertas locas online, es el dia de "gastemos plata" acá, así que es un buen momento xa comprar cosas a buen precio.
yo llevaría 4 o 5
q dicen?

quita estaño

agrega dos quita estaños a la lista de compras, salen USD 5 cada rollito. es esa cinta mágica que le das con el soldador y se sale.
hay d eso por ahí? (en la fac y/o en rondeau?)

quiero confirmación de parte de uds para todas las compras.
no entendí a que se refieren con "pines". podrían mandar foto?

el codigo del imu lee, pero falta masticar bien

• estimar los params de un modelo ax + b.
  • el offset b se calcula haciendo la media de los datos con el imu quieto.
  • la ganancia a no se estima (por ahora). habría que hacer algo experimental para esto:
    • Armar algo que gire a una velocidad angular configurable, w, y razonablemente precisa. ver si el IMU está de acuerdo con la velocidad a la que gira. con un sistema así se podría relevar la respuesta del sensor. conociendo el offset se puede estimar la ganancia

no he buscado como hace la gente xa resolver esto, pero creo que este plan tiene sentido

implementar el bias para el acc en C.

init

• objetivos
• partes del proyecto

modelo

• pasaje del modelo asqueroso a uno lineal simple

sensores

cosas con tito:

• mientras explicamos conservacion del momento ang, hacer q tito rote xa un lado, dsp xa el otro con un cmd_motores
• psímetro
• imu display con tito
  • con/sin kalman
  • ver si la cov dinamica ayuda
• como sacamos los distintos elementos del vector de estados de los sensores disponibles

escs + motores

• se hablan x i2c, protocolo con dos lineas reloj/datos (+tierra), hay 1 maestro y esclavos
  • cada esc tiene su dirección
• mostrar que nos colgamos de lo que había, escuchamos y dsp suplantamos
• brushless -> explicar que lo vas llevando, y que tiene que ir rápido y ahí entran los ESCS
• mostrar puentes H y hacer efectos lindos

tenemos documentación por cualquier lado
mi plan era meter todo el latex/

les parece?
puedo mover la doc sobre modelo_fisico y sobre eleccion_hardware para la carpeta latex/

alguna otra propuesta?

tenemos que alimentar:

1. el/los level-shifters que usamos para la comm. Las tensiones necesarias son:
   • 1.8v
   • 3.3v
   • la tensión que necesite el i2c
2. la IMU
   • 5v

por ahora nada más (excepto el GPS pero asumo que come del USB)

en el expansion header de la beagle 1.8v y 5.5v (pines 1 y 2 respectivamente)

• de la datasheet del beagle

7.24.3 Power
The expansion connector provides two power rails. The first is the VIO_1.8V rail which
is supplied by the TPS65950. This rail is limited in the current it can supply from the
TPS65950 and what remains from the current consumed by the BeagleBoard and is
intended to be used to provide a rail for voltage level conversion only. It is not intended
to power a lot of circuitry on the expansion board. All signals from the BeagleBoard are
at 1.8V.
The other rail is the DC_5V. The same restriction exits on this rail as mentioned in the
USB section. The amount of available power to an expansion board depends on the
available power from the DC supply or the USB supply from the PC.

Lo que yo entiendo es que hay que mirar al TPS65950 para el rail de 1.8v, y a la beaglejuice para el de 5v.

• de la hoja de datos del TPS65950
  • El rail de 1.8v tira 700mA (de acá no queremos sacar casi nada, solo para alimentar el shifter, que debería comer a lo estrella pop no bulímica)
• de la hoja datos de la imu
  • A 5v consume 24mA. Asumo que no vamos a tener problema para sacarle 24mA a la beaglejuice.

En fin, yo digo de alimentar tanto la IMU como el/los shifters desde la beagle
q opinan?

no apoyo el plan de armar un circuito conversor de voltages como de la wiki. creo que la vamos a complicar innecesariamente.

Logré sacar el UART2 de la beagle, y me puse a ver un poquito sobre como conectar a esta gente.
Hay q hacer dos cosas:

• Alimentar a la IMU
• Interconectar RX/TX

5v en la beagle

El pin2 del expansion header en la beagle es 5v, y sobre chupar de ahí tenemos esto de la datasheet de la beagle:

The other rail is the DC_5V. The same restriction exits on this rail as mentioned in the
USB section. The amount of available power to an expansion board depends on the
available power from the DC supply or the USB supply from the PC.

O sea q de fiesta, mandamo cable a la IMU y dale q va. Que la IMU chupe del can.

comm serie

La imu quiere 3.3v-5v para la comm serie, la beagle quiere 1.8. Ahí vamo a tener que meter un shifter.
estuve viendo un Logic Level Converter que vende sparkfun por USD 2. el schematic es re choto.
mñna le pregunto a roberto donde se encanuta transistores tipo bss138, y me hago uno.
si andan se hacen uno ahí y ya era

Primero hacer andar el GPS en la PC y dsp probarlo en la BB

Rela,

Te animas a comentar un poco el código que has hecho o por lo menos dar una explicacion general de que es lo que hay en cada lugar. Ta medio crudo pa arrancar de cero a entender todo lo que has hecho.

Tiene pinta de que está muy rico XD

Gente,

Estuve jugando un ratito con el i2c tools.

El comando para escribir el valor 117 (por ejemplo) en el motor D0 (208) a priori sería

i2cset 2 208 A2 117

Lo cual da el siguiente error
Error: Chip address out of range (0x03-0x77)!

En el .c del i2cset no encontré esta restricción si alguien se da cuenta por favor avisen

conversor RC a binario

como conversor de la señal del control a binario el matute encontró:
http://www.robotcombat.com/products/0-PL1210.html
http://www.robotcombat.com/products/0-PL752.html

faltaría un mux que sea manejador por esa señal binaria.

mux

http://www.nxp.com/documents/data_sheet/74LVC4066.pdf
http://search.digikey.com/us/en/products/74LVC4066D,118/568-8190-6-ND/2763168
parece poder alimentarse con 3.3v, y manejar la llave con hasta 5v. eso serviría para el hacer lo del i2c.
el modelo 14SO mide 8.75x4.0mm, o sea q no es tan chiquito.

si qusieramos agregar una señal xa la beagle quedan 2 canales libres, pero habría que ponerlo del lado lado 3.3 del shifter, y agregar canales al shifter, pero el MAX está lleno, no? (x2 de la uart y x2 del i2c)

capaz ta bueno mirar un poco más lo del switcheo antes de comprar.

The Fabulous Logic Analyzer

Seguir este Link

1. Armar el hardware
2. Testear

• resolver el tema de que para un lado crece al doble/mitad, y para el otro anda bien.
• resolver la discontinuidad del atan -> acumular xa siempre?
• hacer que el control entienda que diff entre 0 y 2 grados es igual a la diff entre 0 y 358.

Estuve revisando con un poco más de cuidado la vida..... No se si es porque soy muy idiota o que, pero no me había dado cuenta de que poninendo los ruidos demenciales que tenemos en la lectura de los ángulos el simulador pira como loco.

Creo que tenemos que trabajar en la linea de bajar un poco el ruido en la medida del ángulo o bajarlo en la estimación.

Eso no más....

Algunas cosas del paper que me parece habría que corregir:

II. Model of Quadrotor
- todos los motores giran clockwise
- No se dice que es M. Los torques de la figura son opuestos a la vel angular.
- Al principio de la página 2 dice S_i tendria que ser S_I
- Yo diria que x,y,z es la posición del centro de masa del sistema expresada en el sistema inercial
- v_q son relativas al sistema del cuadricóptero.

III. Sensores:
- Agregaría la formula con la que se calculan los ángulos de Euler.
GPS:
-"tens of meters y a couple of seconds" Esto esta bien? esa y me resulta dudosa.
- No me gusta decir que el GPS tiene una exactitud de 2-3 metros y que la datasheet diga 5m CEP. Podemos ocultar el dato de la datasheet.

V. Control design.
- Pondría la imágen con colores
- Agregaría que las trayectorias circulares solo pueden ser en torno al eje vertical.
- Agregaría la ecuación de Ricatti (también a la doc)
- Decir que controlabilidad y observabilidad aseguran la estabilidad

VI. Software
- Decir que el control que se implementó es discreto y que hubo que discretizar el modelo y utilizar una versión discreta de LQR.

VII. Results
B. System response
- Se habla primero de la figura 6 y después de la 5. queda mejor al revez.
- Pondría la imagen que usamos para la defensa para el ángulo de roll, tenía mucho menos sobretiro.

Comentario general: Me gusto mucho. Capaz que estaba lindo poner una foto de tito y de la beagle. Pero ta, no es necesario.

chicas hay plan aparte de "IR + photodiodos"?

creo que no es demasiado complejo el asunto, pero no se si hay alguna sutileza en el uso de estas cosas.
yo me llevo unas placas a la vuelta que tienen un dsp de Freescale, el 56F8013.

son breakout boards con montones de pines, tienen:

• GPIO
• ADC
• DAC
• botones
• USB para debugging
• UART

se programan en C desde un IDE de freescale, que capaz consigo (con capaz == taringa, etc). es facil hacer cosas faciles.

aplicacion inmediata seria:

• enchufar el led IR a uno de los GPIO, y el photodiodo al ADC.
• armar un programita que arranque a leer del ADC al apretar un boton y guarde el resultado en algun lado.
  • (lo mas choto seria correrlo con el debugger y verlo asi nomas
  • mas sofisticado seria mandarlo por UART y levantarlo en otro lado. esto no tiene SO, es arrancar casi de 0, o sea que todo es un poco complicado.

con esto creo que se podria resolver el tema de los motores.

estoy tratando de bajar a tierra los planes, para ver que nos va a hacer falta.
ejemplo: que haciamos con unos leds y unos photodiodos? no me parece muy feliz meter mano en la beagle si no es necesario...

• timing al init (5 o 7)?
• errores a un log

• conseguir un taladro violento (mecha violenta) para reventar el tornillo sin bocha, ver si es cable roto o motor roto.
• si es motor, comprar otro, sino arreglar cable.
• armar esqueleto
• hacer cajita para tito
• pegarle el GPS en la mente
• placa para interconexión

hice transplante de esc (anda, los motores están en el orden correcto y funcan todos)
nivelé la imu.

falta probar el control y dsp ver si el update de K hace lo que tiene q hacer
si lo de K no anda de toque (por tiempos o por lo q sea) capaz pinta probar hovering en un lugar grande sin viento y poner punto final...

No quise poner la documentación de los hitos en la carpeta de latex para no armar confusión con el main, después de todo las presentaciones no van a ir en la documentación final...

Para eso cree otra carpeta llamada "presentaciones_hitos" en la raíz del directorio...

Les gusta así? Si a alguien se le ocurre algo mejor que agite y vemos...

Lo que había armado para preparar la SD para el beagle no parece funcionar con la XM. lo hice probando con la vieja.

hoy probando el tercer shifter que armé (este quedó prolijo) cagué la SD (no se como, pero se que no pude probar el circuito...) y no la pude recuperar con la wiki, o sea que no anda.
tengo q arreglar eso

conclusión: no usen la wiki BeagleSDBoot :(

yo x ahora me anoto:

• la parte de costos
  • agregar q usamos osciloscopio, sniffer, etc
  • meter algo de elección de hardware
• emprolijar el GPS (va a quedar + largo)

Necesito info sobre la compra para llenar el RMA.
mandé mail y no dieron bola, creo que se perdió en la cadena, o nunca lo mandé, no se.
agrego acá q es más ordenado. (acuérdense de ir cerrando las cosas q se terminan)

necesito completar:

• Company
• Address
• Phone
• Email

pensaba poner mis datos, para que el proceso sea más fácil y rápido.
q dicen?

propongo cama redonda con la doc que vamos a entregar, así vemos cosas raras en cosas ajenas.

vamos a entregar todo lo que está en /latex o eso lo vamos armando y solo se entrega al final?

Lo mas urgente es ver lo de la musica y lo de los barriles de cerveza

Rodrigo, vos habias dicho algo de q conocias a alguien q tenia luces y musica o pire?

barril digo de pegar el del pater, la cerveza artesanal y si quieren otro de pilsen/patricia

• prueba con diff setpoints (1,2,3m) no afectan la performance. Ver si se corrije con el bias en el acc.

xa habilitar el 4to pwm se pierde la uart2 (q a priori no parece importar) y puede q se complique/cague algo con el dsp. me contaron que usa timers que los pwm necesitan.
no pude encontrar nada sobre el dsp en las datasheets, y no lo se usar como xa ver q pasa.

el 4to pwm es un pin en el medio de la placa, habría que mandar alambre a full xa sacarlo xa afuera. no llega a ninguno de los conectores.

to alambre or not to alambre?

Gente,

Encontré un papper no se si muy interesante pero me gusto mucho el capítulo 2 donde el loco habla en general de los encares desarrollados por otros botijas para determinar la ruta del quad. El link es este:

http://www.cs.uni-salzburg.at/~ckrainer/jnavigator-20090917-final.pdf

Yo todavía no tengo claro que mierda es lo que queremos que el quad haga, pero acá hay algunas posibilidades interesantes algunas más fáciles que otras... desde una trayectoría que sean rectas hasta un sistema en varias capas para buscar cosas, investigar un entorno desconocido, y algun otro pire... hay uno que hace interactuar dos quads... canetti quería hacer algo de esto...

No sé... peguenle una miradita si pueden y lo charlamos

Después de escribir el mail me pareció bueno ponerlo en una issue, para que quede más ordenado....

• Sin disipador
  • Sandwiches
    • http://www.oomodel.com/lotus-t580-parts-t580z11-speed-controller-p-61766.html
    • http://www.moonhobby.com/lotus-t580-spare-parts-t580z11-speed-controller-p-61766.html
    • http://mymobilemms.com/OFFTHEGRIDWATER.CA/index.php?main_page=product_info&cPath=2_4&products_id=17 (creo q trae ambos)
  • Individuales
    • este q es upper: http://www.myrcmodel.com/index.php?main_page=product_info&cPath=1_2_110_108&products_id=2467&zenid=9fhcel4mdp75benqg459brajr5
    • Y la pareja (lower) es este otro http://www.myrcmodel.com/index.php?main_page=product_info&cPath=1_2_110_108&products_id=2468&zenid=9fhcel4mdp75benqg459brajr5
• Con disipador
  • Solo sandwiches
    • http://www.hobby-wing.com/t580-upper-esc.html
    • http://europemodels.eu/p_5430_Speed+Controller+Assembly+for+LOTUS+T580/
    • http://www.helipal.com/t580-z-11-speed-controller.html

Listo.

Solo recordar que lo que quedamos en comprar es:

• 1 sanwitch (1 de abajo y uno de arriba) con disipador
• 2 esc inferiores sin disipador
• 1 esc superior sin disipador

Obviamente van a ser en total 2 compras de 2 lugares distintos, porque no hay nadie que venda todo. Capaz lo que se puede hacer es pagar un shipping caro y otro barato. YO PREFIERO PAGAR LOS 2 CAROS. Si hay q elegir elegiria el que salga menos del limite para no pasar por aduana. Si los pasan sin tocar aduana, elegiría el q es igual al q tenemos, porque anda seguro. Pero insisto, quiero pagar los 2 shippings caros y de ser necesario pongo la diferencia entre shippings. ta?

Bueno vamo arriba q va a salir lindo viejoooo!!!
que no decaiga!!! hay q seguir pasando bien! vamo arriba!!!!

Salú

eu no me gusto mi idea de antes
habia hecho un python/ y meti cosas ahi...

en un rato pensaba cambiar a otra estructura, organizar por hw y no por lenguage, onda una carpeta imu, otra beagle_fw, otra beagle_sw, etc.

sino dsp va a ser un pedo

aviso x si rompo algun link

eu opinen, cambien lo que crean.
puse mi opinión para tener algo.
uds sabe mucho más que yo sobre el tutor, así que cambien nomás.

es xa ya esto...
yo subí lo mio nomás.

eval tutor

mandé mail a los de liquidware.
todo la página parece indicar que ellos usan y dan soporte al beagle rev C4, no al XM.
no debería ser problema, ya que es más o menos igual, pero hay algunas diferencias (el XM no tiene nand flash, por ejemplo)
capazq alguna cosa de esas hace que no arranque

dsp me cuentan bien q pasa
si ven palitos y caramelos en el puerto serie puede ser que tengas un baudrate distinto al que setean ellos. deberían ser palitos y caramelos de muchos sabores. si son todos del mismo gusto entonces hay algo muy raro...
yo siempre usé 115200 y anduvo bien. eso se setea desde consola haciendo
habría que ver bien donde se configura eso en el kernel
dsp que tienen un linux andando, el baudrate se setea haciendo
stty -F /dev/ttyUSB0 115200

no deberías necesitar sudo

siguieron esto:
http://antipastohw.pbworks.com/w/page/27990127/Wi-Fi%20Setup%20Using%20Belkin%20F5D7050%20USB

usando una SD con las instrucciones de
http://antipastohw.pbworks.com/w/page/27960896/Liquidware%20BeagleBoard%20Linux%20Kernel
?

hicieron todo eso?
parece un embole...

le hice diff a la conf que usan ellos
https://files.pbworks.com/download/MTE39lLPow/antipastohw/27969009/.config
y a la que uso yo, y hay muchas cosas distintas. no se cuales importan y cuales no.
yo lo que puedo hacer es compilarme uno con la cfg de ellos, y ver si anda.
no voy a poder probar el wifi jej pero puedo ver si anda el PWM, y si anda el beagle en gral

salú

#4/4/12

• Matriz blandita
• Le da mucha bola a la velocidad angular w_q y poca a los ángulos de euler

TODO

• Sin motores
  ** Probar con distintas matrices K inclinaciones en distintos angulos y ver que haga lo correcto.

por ahora la mongoose pudre todo cuando se conecta la beagle.
hoy estuve probando un poco, con un kernel y un u-boot con los cambios adecuados como para bancar la UART2, y:

• Con la atomic anduvo todo bien.
  • La beagle no dio problemas al arrancar con la atomic conectada
  • Al leer de la atomic todo seguia andando bien (y leia bien)
• Con la mongoose se pone con que "read only filesystem":
  • Se puede leer de la mongoose.
  • No anda ningún programa
  • No se puede crear ni modificar archivos
  • Dsp de un reset (a huevo), no levantaba más, tuve que volver a escribir el MLO y el u-boot.img a la SD, y ahí arrancó bien d nuevo (dsp de desconectar la mongoose). Se quedaba en

    U-Boot SPL 2011.12-dirty (Feb 20 2012 - 11:41:11)
    
    Texas Instruments Revision detection unimplemented

Esta tarjeta levanta con el USB conectado a mi laptop, otra tarjeta (la SD que vino de fábrica), ya un kernel panic y se queda en el camino.
Vamos a tener que entender bien q está pasando. yo estoy viendo de a poco.

chicas!

alguien sabe algo de scons o cmake?
si a nadie le importa tonce leo y elijo cual usar
te hacen la vida más fácil a la hora de compilar cosas gordas.
creo que está bueno armar un código que sea razonablemente manejable a medida que se ponga gordo y puto.

yo por mi me asigno a esto.
dsp de armar una estructura razonable podemos agregar cosas sin romper todo, y garantizar que a todos les compile, etc. eso en gral es feliz

Muchachada,

Creo que este es un tema que hay que discutir. Por lo que estuve mirando, no tengo ni idea como vamos a resolver esto.

Por lo que estuve mirando, mucha gente usa acelerómetros para determinar la orientación. Sin embargo esto solo parece funcionar si el dispositivo está quieto (No acelerado). En estos casos los combinan con giróscopos y con un Kalman se logra una estimación muy buena.
Nuestro problema es que no está quieto el bicho. Así que en esto me parece que el acelerómetro no nos va a ayudar. Por otra parte, tenemos solo el giróscopo. Que aparentemente si lo usas solo no te da algo muy bonito.

Queda planteada la pregunta como mierda determinamos la orientación.

Lo otro es el tema de la posición. El GPS por si solo, no es bueno. Hay que ver si podemos conseguir alguna corrección diferencial, ahí queda algo digno del orden de decenas de centímetro de error. Igual me parece demasiado.
La otra opción es una vez conocida la orientación, si conozco las aceleraciones en teoría puedo integrar y sacar la posición. Ahora, esto es una pija y tampoco funca.

Queda planteado esto otro.

No se. Escucho ideas/sugerencias

Evaluación del Drift a largo plazo

La idea es hacer un recorrido con la imu enchufada a la compu (o a la Beagle) e ir guardando todos los datos que arroja el sensor para luego contrastar con la realidad. Para ello se debe

1. Hacer un código que vaya guardando en un archivo todos los datos que arroja la IMU.
2. Planear rutas controladas y medibles para contrastar los resultados

El bus i2C del quad funciona a 3.3V, mientras que el del analizador con 5V. Para poder utilizarlo necesitamos convertir esos niveles lógicos. Acá encontramos un shifter I2C que es una chotada y justamente por esto nos hace dudar.
Aparte se lo comentamos el Oliver y no se animó a jugársela, lo cual deja aún más dudas.

Léanse eso, estúdienlo y lo conversamos!

done