PDA

Ver la versión completa : Proyecto Antena tracker 360º


Páginas : 1 2 3 4 5 [6] 7

Simba
23/02/2016, 21:22
Quise decir GPRMC

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
23/02/2016, 21:46
Sí, lo leí. Ahora estoy intentando resolver un error que me está volviendo loco. Lo nuevo que he añadido de código fuente me está dando un error cuando transmite las tramas nmea, que hace que el firmware se vuelva loco y empieze el tracker a comportarse de forma aleatoria...

Seguramente es un error en una operaicón matemática que desborda una variable, o a saber ... a ver si doy con ello y lo pongo pronto en marcha.

rortega
23/02/2016, 21:53
Simba ¿Cómo se hace para que oruxmaps se conecte por bluetooth al gps externo? Lo configuro pero luego no veo ningún botón u opción que sea "Conectar".

rortega
23/02/2016, 22:01
Simba ¿Cómo se hace para que oruxmaps se conecte por bluetooth al gps externo? Lo configuro pero luego no veo ningún botón u opción que sea "Conectar".

Siempre obtengo GPS no activo, entiendo que está intentando usar el GPS del teléfono móvil.

Simba
23/02/2016, 22:03
En la flecha torcida se selecciona iniciar GPS externo.

Simba
23/02/2016, 22:05
Previamente tienes que entrar en lo tres puntos de la derecha / configuracion global/ sensores/ GPS/ GPS Externo.

rortega
23/02/2016, 22:06
En la flecha torcida se selecciona iniciar GPS externo.

Joder, lo tenía delante de mis narices, gracias.

Ya hace link con el bluetooth, y luego, como le digo que se situe en la posición?

Le estoy metiendo como cabecer a una de las tramas $GGA pero tengo mis dudas de si lo que necesita realmente que la trama empiece como $GPGGA

Simba
23/02/2016, 22:08
Y antes haber enlazado en el Movil el Bluetooht.

También en ajustes se pone /GPS/ según ajustes

Simba
23/02/2016, 22:10
Ponle GPGGA

Para que arranque le tienes que poner en la Flecha torcida / iniciar Gps Externo.

Simba
23/02/2016, 22:13
Como te comente, con la trama GPRMC lo único que hace es que la flecha del avión, apunte hacia donde se mueve

rortega
23/02/2016, 22:29
Como te comente, con la trama GPRMC lo único que hace es que la flecha del avión, apunte hacia donde se mueve

De momento no detecta el oruxmaps la posición, algo debo estar enviando mal en la trama. La trama se envía y con el blueterm puedo verla, ahora falta afinar. La gprmc no la tengo aún preparada, se la meteré también para ver si es eso...

Bueno, voy a dejarlo de momento, toca sesión skype con la que manda.

Ivan_Cillo
23/02/2016, 23:45
Por cierto, yo puedo hacer que cleanflight saque Mavlink por la flip32 y también te solucione el problema. En una tarde lo puedo tener listo. Eso también solucionaría tu problema.
Joer Raúl eres un maquinon!
Eso ya seria la repera. A mi no me urge para nada ya que el quad apenas lo toco porque no lo tengo ajustado pero si lo llegas a hacer lo aprovecharé.
Se que con la flip en el tracker se solucionarían estas bobadillas pero quiero amortizar el 8 bits antes de volver a invertir.
Por cierto, tengo los archivos stl para imprimir listos, pensaba hacer una pagina en thingiverse y que pusieras el enlace en el repositorio o algo así.
Si me pasais las medidas de la pantalla nueva puedo hacer una adaptación del tracker para 32bits

Enviado desde mi DG800 mediante Tapatalk

rortega
23/02/2016, 23:49
Joer Raúl eres un maquinon!
Eso ya seria la repera. A mi no me urge para nada ya que el quad apenas lo toco porque no lo tengo ajustado pero si lo llegas a hacer lo aprovecharé.
Se que con la flip en el tracker se solucionarían estas bobadillas pero quiero amortizar el 8 bits antes de volver a invertir.
Por cierto, tengo los archivos stl para imprimir listos, pensaba hacer una pagina en thingiverse y que pusieras el enlace en el repositorio o algo así.
Si me pasais las medidas de la pantalla nueva puedo hacer una adaptación del tracker para 32bits

Enviado desde mi DG800 mediante Tapatalk

Me parece perfecto lo del thingiverse, pondremos toda la información y autoría, por supuesto...

A ver si algún compañero lo mide y te lo pasa, que me he dejado un pequeño metro que tengo en casa en el curro, lo único que tengo para medir...

rortega
23/02/2016, 23:51
Como te comente, con la trama GPRMC lo único que hace es que la flecha del avión, apunte hacia donde se mueve

Ya me funciona con el oruxmaps metiendo únicamente la trama GPGGA. Le meteré la trama GPRMC también, para que lo haga bien y bonito.

De momento tengo que resolver el problema de la posición, pues parece que me lo pone en el pacífico el punto, supongo que por el tema de interpretación del Este y el Oeste, pero es cosa simple.

Simba
24/02/2016, 00:14
Eso del Este y el Oeste siempre te ha llevado loco jajajajiji.
Me alegro que ya lo veas funcionar.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
24/02/2016, 00:23
Pues están bien la posición y el signo... He comprobado la trama que entra en un decodificacor online y me da perfecto, no sé por qué el orus lo saca en el pacífico.

rortega
24/02/2016, 00:25
Hay que calibrar los mapas o algo antes de usarlo?

Simba
24/02/2016, 00:26
Y digo yo ¿ no se podría ver en el Google Maps?
Es que no veo la forma de ver punto gps en el orux y en el Google Maps es muy fácil.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
24/02/2016, 00:28
Hay que calibrar los mapas o algo antes de usarlo?
Que yo sepa no, a mi con el simulador me salia directamente mi casa

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
24/02/2016, 00:28
Pincha en este enlace: http://rl.se/gprmc

Y luego mete cualquiera de estas tramas, que son las que me devuelve el tracker. Verás que se te situa en torno a Zürich (Suiza):

$GPGGA,123519,4743.574,N,853.813,E,1,08,1f,1f,M,1f,M,,*08
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.593,N,853.813,E,1,08,1f,1f,M,1f,M,,*01
$GPGGA,123519,4743.612,N,853.813,E,1,08,1f,1f,M,1f,M,,*0b
$GPGGA,123519,4743.612,N,853.813,E,1,08,1f,1f,M,1f,M,,*0b
$GPGGA,123519,4743.612,N,853.813,E,1,08,1f,1f,M,1f,M,,*0b
$GPGGA,123519,4743.612,N,853.813,E,1,08,1f,1f,M,1f,M,,*0b
$GPGGA,123519,4743.612,N,853.813,E,1,08,1f,1f,M,1f,M,,*0b
$GPGGA,123519,4743.631,N,853.813,E,1,08,1f,1f,M,1f,M,,*0a
$GPGGA,123519,4743.631,N,853.813,E,1,08,1f,1f,M,1f,M,,*0a
$GPGGA,123519,4743.631,N,853.813,E,1,08,1f,1f,M,1f,M,,*0a
$GPGGA,123519,4743.631,N,853.813,E,1,08,1f,1f,M,1f,M,,*0a
$GPGGA,123519,4743.631,N,853.813,E,1,08,1f,1f,M,1f,M,,*0a
$GPGGA,123519,4743.650,N,853.812,E,1,08,1f,1f,M,1f,M,,*0c

Simba
24/02/2016, 00:46
Si ya lo probé, sale cerca de Zurich.

Lo del Orux ya se como ver en el mapa el punto GPS, solo hay que poner el dedo encima un segundo y sale un menú desplegable para elegir.

rortega
24/02/2016, 00:48
Si ya lo probé, sale cerca de Zurich.

Lo del Orux ya se como ver en el mapa el punto GPS, solo hay que poner el dedo encima un segundo y sale un menú desplegable para elegir.

Yo me referái a que se centrara en la posición que recibe desde el tracker.

El caso es que se centra sólo, y se ve como avanza, pero sobre el pacífico. A mí me da que hay que calibrar el mapa o algo ... Lo mismo en esta actualización de oruxmaps hay que hacerlo, no lo sé, nunca lo he usado.

Simba
24/02/2016, 00:49
le das a ¿que hay aqui? y sale nombre latitud y longitud.

rortega
24/02/2016, 00:51
Bueno, mañana más, pero ya andamos cerca ...

Simba
24/02/2016, 00:51
Pues no se, pero si sale bien y se centra perfecto, cuando le mando las tramas directas del simulador, y el avioncillo vuela sobre mi barrio, te debería funcionar igual a ti ¿no?

Simba
24/02/2016, 00:51
Eso mañana mas.
Buenas noches.

Simba
24/02/2016, 00:59
Ya lo tengo Raul, hay una opción en Mapa/Recalibrar mapa.
Creo que con eso se centra en la posición GPS que estés situado.

rortega
24/02/2016, 01:39
Ya he resuelto el tema, no podía acostarme sin resolverlo :)

Es una chorrada, simple formato. Los dos ceros que he marcado en rojo faltaban. Ahora sí.

$GPGGA,123519,4743.612,N,00853.813,E,1,08,1f,1f,M,1f,M,,*0B

Mañana meto agrego la altitud, la hora exacta si es posible, la trama $GPRMC ... si todos los datos que traemos desde el simulador están disponibles ...

Simba
24/02/2016, 01:45
Ok pues ale a dormir.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
24/02/2016, 21:43
Ya tengo las tramas GGA y MRC implementadas, y funciona, pero hay datos que paso de forma fija, a modo de ejemplo. Ahora tengo que hacer que los distintos decodificadores, para cada protocolo de telemetría de entrada, decodifiquen esos datos, y así pasárselo a las tramas mavlink, NMEA , etc, de salida. Un lío ...

Guillesan
24/02/2016, 22:04
Estupendo Raúl, una cosa más , las tramas Mavlink del horizonte artificial pitch,roll,yaw no se retransmiten por softserial , es así? No es posible? Mucho lío?

rortega
24/02/2016, 22:56
Estupendo Raúl, una cosa más , las tramas Mavlink del horizonte artificial pitch,roll,yaw no se retransmiten por softserial , es así? No es posible? Mucho lío?

De momento no, pero lo vamos a hacer. He hecho antes lo de NMEA porque lo tenía casi implementado. Como para NMEA también me faltan datos que decodificar desde la telemetría de entrada, haré ambas cosas en paralelo, porque algunos datos serán comunes...

Guillesan
24/02/2016, 22:58
Nada como siempre a tu bola, era por confirmar si no estaba implementado o fallaba algo. Tengo todo preparado para la prueba en vuelo real pero....... parece que este fin de semana va a llover y mucho. Murphy vive

carabin
24/02/2016, 23:23
Nada como siempre a tu bola, era por confirmar si no estaba implementado o fallaba algo. Tengo todo preparado para la prueba en vuelo real pero....... parece que este fin de semana va a llover y mucho. Murphy vive
Ten cuidado con dejarlo a su bola que puede estar pensando en un Tracker de 128 bits 😲 ja ja


Enviado desde mi GT-I9301I mediante Tapatalk

Simba
25/02/2016, 00:11
Yo acabo de ponerme a leeros, y es una satisfacción muy grande ver como progresa el tema.
Mi idea era como Guillesan sacar este fin de semana, en primicia el Tarker360 32 con su Oleg grande, que lo espero mañana, pero creo que se va ha jorobar por lluvia y aire, aunque aquí el Valencia suelen fallar bastante los del tiempo.

El caso es que pronto y vendida sea, la V3.0.0 se va ha ver anticuada y eso es algo muy grande.

Carabin a ver cuando puedes y nos comentas tus progresos, que ansioso estoy de ver como lo llevas.

Un saludo a todos y buenas noches, yo me retiro.

rortega
25/02/2016, 07:58
Pues estoy pensando en comprar otra controladora ... otra Flip32, porque a ésta se le ha desprendido el conector micro usb de cuajo. Imagino que de tanto meter y sacar el conector, y algunas veces que he simulado con el cable puesto, ha terminado por deteriorarse...bueno, y las soldaduras y lo mal anclado que va a la placa.

Suerte que tengo aquí un FTDI, que si no no hay nada que hacer...

carabin
25/02/2016, 08:03
Ese es uno de sus puntos débiles, yo repase la soldadura de la parte del chasis del conector pues vi que eso podría pasar

Enviado desde mi GT-I9301I mediante Tapatalk

Guillesan
25/02/2016, 10:50
Hola chicos, pongo unas fotos de la antena casi terminada. Cada vez se hace más grande ( mamotreto), pero funcional. http://uploads.tapatalk-cdn.com/20160225/73660a63b62ad351fb9c45a5be40a355.jpghttp://uploads.tapatalk-cdn.com/20160225/ab62286362ea4180aa0c53f5ccb58643.jpghttp://uploads.tapatalk-cdn.com/20160225/0eec43a204bf2302f405b586c768d240.jpghttp://uploads.tapatalk-cdn.com/20160225/bcbe3bcc888f4d4da472dcb738ed4661.jpghttp://uploads.tapatalk-cdn.com/20160225/673835b360554f968dc7a4399d7983a8.jpghttp://uploads.tapatalk-cdn.com/20160225/16088e78228afc9c3fccbd5703ef9957.jpg

UTOPIAS
25/02/2016, 13:13
Guille;
Lo que pasa es que os gusta cacharrear, esto lo vendéis después a la NASA. :laugh::laugh:
Y la caja azul para sustituir qué o hacer qué?

sl2.

rortega
25/02/2016, 16:16
Es impresionante, la verdad. Y el OLED, de lujo.

UTOPIAS
25/02/2016, 16:47
En mi caso con la de 8 BITS, se mueve, por lo tanto si antes que la dejaba fija fui hasta casi 10Kms ahora ya con las prohibiciones, casi me da lo mismo que este desfasada 5º y que el TILT no haga 90º...:laugh::laugh:
Ya iré ajustando si puedo y Guille lo pillo desocupado y con ganas, ... que se lleva unos trajines ... :laugh::laugh:

salud, suerte y sl2.

Ivan_Cillo
25/02/2016, 20:12
Pues ya esta, ya he publicado el diseño 3d en thingiverse. Media hora y ya tiene 15 descargas...
Si me pasais las medidas de la pantalla nueva puedo modificar la tapa para si os quereis imprimir uno.
Ortega incluyelo en el repositorio como buenamente quieras.
A ver si consigo ir a probarlo al campo para ver como reacciona.

http://www.thingiverse.com/thing:1367337

Guillesan
25/02/2016, 21:53
Ole, Ivan lo reviso, fijo que será de fábula. Te agradezco tu trabajo, un saludo.

rortega
25/02/2016, 23:04
Ivan_Cillo, lo descargaré y lo subiré, además de poner el link a thingiverse.

¿Por otro lado, Guillesan, puedes sacarme algun log con tramas mavlink? No sé si en las pruebas que hiciste la última vez y que me enviaste ya viene esa información que necesito para pitch, roll, yaw...los archivos los conservo pero no me he puesto a ello. Pero si me pasas un log con tramas nuevas donde hagas movimientos del avión bruscos en los 3 ejes para ver que se reflejen bien los movimientos en el mission planer, será mucho mejor.

Ya tengo medio preparado el código que toma esos datos de la telemetría y la manda a la de salida...

Guillesan
25/02/2016, 23:15
Ivan_Cillo, lo descargaré y lo subiré, además de poner el link a thingiverse.

¿Por otro lado, Guillesan, puedes sacarme algun log con tramas mavlink? No sé si en las pruebas que hiciste la última vez y que me enviaste ya viene esa información que necesito para pitch, roll, yaw...los archivos los conservo pero no me he puesto a ello. Pero si me pasas un log con tramas nuevas donde hagas movimientos del avión bruscos en los 3 ejes para ver que se reflejen bien los movimientos en el mission planer, será mucho mejor.

Ya tengo medio preparado el código que toma esos datos de la telemetría y la manda a la de salida...

Ok lo estoy leyendo ahora, te hago el log mañana mismo y te lo mando.

rortega
25/02/2016, 23:41
Pues ya esta, ya he publicado el diseño 3d en thingiverse. Media hora y ya tiene 15 descargas...
Si me pasais las medidas de la pantalla nueva puedo modificar la tapa para si os quereis imprimir uno.
Ortega incluyelo en el repositorio como buenamente quieras.
A ver si consigo ir a probarlo al campo para ver como reacciona.

http://www.thingiverse.com/thing:1367337

Como estoy muy liado, lo que he hecho ha sido ponerlo en el README de la de 8 bits, con una foto (está un poco más abajo cerca del final de la página), y en la versión de 32 bits lo he puesto en la wiki a modo de enlace (está la información bastante completa en Thingiverse).

Guillesan
26/02/2016, 21:01
Hola Raul te paso el link de mi dropbox veras dos capturas
1 Captura del mavlink que sale del re`petidor softserial hacia el PC o Mobil etc...
2 Captura directa del bluetooh del TX Crossfire recibidas del avion, creo que tambien este tx le añade unas tramas de la rssi tanto dowlink como uplink de su propia transmision.
Espero te valga, saludos.

https://www.dropbox.com/sh/x82ug4kwgrnv47p/AABbnZowGV6BlAscIYZaQS44a?dl=0

rortega
26/02/2016, 21:49
Ok, ya lo tengo...mañana me pongo con ello.

Guillesan
26/02/2016, 21:50
Muy bien , ya diras

rortega
26/02/2016, 22:48
Decía que lo miraría mañana porque tenía pendiente probar con el oruxmaps las tramas RMC, que ayer haciendo pruebas no marcaba bien el rumbo la flechita, y me he puesto hace 20 minutos y ya está solucionado, ya por fín veo altitud, velocidad, rumbo (course), etc... en el oruxmaps, así que ya tenemos un problema solucionado...

La idea es leer los datos que se puedan desde otros protocolos, y convertirlos a NMEA. De momento de GPS TELEMETRY de entrada, a NMEA de salida, va bien.

Con mavlink la idea es similar, intentar que desde otros protocolos de entrada saque hacia mavlink todos los datos que sean posible. En el caso por ejemplo de tener de entrada mavlink y salida mavlink no debería haber problema. Pero de GPS Telemetry a Mavlink va a estar limitadillo. No se si se entiende lo que intento explicar.

Lo de mavlink lo voy a probar ahora a ver si ya tengo toda la info que necesito en la telemetría de salida. Lo implementé ayer pero no llegué a probarlo.

Simba
26/02/2016, 22:59
Ok
Desde luego de donde no hay no se puede sacar y si nmea es lo que da pues ya está y punto.
En principio según yo lo entiendo, solo se pretendía hacer funcionar el Orux, por ser sencillo y cómodo de utilizar en el móvil, y este utiliza nmea.
Si hay alguna otra utilidad la desconozco, pero creo que al final se puede complicar mucho el tema.

¿Entonces ya se puede utilizar el Orux con la Gps Telemerty????

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
26/02/2016, 23:08
¿Entonces ya se puede utilizar el Orux con la Gps Telemerty????


Sí, pero aún no lo he subido al repositorio.

Simba
26/02/2016, 23:10
Ok pues nada cuando toque ya lo probaremos.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
26/02/2016, 23:25
Guillesan, las capturas que me has pasado no se las traga el tracker. Puede que las hayas capturado a los baudios equivocados?

De todos modos, he probado con la captura que me pasaste la otra vez y ahora ya si veo datos de course y datos de inclinación en los 3 ejes.

Lo vo ya subir en unos minutos al repositorio, tras probar que el tracker funcione normalmente en MFD y GPS Telemetry, que es lo más que puedo probar ahora...

rortega
27/02/2016, 00:38
No lo he subido aún, tengo un desplazamiento de unos 40km en el Orusmaps, no lo había apreciado hasta hace un momento...

Guillesan
27/02/2016, 09:43
Hola Raul he vuelto a subir una captura "nuevo" del mavlink de crossfire, confirmado que esta en 57600 ok. Mira si esta si sirve.

rortega
27/02/2016, 11:32
Ya está subida la nueva versión:



Disponible posición, altitud, velocidad, course para Oruxmaps
Disponible posición, altitud, course, Yaw,Pith,Roll para mavlink con Mission Planner, Droidplanner, etc...

Espero que la disfrutéis y reportéis problemas.

Guillesan, no he probado los archivos, te va a tocar a tí probarlo en vivo. Se notará un pequeño lag porque ahora toca construir más paquetes mavlink para enviarlos al puerto serie de salida...a mí a 9600 buadios de salida hacia el Droidplanner me va, pero noto ese pequeño retrasillo...

Guillesan
27/02/2016, 11:40
Vale Raúl lo subo y pruebo, por cierto hoy aquí muy mal día, llueve y se espera nieve........ Eso a ti no fu ni fa, acostumbrado estarás.
En otro orden estoy montando una antena Tracker mini para los días tranquilos......http://uploads.tapatalk-cdn.com/20160227/b3c78ec9011cb08af936e7e1958d910e.jpg

rortega
27/02/2016, 12:01
Vale Raúl lo subo y pruebo, por cierto hoy aquí muy mal día, llueve y se espera nieve........ Eso a ti no fu ni fa, acostumbrado estarás.
En otro orden estoy montando una antena Tracker mini para los días tranquilos......

¡Ostras! Diseño nuevo de los alemanes ?

Aquí soleado hoy después de una semana de perros...

Yo ahora montando las piezas de recambio en el micro, a ver si soy capaz de probar el tracker mañana con FrSKY D en el campo.

Ivan_Cillo
27/02/2016, 12:03
Una duda que me surje para el uso con orange lrs, hay que usar la versión gitsly independientemente de si se define gps telemetry, mavlink u otro protocolo? O es solo para gps?

Enviado desde mi DG800 mediante Tapatalk

Guillesan
27/02/2016, 12:19
No Gitsly es específico para Mavlink. Para gps_telemetry te vale cualquiera version

Simba
27/02/2016, 12:21
Una duda que me surje para el uso con orange lrs, hay que usar la versión gitsly independientemente de si se define gps telemetry, mavlink u otro protocolo? O es solo para gps?

Enviado desde mi DG800 mediante Tapatalk

Ostras Ivan no te entiendo, lo del gitsly no se ni lo que es.
Tu montale un GPS al Rx Orange, a 4800 bauds y a 4hz con solo trama GPGGA, y ya esta no tienes que hacer nada mas chico.
En el Traker le dices que es GPS Telemetry a 4800 y listo a trakear sin ningún problema.

Guillesan
27/02/2016, 12:23
Gitsly es el nombre de una versión openlrs con cambios específicos para transmitir telemetria Mavlink, con mejor respuesta. Es el nombre del programador que la a versiónado

rortega
27/02/2016, 12:24
Lleva aquí el tracker media hora o más dando vueltas el solo, como si tuviese vida propi,a jeje...Lo tengo en GPS telemetry a modo de pruebas a ver si casca o algo, pero no, va perfecto.

También compruebo en el Orux maps la posición y no falla...

Por cierto, veréis en la página de inicio en el display algo más que la versión del firmware ...

Guillesan
27/02/2016, 12:24
Vaya, vaya.

Ivan_Cillo
27/02/2016, 12:28
Ostras Ivan no te entiendo, lo del gitsly no se ni lo que es.
Tu montale un GPS al Rx Orange, a 4800 bauds y a 4hz con solo trama GPGGA, y ya esta no tienes que hacer nada mas chico.
En el Traker le dices que es GPS Telemetry a 4800 y listo a trakear sin ningún problema.

Ya Simba, pero de momento lo voy a usar para el avion con Myflydream por lo que aprovechare el mavlink y no añado mas peso.

No Gitsly es específico para Mavlink. Para gps_telemetry te vale cualquiera version

Muchas gracias Guille, flasheare el equipo entonces.
Por cierto muy chulo el diseño nuevo del tracker.

Guillesan
27/02/2016, 12:29
Está en thinguiverse, lo imprimí antes de ver el tuyo, es muy pequeñita

Simba
27/02/2016, 12:32
Raul, voy bajando ultima versión y probaremos el Orux.

Otra cosa, me he llevado un chasco, resulta que me he enredado con la configuración de Filp32 en un Quad, para ponerle el GPS y sacar telemetria LTM, para metersela en el Rx Orange, tal como comentamos con Ivan hace unos dias.
Pues bien yo no sabia que el Cleanflight 1.2.1 Ultimo, no reconoce mi versión anterior del Micro250, total que para no perder toda la configuración del Micro, he tenido que volver a la version de Cleanflight anterior, para guardar la configuración tengo en el micro.
En fin un lio, que con tanto trasto como llevamos, al final es mucho al menos para mi.
Supongo que sto nos pasa a todos.

rortega
27/02/2016, 12:35
Raul, voy bajando ultima versión y probaremos el Orux.

Otra cosa, me he llevado un chasco, resulta que me he enredado con la configuración de Filp32 en un Quad, para ponerle el GPS y sacar telemetria LTM, para metersela en el Rx Orange, tal como comentamos con Ivan hace unos dias.
Pues bien yo no sabia que el Cleanflight 1.2.1 Ultimo, no reconoce mi versión anterior del Micro250, total que para no perder toda la configuración del Micro, he tenido que volver a la version de Cleanflight anterior, para guardar la configuración tengo en el micro.
En fin un lio, que con tanto trasto como llevamos, al final es mucho al menos para mi.
Supongo que sto nos pasa a todos.

Sí, sí, son cosas que suelen pasar. Lo suyo es tener la configuración de cleanflight guardada en un archivo de texto, porque simpre que metes una versión nueva hay parámetros nuevos y ocupa también distinto espacio de memoria, lo que hace que se pisen. Yo lo aprendí cuando empezaba con los multis usando Multiwii.

Simba
27/02/2016, 12:45
Una cosa Raul, yo sigo utilizando el puente boot para cargar nueva V., ¿es correcto o se puede hacer sin el puente?, ya no me acuerdo si lo explicaste de otro modo.

rortega
27/02/2016, 14:10
Una cosa Raul, yo sigo utilizando el puente boot para cargar nueva V., ¿es correcto o se puede hacer sin el puente?, ya no me acuerdo si lo explicaste de otro modo.

Se puede hacer sin el puente.

Yo lo que hago es que con el cable usb puesto, entro en el CLI desde hércules y ejecuto el comando:

boot mode

Se encienden todos los leds quedándose fijos.

Acto seguido pulso close en el hércules y ya puedo proceder a cargar el firmware con el Flash Loader.

Recuerda que al poner en boot mode, los baudios quedan a 115200 por defecto para la carga del firm.

Simba
27/02/2016, 16:16
Hola, algo está pasando que no me convence.

No puedo ajustar el offset, y no me ajusta a donde debe.

Mira a ver si la versión esta corrupta o que pasa pero no consigo que marque el angulo que toca.
Tal como lo tenia antes yo ajustaba offset=270, pero ahora con esa configuración el norte me marca 140º.

Simba
27/02/2016, 16:23
Vale ya se lo que pasaba, que en la nueva versión, el pan0=1500 lo has puesto a 0 y claro quien lo iba a pensar.

De todos modos mira a ver si soy yo que he cambiado sin darme cuenta.

rortega
27/02/2016, 16:32
Vale ya se lo que pasaba, que en la nueva versión, el pan0=1500 lo has puesto a 0 y claro quien lo iba a pensar.

De todos modos mira a ver si soy yo que he cambiado sin darme cuenta.

No, no lo he puesto a cero. Eso será por lo que he comentado antes, que al cambiar de versión la configuración va a parar a otra posición de memoria. Si al subir el firmware no le dices al Flash Loader que borre la memoria antes de subir, es posible que tome valores de donde no debe...

rortega
27/02/2016, 16:34
Aún no he almorzado, me he liado tontamente con ésto:

http://www.u360gts.com/

Estoy empezando a perder el norte ...

Simba
27/02/2016, 16:50
Joer que de P.M. que te esta quedando, ya tenemos Hueveria y todo.

Una pregunta, pero almuerza o come o merienda, pero alimentate que eso si que es perder el norte.

¿Como le indico, que lo que quiero que salga por el Bluetooht, es el NMEA ? o GPS_telemetry, para verlo en el Oruxmap.

Guillesan
27/02/2016, 17:07
Aún no he almorzado, me he liado tontamente con ésto:

http://www.u360gts.com/

Estoy empezando a perder el norte ...

Esa web va a ser un bombazo en el mundo FPV.
Vas a ver como se apuntan a montar.
Un saludo, a por cierto come coño no te vayas a poner malo, dicho con todo el interes que tengo en el tema. jajajaja

rortega
27/02/2016, 17:08
Joer que de P.M. que te esta quedando, ya tenemos Hueveria y todo.

Una pregunta, pero almuerza o come o merienda, pero alimentate que eso si que es perder el norte.

¿Como le indico, que lo que quiero que salga por el Bluetooht, es el NMEA ? o GPS_telemetry, para verlo en el Oruxmap.

Primero tienes que éstos comandos:

feature softserial
feature telemetry

Dime los baudios y te pongo el comando serial ya preparado para que lo metas.

rortega
27/02/2016, 17:12
Esa web va a ser un bombazo en el mundo FPV.
Vas a ver como se apuntan a montar.
Un saludo, a por cierto come coño no te vayas a poner malo, dicho con todo el interes que tengo en el tema. jajajaja

Que vá, ya he comido...es que son de estas cosas que o las haces o rebientas...

La estética de la página se puede mejorar, está claro, pero lo importante es el mensaje. Cuando tenga el tracker "bonito" (tú ya me entiendes), voy a poner una imagen completa, no sólo la antena...

La imagen de la página principal es un montaje de varias imágens, todas mías. El avión, que no es el mejor del mundo, es mío, mi Raptor 1600 mm, el que me trae de cabeza con ésto del tracker... El pobre está en España, y yo aquí :-beg:... Lleva montada pixhawk y toda la parafernalia necearia ...

Guillesan
27/02/2016, 17:14
Que vá, ya he comido...es que son de estas cosas que o las haces o rebientas...

La estética de la página se puede mejorar, está claro, pero lo importante es el mensaje. Cuando tenga el tracker "bonito" (tú ya me entiendes), voy a poner una imagen completa, no sólo la antena...

La imagen de la página principal es un montaje de varias imágens, todas mías. El avión, que no es el mejor del mundo, es mío, mi Raptor 1600 mm, el que me trae de cabeza con ésto del tracker... El pobre está en España, y yo aquí :-beg:... Lleva montada pixhawk y toda la parafernalia necearia ...
Sobre fotos puedes usar alguna de las mias si quieres, ok

Simba
27/02/2016, 17:17
Primero tienes que éstos comandos:

feature softserial
feature telemetry

Dime los baudios y te pongo el comando serial ya preparado para que lo metas.
Pues supongo que serán 4800, por que yo lo tengo como la GPS_Telemetry del Orange a 4800.

Simba
27/02/2016, 17:22
Yo lo que tengo ahora es esto:

Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING


serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 512 115200 57600 57600 115200
serial 31 0 115200 57600 0 115200

Simba
27/02/2016, 17:25
Pues supongo que serán 4800, por que yo lo tengo como la GPS_Telemetry del Orange a 4800.

Rectifico deben de ser, 57600 ¿no?

Simba
27/02/2016, 17:41
Con esa configuración que he puesto, era como lo seguía con Mavlink en la Tablet.
Pero lo intento ahora con el Orux y no veo que lo siga.

Me voy centrando y comprendiendo, supongo que los 512 son MAVLINK, y ahora hay que meter otro numero que corresponderá a la GPS_Telemetry.

rortega
27/02/2016, 18:21
Con esa configuración que he puesto, era como lo seguía con Mavlink en la Tablet.
Pero lo intento ahora con el Orux y no veo que lo siga.

Me voy centrando y comprendiendo, supongo que los 512 son MAVLINK, y ahora hay que meter otro numero que corresponderá a la GPS_Telemetry.

Tienes que poner 1024 en lugar de 512.

Disculpa por no comentarlo antes.

Simba
27/02/2016, 18:33
Tienes que poner 1024 en lugar de 512.

Disculpa por no comentarlo antes.

Tengo puesto tal como esto y no funciona:

# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 57600 115200
serial 31 0 115200 57600 0 115200

rortega
27/02/2016, 18:37
Tengo puesto tal como esto y no funciona:

# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 57600 115200
serial 31 0 115200 57600 0 115200

Define "no funciona"...

Cosas a tener en cuenta, por si acaso se te pasa algo:



La posición HOME debe estar establecida.
El seguimiento debe haberse iniciado.
No funciona en modo CLI.
Guardar los cambios con save en lugar de salir con exit.
El módulo bluetooth debe vincularse (a veces se desvincula sólo y Oruxmaps pide vincularlo nuevamente).

A mí me da muchos problemas el bluetooth, tengo que andar quitándole alimentación y dándole, unas veces apagar bluetooth, desvincular, vincular ... pero es un problema del módulo que tengo, no del firm.

Simba
27/02/2016, 18:48
Define "no funciona"...

Cosas a tener en cuenta, por si acaso se te pasa algo:



La posición HOME debe estar establecida.
El seguimiento debe haberse iniciado.
No funciona en modo CLI.
Guardar los cambios con save en lugar de salir con exit.
El módulo bluetooth debe vincularse (a veces se desvincula sólo y Oruxmaps pide vincularlo nuevamente).

A mí me da muchos problemas el bluetooth, tengo que andar quitándole alimentación y dándole, unas veces apagar bluetooth, desvincular, vincular ... pero es un problema del módulo que tengo, no del firm.

Inicio secuencia como siempre, lanzo el simulador, hago Home sale Tetemetry Aircraft.
En Oruxmap configuro GPS externo, en el Bluetooht veo que el led se pone fijo (vinculado). en el Oruxmap se pone la flechita quieta sobre mi casa pero aunque el simulador está volando, está no se mueve.

Es como si no entendiera lo que le llega al Oruxmap, si es que le llega, pero el Bluetooht si que esta vinculado.

Hago lo mismo que con la Tablet y el Mavlink, que si que funcionaba.

rortega
27/02/2016, 19:00
...

Es como si no entendiera lo que le llega al Oruxmap, si es que le llega, pero el Bluetooht si que esta vinculado....

El tracker se mueve físicamente???

Guillesan
27/02/2016, 19:01
Simba as revisado tu mail privado en el foro?

rortega
27/02/2016, 19:05
Yo uso tres módulos bluetooth, dos de ellos están en el tracker, y conectado por ftdi al ordenador. Algunas veces me ocurre que los dos bluetooth del tracker se enlazan entre sí, y me quedo mirando la pantalla del móvil y no ocurre nada...

Otras veces, está emparejado bien con el móvil, pero no recibe señal, tengo que quitarle alimentación al módulo bluetooth y volverla a meter, clicar en desconectar gps en Oruxmaps, desactivar bluetooth en la configuración del móvil y vuelta a empezar...

Simba
27/02/2016, 19:13
El tracker se mueve físicamente???
Si el Traker se mueve perfectamente siguiendo al simulador, como siempre.

Y Guillesan lo tengo claro.

Raul como ya comente estoy haciendo lo mismo que con el Mavlink y la Tablet, solo le he cambiado lo comentado, el 215 por 1024, no he cambiado nada mas, por que ya lo tenia cambiado cuando utilizaba Mavlink.

rortega
27/02/2016, 19:18
Acabo de grabar un vídeo para que se vea que funciona:

https://www.youtube.com/watch?v=TsI-OmbA7lw

rortega
27/02/2016, 19:27
Simba pásame tu configuración que le eche un vistazo...

Simba
27/02/2016, 19:44
Mira raul para ver que no es problema del Orux, he conectado el Bluetooht directamente al PC, (ftdi usb) y tal como estaba solo cambiando los baudios en el simulador, ya que normalmente lo tengo con 4800 (Telemetria Orange), poniéndole lo del Bluetooht, es decir 57600 con solo esto el Oruxmap funciona perfectamente.

En el Traker yo tengo la entrada de Telemetria a 4800 (Telemetria Orange), y la salida del Bluetooht a 57600.
Lo que pase, pasa dentro de la Flip32, ya que el simulador y el bluetooht ellos solos funciona perfectamente.

La configuración de puertos y el feature ya lo he puesto varias veces, pero es está:
# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 57600 115200
serial 31 0 115200 57600 0 115200

Guillesan
27/02/2016, 20:38
Bueno la mini va tomando forma. Aquí una foticos, se aceptan críticas (constructivas)
Saludoshttp://uploads.tapatalk-cdn.com/20160227/c79448be2dc64f070d3aadb31eaa1d3e.jpghttp://uploads.tapatalk-cdn.com/20160227/60b07076d3c2f086f5f2ebdcd401bb4c.jpghttp://uploads.tapatalk-cdn.com/20160227/a640be8497e9e8258fc71da1f44d5cef.jpg

rortega
27/02/2016, 20:39
Simba, me tienes que disculpar que tarde tanto en contestar, es que he estado por Skype con mi mujer.

Te pedía la configuració completa, para yo intentar emularte aquí, por si acaso hay algún conflicto con alguna otra cosa.

¿Has mirado por casualidad si la versión en el display se corresponde con la nueva y no has vuelto a subir la antigua? Ya es por preguntar algo, porque como son tantas cosas las que hacemos, se podría estar olvidando cosas tontas...

Simba
27/02/2016, 20:41
Je je jaja ya pero no es la 3.1.0 es lo primero que miro al arrancar.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
27/02/2016, 20:43
Simba comprueba la versión por si acaso, que ya nos ha pasado en otra ocasión que al sincronizar el repositorio no se subía y se quedaba la antigua.

Guille, es espectacular, me encanta... y veo que tiene el hueco para el OLED grande...

Simba
27/02/2016, 20:46
Simba comprueba la versión por si acaso, que ya nos ha pasado en otra ocasión que al sincronizar el repositorio no se subía y se quedaba la antigua.

Guille, es espectacular, me encanta... y veo que tiene el hueco para el OLED grande...

# version
# amv-open360tracker-32bits /NAZE 3.1.0 Feb 27 2016 / 10:08:48 (9e52ea2)

rortega
27/02/2016, 20:47
Pongo aquí mi configuración por si sirve de algo:

# set
Current settings:
gps_baud = 2
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 6
telemetry_inversion = OFF
battery_capacity = 0
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 3200
i = 50
d = 200
max_pid_error = 1
max_pid_accumulator = 5000
max_pid_gain = 500
pid_divider = 15
pan0 = 1528
pan0_calibrated = 1
min_pan_speed = 0
offset = 90.000
init_servos = 0
tilt0 = 1140
tilt90 = 2100
easing = 1
easing_steps = 20
easing_min_angle = 1
easing_milis = 15
telemetry_baud = 6
telemetry_protocol = 8
start_tracking_distance = 10
mag_declination = 207
min_logic_level = 15

# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# serial
serial 0 1 115200 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 9600 115200
serial 31 0 115200 57600 0 115200

Yo lo tengo a 9600, pero también la he probada a otras velocidades conectando directamente un ftdi.

rortega
27/02/2016, 20:49
# version
# amv-open360tracker-32bits /NAZE 3.1.0 Feb 27 2016 / 10:08:48 (9e52ea2)

Yo tengo la misma:

amv-open360tracker-32bits /NAZE 3.1.0 Feb 27 2016 / 10:08:48 (9e52ea2)

No sé, no sé que haces tú distinto o que tienes distitno a mí ...

Simba
27/02/2016, 20:52
Solo esto:

serial 30 1024 115200 57600 9600 115200

Yo tengo
serial 30 1024 115200 57600 57600 115200
Por que mi Bluetooht lo tengo a 57600

rortega
27/02/2016, 20:54
Solo esto:

serial 30 1024 115200 57600 9600 115200

Yo tengo
serial 30 1024 115200 57600 57600 115200
Por que mi Bluetooht lo tengo a 57600

Pues como no le esté costando al softserial por estar trabajando a 57600, otra cosa no se me ocurre que pueda ser.

Simba
27/02/2016, 20:55
Espera voy a poner el Bluetooht a 9600 y pruebo.

Simba
27/02/2016, 21:23
Vale siento la paliza que estoy dando, pero sigue sin funcionar, hace exactamente lo mismo, con el bluetooht a 9600 y esta configuración:

# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 9600 115200
serial 31 0 115200 57600 0 115200

# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# dump

# dump configuration


# feature
feature EASING



# feature
set gps_baud = 2
set gps_provider = NMEA
set gps_sbas_mode = AUTO
set gps_auto_config = ON
set gps_auto_baud = OFF
set home_min_sats = 6
set p = 6000
set i = 150
set d = 10000
set max_pid_error = 1
set max_pid_accumulator = 12000
set max_pid_gain = 500
set pid_divider = 15
set pan0 = 1500
set pan0_calibrated = 1
set min_pan_speed = 0
set offset = 270.000
set init_servos = 0
set tilt0 = 2025
set tilt90 = 1050
set easing = 1
set easing_steps = 20
set easing_min_angle = 4
set easing_milis = 15
set telemetry_baud = 1
set telemetry_protocol = 8
set start_tracking_distance = 10

#

rortega
27/02/2016, 21:40
No te creas que no estoy pendiente al tema, estoy nada más que dándole vueltas a la azotea a ver que puede ser.

¿Estás enviando tramas GGA y RMC? Se necesitan enviar las dos ...

Simba
27/02/2016, 22:29
Si estoy con las dos gga y rmc

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
27/02/2016, 22:30
Raúl dejalo y descansa que con tranquilidad mañana igual lo vemos mejor.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
27/02/2016, 22:34
Raúl dejalo y descansa que con tranquilidad mañana igual lo vemos mejor.

Sí, será lo mejor...

rortega
28/02/2016, 08:52
Una pregunta de principiante. ¿Qué software estáis usando para diseñar o modificar diseños existentes en 3D? Quiero hacer una "infografía" 3D, o como lo queramos llamar del tracker, y pensaba hacerlo desde cero con Blender, pero imagino que partiendo de alguno de los diseños será más fácil, y no tengo ni idea de que software se está utilizando. Sé que algunos, los más osados, usan Blender y otros SketchUp, pero supongo que habrá algo más simple...

ALBERTHAMON
28/02/2016, 08:58
Bueno la mini va tomando forma. Aquí una foticos, se aceptan críticas (constructivas)
Saludoshttp://uploads.tapatalk-cdn.com/20160227/c79448be2dc64f070d3aadb31eaa1d3e.jpghttp://uploads.tapatalk-cdn.com/20160227/60b07076d3c2f086f5f2ebdcd401bb4c.jpghttp://uploads.tapatalk-cdn.com/20160227/a640be8497e9e8258fc71da1f44d5cef.jpg

Hola Guillesan,
yo si que tengo una critica y por supuesto muy constructiva :wink2::wink2:

echo en falta un primer post con enlaces a todos los avances y mejoras que se van haciendo sobre el tracker.
Hay dos partes importantes sobre el tracker, una el soft y otra el hardware, pero ninguna de las dos estan reflejadas en el primer post.
Si que es cierto que correctisimamente en el primer post informas y diriges hacia el foro aleman con el proyecto original, pero a día de hoy, gracias a vuestra labor, del proyecto aleman queda poco.
En software ya se le han pegado 1.000 vueltas a los alemanes y que no se me mal interprete, solo pretendo decir que Raul ha incluido muchas mejoras a ese proyecto y ademas ha implementado el codigo en 32 bits. Pues no hay nada en la primera pagina de este tema.

En harware hay unas cuantas versiones de chasis, pero hay 2 o 3 muy importantes que a dia de hoy deberían de aparecer tambien en la primera pagina. Está el chasis aleman para impresion 3D(en alguna de las ciento y pico paginas lo subi.), está la version de Ivan_Cillo http://www.thingiverse.com/thing:1367337, está la version mini a la que has hecho referencia http://www.thingiverse.com/thing:1351489, y como no, unos cuantos productos que se entan probando y que son importantes porque se esta trabajando en el codigo para que se puedan implementar, como son los oled...

De veras que solo es una critica constructiva y no os lo tomeis a mal porque lo exprese por aqui, porque insisto que estais haciendo un gran trabajo, pero a mi entender no brilla lo que podría brillar porque queda tapado con el efecto "chat" que se genera con los mensajes de pruebas y pruebas que afortunadamente estais haciendo para que esto funcione.

Guillesan, solo como sugerencia, podrias pedir a los administradores que os hicieran moderadores a los 4(Guillesan,Rortega,Turruk y Simba) y que os dieran a los 4 autorizacion para editar este tema.
Si os repartís 30 paginas entre los 4 seguro que en una mañana de lluvias encontrais unos cuantos mensajes a los que podrian redirigir desde la pagina principal y se viese el buen trabajo que habeis hecho.


Perdon por el tocho y de veras que no pretendo ofender a nadie, pero cada vez que entre en el foro y me pongo a leer el tema del tracker me duele ver como se encuentra cuando en realidad hay un monton de trabajo empleado y que no se está aprovechando.

Por cierto, el chasis mini que has puesto se ve muy elaborado. mola un monton. ya diras que tal va.

Saludos,

rortega
28/02/2016, 09:08
Hola Guillesan,
yo si que tengo una critica y por supuesto muy constructiva :wink2::wink2:...

+1

Creo que es verdad, un primer post resumiendo el proyecto, no necesariamente extenso, con esos links bien estructurado, es una muy buena idea.

Guillesan, si os parece hago una pequeña introducción, esquema, te lo paso y lo vamos completando... Sugiero poner un párrafo corto arriba, los enlaces estructurados a continuación, y una descripción del proyecto por debajo.

Alguno de vuestros vídeos con el tracker funcionando, pero que no se mueva tanto la cámara como en los últimos, estaría genial.

Guillesan
28/02/2016, 09:13
Hola. Alberthamon estoy de acuerdo. Molestarse que va hombre. Gracias por tu consejo. Raúl espero que me hechas una mano también en esto. El proyecto se ha hecho tan grande como no podía haber previsto. Espero indicaciones concretas y lo hacemos. Saludos

rortega
28/02/2016, 10:43
He realizadao un boceto para esa introducción del primer post. Faltaría completar las listas de componentes, etc., e ir poniendo enlaces a los posts donde se hablen de esas cosas, así como los enlaces de compra, por ejemplo.

Cómo no se pueden subir archivos pdf al foro, lo he subido al repositorio para que le podáis echar un vistazo:

https://github.com/raul-ortega/amv-open360tracker/blob/master/docs/introduccion-primer-post-del-foro.pdf

Guille la pelota está en tu tejado, je je...

Guillesan
28/02/2016, 10:45
Más que pelota, pelotazo. Me pongo a ello.

Simba
28/02/2016, 10:46
Raúl respecto a lo de ayer quería preguntar una cosa.
Comentaste algo respecto a la carga de la versión que había que borrar la memoria antes de cargar.
¿ Podría ser ese el problema? Dime como se borra y después la cargo.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
28/02/2016, 10:48
Yo nunca he borrado nada.
Además si que note algo que me sorprendió y es que es más lenta de respuesta al entrar en cli al principio.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
28/02/2016, 10:49
Simba, ha habido algún avance con lo del oruxmaps?

A ver si alguien más puede probarlo y reporta la experiencia... Yo lo he probado hasta la saciedad, y los problemas que me encuentro son con la conexión bluetooth que algunas veces pierdo el emparejamiento, me veo obligado a quitar alimentación al módulo bluetooth y demás... puede incluso que sea por culpa de la versión de android que uso. No sé que te puede estar pasando a tí...

rortega
28/02/2016, 10:49
Ostras, te estaba preguntando mientras tú contestabas...

rortega
28/02/2016, 11:01
Yo nunca he borrado nada.
Además si que note algo que me sorprendió y es que es más lenta de respuesta al entrar en cli al principio.

Enviado desde mi GT-I9505 mediante Tapatalk

El que sea más lento ¿Te pasa cuando has configurado 1024 como protodolo de salida? Podría ser que sea más lenta no sólo cuando emitimos NEMA, sino también cuando emitimos MAVLINK, porque se envían tramas con frecuencas de 100 milisegundos en NEMA y similar en MAVLINK...

Prueba a desactivar la telemetría de salida a ver si se quita esa lentitud de respuesta del cli.

Días atrás hice una refactorización del código (limpiar, ordenar, ...) con idea de tener el código más claro y limpio, que ya cada vez se hace más complejo modificarlo.

Anoche echando un vistazo, vi en el código algo que no necesariamente tenga que ver con el problema, pero que podría aportar algo de lentitud, y es la frecuencia con la que hago la llamda a la parte de código que gestiona la telemetría de salida, e incluso a la monitorización de la batería.

Aún no lo he probado, pero voy a hacerlo en unos minutos, y creo que voy a bajar también la frecuencia de emisión de tramas NMEA a 200ms, osea, 10 tramas por segundo, 5 GGA + 5 RMC, es decir, 2 tramas cada 200ms).

Si así no va bien, probaremos a alternalas poniendo una cada 125 o 150 milisegundos, esto es, una trama GGA y al cabo de 150ms una RMC y al cabo de 150ms otra GGA...

Todo esto por si acaso tuviese algo que ver, pero ya te digo que yo a 9600 no estoy teniendo problema alguno por esos motivos.

Simba
28/02/2016, 11:04
OK pero no me contestas a lo que te pregunte de si es necesario borrar antes de cargar y como.

rortega
28/02/2016, 11:09
Raúl respecto a lo de ayer quería preguntar una cosa.
Comentaste algo respecto a la carga de la versión que había que borrar la memoria antes de cargar.
¿ Podría ser ese el problema? Dime como se borra y después la cargo.

Enviado desde mi GT-I9505 mediante Tapatalk

Lo de borrar la memoria, es en el paso donde se elecciona el archivo del firmware. Justo debajo hay 3 opciones. Yo marco siempre "Global Erase".

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64141&stc=1&d=1456654142

rortega
28/02/2016, 11:09
OK pero no me contestas a lo que te pregunte de si es necesario borrar antes de cargar y como.

Te lo estaba pintanto :sad:

Simba
28/02/2016, 11:12
Vale gracias, pues lo estoy haciendo, lo borro y vuelvo a empezar.

rortega
28/02/2016, 11:56
He subido al repositorio el firm con las mofificaciones que he comentado.

Ahora las tramas se envían de forma alterna una cada 150ms.

Lo he probado y funciona en oruxmaps perfectamente.

Es cierto que antes de realizar las modificaciones he probado y parecía más lenta la entrada al cli. Parece que con estos cambios mejora.

rortega
28/02/2016, 12:10
Guillesan, te anticipo que el course y los datos de inclinación no están funcionando en mavlink...lo estoy solucionando y probando (lo del course al menos). Son demasiadas cosas las que comprobar y tener en cuenta y algunas veces se me escapan detalles muy tontos.

Simba
28/02/2016, 12:12
Pues me parece muy bien, pero me podía haber esperado a hacer las pruebas, que no me sirvieron para nada.

Volví a cargar y meter todos los parametros de feature y serial, pero podo sigue igual.

He vuelto a probar el protocolo de salida Mavlink y este si que funciona, vamos igual que antes, con la tablet y el DroidPlaner el seguimiento es perfecto.

Pero el protocolo GPS_Telemetry y el Oruxmap sigue sin funcionar.

Esta tarde cuando pueda VOLVERE que no cunda el pánico, a cargar la nueva V. y comento.

Ale me voy a tomar el aire.

Guillesan
28/02/2016, 12:12
Tranquilo Raúl, no había flasheado, estoy con la 3.0.0 . También para mí son muchas cosas a tener en cuenta. Estoy liado con tu doc.... Para informar el proyecto.

rortega
28/02/2016, 12:15
Hoy quiero empezar a meterle mano al configurator para google Chrome, para hacer todo ésto de configurar de forma más amena...

ALBERTHAMON
28/02/2016, 12:18
Hola. Alberthamon estoy de acuerdo. Molestarse que va hombre. Gracias por tu consejo. Raúl espero que me hechas una mano también en esto. El proyecto se ha hecho tan grande como no podía haber previsto. Espero indicaciones concretas y lo hacemos. Saludos

He realizadao un boceto para esa introducción del primer post. Faltaría completar las listas de componentes, etc., e ir poniendo enlaces a los posts donde se hablen de esas cosas, así como los enlaces de compra, por ejemplo.

Cómo no se pueden subir archivos pdf al foro, lo he subido al repositorio para que le podáis echar un vistazo:

https://github.com/raul-ortega/amv-open360tracker/blob/master/docs/introduccion-primer-post-del-foro.pdf

Guille la pelota está en tu tejado, je je...

genial!!
me alegro un monton que lo hayais tenido en cuenta. Seguro que es una ventaja para todos aquellos que quieran hacerlo. Ademas, evitará muchas preguntas repetidas y dejará el foro mas limpio para la investigacion y desarrollo que venis haciendo.

aqui te dejo el diseño aleman en 3D por si quieres incluirlo. Me costó mucho localizarlo en el foro aleman.
http://www.aeromodelismovirtual.com/showpost.php?p=489094&postcount=3902
http://www.aeromodelismovirtual.com/showpost.php?p=489095&postcount=3903
http://www.aeromodelismovirtual.com/showpost.php?p=489097&postcount=3904

saludos,

Guillesan
28/02/2016, 12:22
Una pequeña consideración, no sé si digo tonterías pero... teniendo en cuenta los problemas que están saliendo en la rediré cono de la telemetria softserial no sería posible simplemente redireccionar ( transparente) la entrada a una salida ? Entiendo los problemas en la conversión Mavlink-nmea, nmea-Mavlink , MFD-nmea etc . Pero sin necesitar cambio de protocolo no hay posibilidad de enviar la entrada a una salida?

Guillesan
28/02/2016, 12:24
Alberthamon tenias toda la razón , tengo problemas yo para recopilar imagínate a un recién llegado. Estamos en ello. Espero darle más "luz" a la cosa

Simba
28/02/2016, 12:33
Una pequeña consideración, no sé si digo tonterías pero... teniendo en cuenta los problemas que están saliendo en la rediré cono de la telemetria softserial no sería posible simplemente redireccionar ( transparente) la entrada a una salida ? Entiendo los problemas en la conversión Mavlink-nmea, nmea-Mavlink , MFD-nmea etc . Pero sin necesitar cambio de protocolo no hay posibilidad de enviar la entrada a una salida?
+1 tienes razón Guillesan, yo no necesito convertir nada, solo tener una salida con lo mismo de la entrada, entra GPS_Telemetry y sale GPS_telemetry, al menos en el caso que yo estoy teniendo, no necesito convertir, es mas con una simple Y en la entrada lo sulucionaria.

rortega
28/02/2016, 14:53
Una pequeña consideración, no sé si digo tonterías pero... teniendo en cuenta los problemas que están saliendo en la rediré cono de la telemetria softserial no sería posible simplemente redireccionar ( transparente) la entrada a una salida ? Entiendo los problemas en la conversión Mavlink-nmea, nmea-Mavlink , MFD-nmea etc . Pero sin necesitar cambio de protocolo no hay posibilidad de enviar la entrada a una salida?

Sí, es algo que tengo anotado para realizarlo, ya lo hemos comentado en alguna ocasión.

No obstante, la conversión desde otros protocolos distintos al de salida ya que está hecho no la vamos a descartar.

Problemas no debería dar más allá de lo comentado, que tampoco tengo muy claro de por donde vienen, pues a mí me funciona de maravilla (salvo el course en mavlink de salida que no consigo hacer que la flecha apunte a su sitio).

De todos modos, como dice Simba, lo más simple es la "Y".

rortega
28/02/2016, 15:35
Estoy a punto de probar el reenvío sin conversión:

NMEA a NMEA
MAVLINK a MAVLINK

Así que no os déis mucha prisa en cargar y probar hasta que no os avise, para que no tengáis que hacerlo dos veces.

Ivan_Cillo
28/02/2016, 16:02
Una pregunta de principiante. ¿Qué software estáis usando para diseñar o modificar diseños existentes en 3D? Quiero hacer una "infografía" 3D, o como lo queramos llamar del tracker, y pensaba hacerlo desde cero con Blender, pero imagino que partiendo de alguno de los diseños será más fácil, y no tengo ni idea de que software se está utilizando. Sé que algunos, los más osados, usan Blender y otros SketchUp, pero supongo que habrá algo más simple...
Aunque no entiendo que es a lo que te refieres con infografía 3d (igual es porque llevo currando 10h...) te informo de que yo uso sketchup

Enviado desde mi DG800 mediante Tapatalk

rortega
28/02/2016, 16:24
Aunque no entiendo que es a lo que te refieres con infografía 3d (igual es porque llevo currando 10h...) te informo de que yo uso sketchup

Enviado desde mi DG800 mediante Tapatalk

Gracias...

rortega
28/02/2016, 16:26
Bueno, no funciona correctamente el reenvío, me deja la placa muerta.
No es tan simple de implementar, aunque el concepto lo sea ...

He subido versión 3.3.0 con unos cambios que afectan al número de tramas mavlink que se envía, ahora es un poco más libiano pues sobraba una trama.

Guillesan
28/02/2016, 16:36
Raúl la bajo e instalo? O espero para novedades mayores, tú dirás si necesitas la pruebe

rortega
28/02/2016, 16:40
Raúl la bajo e instalo? O espero para novedades mayores, tú dirás si necesitas la pruebe

Hombre si la subes puedes probar lo del tema de los movimientos de yaw, pitch, rolll...

Guillesan
28/02/2016, 16:40
Ok entendido, en un rato reporto

rortega
28/02/2016, 16:44
Ok entendido, en un rato reporto

Juraría que me habías pasado otra vez las capturas mavlink, pero estoy buscando el link en las últimas páginas y no lo encuentro...

Guillesan
28/02/2016, 16:47
Hay una captura "nuevo" es directa de Crossfire ok
https://www.dropbox.com/sh/x82ug4kwgrnv47p/AABbnZowGV6BlAscIYZaQS44a?dl=0

rortega
28/02/2016, 16:52
Hay una captura "nuevo" es directa de Crossfire ok
https://www.dropbox.com/sh/x82ug4kwgrnv47p/AABbnZowGV6BlAscIYZaQS44a?dl=0

Pues tampoco va.

Puede que antes no la hicieras con Mac?

Guillesan
28/02/2016, 16:53
Está hecho con Mac si.

Guillesan
28/02/2016, 16:54
Perdón quería decir antes no era con Hércules ahora con un programa de Mac

Guillesan
28/02/2016, 17:02
Bingo funciona, se mueve el horizonte artificial en APM. Por cierto no lo hace hasta que se posiciona todo, antena y avion, pero eso es lo que se espera para volar no.

Guillesan
28/02/2016, 17:07
Otra curiosidad en el programa QGroundcontrol se reciben los datos de horizonte etc.. pero no lo posiciona en el mapa `por que dice "no gps lock for vehicle #100" , entiendo dice que no esta fix el gps AVION , que de hecho si lo esta pero el MyFlyDream no lo envia "o gps fix, numero satelites" y por eso se queja.

Simba
28/02/2016, 17:33
Guillesan, tu que estas al loro de los programas, ¿que hay a parte del Oruxmap? preferiblemente para el Android Movil, y también para Tablet Android.

Como ya comenté, tengo probado el DroidPlaner en la Tablet, y funciona bien con Mavlink, pero si conoces algún otro programa lo probaría.

Lo curioso del caso es que con Mavlink funcione bien, y con GPS_Telemetry no funcione, supongo que las tramas Mavlink son mucho mas fáciles de interpretar.

Guillesan
28/02/2016, 17:36
Puedes probarlo con Google Earth , herramientas/GPS/ tiempo real/ iniciar, buscará el puerto conectado y te pondrá el punto, a buen fin

rortega
28/02/2016, 18:09
Otra curiosidad en el programa QGroundcontrol se reciben los datos de horizonte etc.. pero no lo posiciona en el mapa `por que dice "no gps lock for vehicle #100" , entiendo dice que no esta fix el gps AVION , que de hecho si lo esta pero el MyFlyDream no lo envia "o gps fix, numero satelites" y por eso se queja.

Se envían tramas muy concretas, puede que GQGroundcontrol necesita alguna adicional.

Pruega el oruxmaps a ver si a tí te va bien.

rortega
28/02/2016, 18:10
Perdón quería decir antes no era con Hércules ahora con un programa de Mac

Pues el problema va a ser ese, que me envías un archivo de texto para Mac, y yo estoy en windows ...

Guillesan
28/02/2016, 18:10
Para probar Oruxmaps tendría que cambiar todo el montaje a Gps_telemetry, un lio

rortega
28/02/2016, 18:10
Guillesan, tu que estas al loro de los programas, ¿que hay a parte del Oruxmap? preferiblemente para el Android Movil, y también para Tablet Android.

Como ya comenté, tengo probado el DroidPlaner en la Tablet, y funciona bien con Mavlink, pero si conoces algún otro programa lo probaría.

Lo curioso del caso es que con Mavlink funcione bien, y con GPS_Telemetry no funcione, supongo que las tramas Mavlink son mucho mas fáciles de interpretar.

Has probado ya la última versión que he subido a ver si funciona?

Guillesan
28/02/2016, 18:14
Pues el problema va a ser ese, que me envías un archivo de texto para Mac, y yo estoy en windows ...


Tengo un problemilla con esa captura, lo conecto al pc por bluetooh y el Windows lo tengo virtualizado , los driver a de bluetooh no están instalados, de hecho es difícil hacerlo, por lo que busque hacerlo con un programa para Mac sustituyendo el Hércules, a la vista está que no sirve.

rortega
28/02/2016, 18:42
Otra curiosidad en el programa QGroundcontrol se reciben los datos de horizonte etc.. pero no lo posiciona en el mapa `por que dice "no gps lock for vehicle #100" , entiendo dice que no esta fix el gps AVION , que de hecho si lo esta pero el MyFlyDream no lo envia "o gps fix, numero satelites" y por eso se queja.

Ya está resuelto lo de los satélites. Se debe a que entre los arreglos que hice quité el envío de una trama, que precisamente enviaba el número de satélites. La quité porque se envía una segunda trama que también manda la posición, y me pareció redundante. Pero se ve que si no va esa trama no hay satélites y algún porgrama no entiende que hay fix.

rortega
28/02/2016, 18:42
Subido el apaño como 3.3.1 al respositorio.

rortega
28/02/2016, 18:43
Simba dime que versión de Oruxmaps tienes...

Guillesan
28/02/2016, 18:43
Ok, estoy intentando hacerte una nueva captura

rortega
28/02/2016, 18:44
Por cierto, hace unos cuantos días instalé el QGroundcontrol y me petó el ordenador, tuve que restaurar...

Guillesan
28/02/2016, 18:45
Raul tienes una nueva captura en dropbox "ultimo_crossfire" veamos si te sirve esta.

rortega
28/02/2016, 18:55
Raul tienes una nueva captura en dropbox "ultimo_crossfire" veamos si te sirve esta.

No se lo traga, los antiguos que me enviaste hace ya bastante tiempo si van.

Guillesan
28/02/2016, 19:09
No se lo traga, los antiguos que me enviaste hace ya bastante tiempo si van.

Lo siento pues , vere de hacer la captura en hercules. Por cierto la 3.1.1 esta instalada y funciona pero........siempre hay uno QGroundcontrol no se entera, y es que como ya dije en otros post este MyFlyDream es una cosa un tanto rara por que manda un Mavlink light y precisamente el numero de satelites o el fix no lo envia, por lo que al no tenerlo la antena tampoco los muestra y el mavlink repetidor no puede darlos, APM parece que no le importa pero este Qgroundcontrol si lo espera y no posiciona el avion en mapa, lo demas si lo representa,yaw;roll etc. Tampoco es un grave problema se usa APM y solucionado. Gracias de todos modos como siempre.

rortega
28/02/2016, 19:11
Lo siento pues , vere de hacer la captura en hercules. Por cierto la 3.1.1 esta instalada y funciona pero........siempre hay uno QGroundcontrol no se entera, y es que como ya dije en otros post este MyFlyDream es una cosa un tanto rara por que manda un Mavlink light y precisamente el numero de satelites o el fix no lo envia, por lo que al no tenerlo la antena tampoco los muestra y el mavlink repetidor no puede darlos, APM parece que no le importa pero este Qgroundcontrol si lo espera y no posiciona el avion en mapa, lo demas si lo representa,yaw;roll etc. Tampoco es un grave problema se usa APM y solucionado. Gracias de todos modos como siempre.

Bueno, podemos meter un número de satélites al voleo si me da valor 0.

Guillesan
28/02/2016, 19:14
Bueno, podemos meter un número de satélites al voleo si me da valor 0.

No te lies Raul que no es grave , todo lo demas funciona y muy bien, deja que ya te digo que no es un Mavlink normal, seria en mi opinion mejor el tema de salida transparente mavlink-mavlink o gps-gps , por no cargar al micro y ademas las gallinas que entran por las que salen y que cada programa se espabile, jajajajaja

Simba
28/02/2016, 19:31
No acabo de llegar a casa luego lo pruebo

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
28/02/2016, 19:40
Simba dime que versión de Oruxmaps tienes...
Es la OruxMaps v.6.0.9

Simba
28/02/2016, 20:08
Es la OruxMaps v.6.0.9
Acabo de instalar la ultima, la V.6.5.0

Guillesan
28/02/2016, 20:08
Y..…

carabin
28/02/2016, 20:18
Simba , no pienses que me olvidado del tema de los PIDS , pues llevo casi todo el fin de semana de pruebas , en la de 32 bits ya creo que lo tengo y la de 8 bits esta encaminada , el problema mío es que parto de unos servos que en la zona central les cuesta mucho moverse y encima la relación es de 3/1 de los piñones pues no te digo más.
Esta semana seguiré haciendo pruebas y ya te contaré como queda , para así, si no lo consigo la 2ª semana Marzo estaré por tu zona y nos podríamos ver para despejar dudas .
Ya te infomo yo .:wink:

Simba
28/02/2016, 20:41
OK carabin.

Bueno sigo igual he cargado ultima versión del repositorio y la ultima del Oruxmaps, y sigo exactamente igual.
Empiezo a pensar que no se manejar el OruxMaps.

Guillesan
28/02/2016, 20:43
Simba por resumir, tú tienes softserial a 9600 digo yo. Tienes certeza de que sale algo por ahí? Conecta un ftdi directo y a consola para certificar que salen tramas, no

Simba
28/02/2016, 20:55
Si tengo softserial a 9600 para el Orux y no va y cuando lo pongo a 57600 y utilizo mavlink si que funciona

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
28/02/2016, 20:56
Pero dices no va, has hecho esa prueba de conexión directa a consola por ftdi?

Simba
28/02/2016, 21:01
Solo tengo un ftdi, y lo utilizo con el simulador.
Si lo quito del simulador, no puedo simular las tramas GPS.

Guillesan
28/02/2016, 21:03
Coño lastima. Y si lo inviertes, el bluetooh a la entrada y conectas al pc-simulador y ftdi salida

rortega
28/02/2016, 21:11
Puedes hacer una cosa?

Instala Blueterm, conecta al módulo y graba el log con lo que le llega. Eso luego lo puedo yo analizar y ver si hay algo que falla.

A mí algunas veces me pasa, lo he comentado algunas veces, que hace emparejamiento pero no recibo nada. Lo que hago es que le quito la alimentación al bluetooth y la vuelvo a meter. Y me llega a pasar que incluso el orux, y otros programas, me piden nuevamente emparejar pidiendo el código...

Me pasa con 3 módulos distintos, se lo achaco a Android...

Simba
28/02/2016, 22:15
Puedes hacer una cosa?

Instala Blueterm, conecta al módulo y graba el log con lo que le llega. Eso luego lo puedo yo analizar y ver si hay algo que falla.

A mí algunas veces me pasa, lo he comentado algunas veces, que hace emparejamiento pero no recibo nada. Lo que hago es que le quito la alimentación al bluetooth y la vuelvo a meter. Y me llega a pasar que incluso el orux, y otros programas, me piden nuevamente emparejar pidiendo el código...

Me pasa con 3 módulos distintos, se lo achaco a Android...

Perdonar que no conteste rapido, pero ando de pruebas.

Bueno ya sabemos una cosa importante.
Por el Bluetooht salen las tramas GPS_Telemetry perfectas, o sea que ya tenemos clara la cuestión, TENEMOS TRAMAS.
He instalado en el Movil un terminal de bluetooht (el 3º que he bajado) y BINGO se leen las tramas perfectamente.

La cuestión es que seguramente es el mierrrrdddddaaaaaa del OruxMap que no las interpreta o yo (lo mas probable) no lo sepa configurar.

Lo que me mosquea es que poniendo el Bluetooht en la salida del PC simulador, las tramas directas del simulador si que las interpreta perfectamente. ¿por que estas SI y las que saca la Flip32 NO ? esa es la cuestión.

El bluetooht está a 9600.

rortega
28/02/2016, 22:26
... ¿por que estas SI y las que saca la Flip32 NO ? esa es la cuestión.

Eso mismo es lo que yo quiero saber...

Si hubiese alguan forma en la que me pasaras esas tramas para yo verlas, lo mismo sacaba algo en conclusión.

Con el Blueterm se puede grabar log. El problema es acceder a ese archivo, que se necesita una aplicaicón para gestión de archivos, porque si no no hay forma de acceder a él.

Yo tengo la última versión del oruxmaps instalada, la misma que tú, y la configuración es por defecto... y tú me enseñaste a usarla... No sé si le haces algo al orux, yo no le hago nada, sólo indico que módulo bluetooth usar, y luego iniciar gps.

Una cosa que también hago, es que no le doy a "iniciar gps externo" hasta que no está el tracker en movimiento, para asegurarme que cuando lo active ya estén llegando tramas.

Simba
28/02/2016, 22:29
Las tramas que sales son estas:

$GPGGA,-261076880,3940.15679,N,00-13.-26179,W,1,12,0.0,400.0,M,400.0,M,,*41

$GPRMC,-260977280,A,3940.14720,N,00-13.-26480,W,034.0,192.0,280216,000.0,E*48


No se a que corresponden pero deben de ser cercanas a mi casa.

Simba
28/02/2016, 22:51
Raul creo que lo que sale de la Flip32, no es la posición de mi casa, creo que está bastante lejos.
Estoy comprobando las 2 tramas GPGGA, una de mi casa y la otra la que he sacado de la Flip32 y hay unos signos negativos (-) que no deberían estar.

Son estas:
Mi casa
$GPGGA,214351.00,3940.14450,N,00013.73547,W,2,05,2.94,126.4,M,50.4,M,,0000*4D


Flip32

$GPGGA,-261076880,3940.15679,N,00-13.-26179,W,1,12,0.0,400.0,M,400.0,M,,*41

Simba
28/02/2016, 22:56
La GPGGA de mi casa esta sacada de un GPS puesto en la ventana, con el U.center.

rortega
28/02/2016, 23:03
Raul creo que lo que sale de la Flip32, no es la posición de mi casa, creo que está bastante lejos.
Estoy comprobando las 2 tramas GPGGA, una de mi casa y la otra la que he sacado de la Flip32 y hay unos signos negativos (-) que no deberían estar.

Son estas:
Mi casa
$GPGGA,214351.00,3940.14450,N,00013.73547,W,2,05,2.94,126.4,M,50.4,M,,0000*4D


Flip32

$GPGGA,-261076880,3940.15679,N,00-13.-26179,W,1,12,0.0,400.0,M,400.0,M,,*41

Sí, eso te iba a decir, que hay un error en los decimales. El problema es de lo más tonto del mundo, lo resuelvo en un periquete...

rortega
28/02/2016, 23:04
Sí, eso te iba a decir, que hay un error en los decimales. El problema es de lo más tonto del mundo, lo resuelvo en un periquete...

Eso provoca que las tramas no sean válidas y el orux no muestra posición.

Simba
28/02/2016, 23:05
La cuestión es el porque a ti si que te funciona ¿?¿?¿?

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
28/02/2016, 23:05
Por qué en su posición está en el este

rortega
28/02/2016, 23:06
La cuestión es el porque a ti si que te funciona ¿?¿?¿?

Enviado desde mi GT-I9505 mediante Tapatalk

Porque en mi caso no hay valores negativos, estoy al norte y al este.

Tu al estar al oeste tienes un negativo, y se me ha pasado por alto eliminar el signo en los decimales.

Guillesan
28/02/2016, 23:06
Bingo, los dos estamos de acuerdo hajajaja

fazer5
28/02/2016, 23:06
Habeisvprobado a poner el móvil o la tablet en modo avión para trabajar con oruxmaps?
A mi me soluciono bastantes problemas

Simba
28/02/2016, 23:06
Ok

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
28/02/2016, 23:07
Habeisvprobado a poner el móvil o la tablet en modo avión para trabajar con oruxmaps?

A mi me soluciono bastantes problemas


No es eso Manolo, cosa de decimales.

fazer5
28/02/2016, 23:12
No es eso Manolo, cosa de decimales.

Pero cuando lo pones en modo avión y lo configuras que si pierde conexión y la recupera después se conecte automáticamente. Que puede ser el problema de ortega que dice que tiene que apagarlo y volverlo a conectar el bluethoot. A mi me paso eso y desde que lo configure así funciona perfecto.

rortega
28/02/2016, 23:13
Ya está la correción subida: 3.3.3

Guillesan
28/02/2016, 23:13
Ok pues ya lo verán ellos que son usuarios como tu

fazer5
28/02/2016, 23:13
Por cierto, cuantas antenas tracker tienes ya guille? :laugh:

Guillesan
28/02/2016, 23:13
3 ya van

rortega
28/02/2016, 23:15
Pero cuando lo pones en modo avión y lo configuras que si pierde conexión y la recupera después se conecte automáticamente. Que puede ser el problema de ortega que dice que tiene que apagarlo y volverlo a conectar el bluethoot. A mi me paso eso y desde que lo configure así funciona perfecto.

Lo de Simba son problemas de decimales. Se invalidan las tramas al interpretar mal los datos de posición como cadenas de texto, por llevar un signo negativo en el número decimal.

Mi problema con los bluetooth es problema de android seguro, porque tengo que volver a emparejarlos de vez en cuando (me pide el pin).

Simba
28/02/2016, 23:22
Ya está la correción subida: 3.3.3
Vale pues al lio, otra vez a meter to esto jajaj jaja .

Guillesan
28/02/2016, 23:24
Simba esto es de lujo, tener un súper programador currando a las 23,30 de un domingo y además en castellano jajaja

Simba
28/02/2016, 23:25
+1 esto no tiene presssio :laugh:

rortega
28/02/2016, 23:27
Guille en la actualización también está lo de poner un número de satélites cuando mavlink devuelve 0 satélites...

Guillesan
28/02/2016, 23:28
Vale, mañana la pincho, y puestos podrá haber una transferencia sin más hacia la salida softserial?

rortega
28/02/2016, 23:29
Vale, mañana la pincho, y puestos podrá haber una transferencia sin más hacia la salida softserial?

Si ves que lo de la transferencia no va bien, te paso mi número de cuenta y me la pones a mí :-800:

Guillesan
28/02/2016, 23:30
Jajaja, ya querría, sinceramente

Simba
29/02/2016, 00:16
BINGO BINGO BINGO, YA ESTA, ya funciona sin ningún problema y va de P.M.

Felicidades por el tesón y las ganas.

3 curras por el el Traker360 :biggrin2::biggrin2::ansioso::ansioso:.
No pongo video, por que el Movil esta con el Orux jajaj jiji.

Ale ya podemos dormir tranquilos.

Guillesan
29/02/2016, 00:17
Joder felicidades, ala a disfrutar, como pierdas el avión ahora es pa matarte jajaja

rortega
29/02/2016, 00:17
Por fin ...

Guillesan
29/02/2016, 00:18
Y eso con la versión 333 imaginar cuando llegue la 666

Simba
29/02/2016, 00:27
Bueno chicos yo me retiro, mañana mas.

Buenas noches.

Guillesan
29/02/2016, 00:28
Al buenas noches a todos

Mariete
29/02/2016, 12:10
Bueno, pues ya he recibido los conectores para el MFD AAT. Pronto empezaré con las pruebas.

Me falta resolver el tema de como bajar la telemetría. No se si cambiar el Dragonlink por el nuevo o usar, de momento, un Openlrsng.

Para los Eagle Tree Vector tengo un Eagle Eyes, que decodifica la telemetría, pero me parece que no está documentado como sacarla de ahí para utilizarlo con un arduino.

64173

Simba
29/02/2016, 14:41
Depende de lo que dispongas.
Si tienes el Driver mfd y el mfd ad ya lo tenes todo por Telemetria Video .
Si no es el caso yo sin dudarlo utilizaría Orange LRS, barato bueno y seguro al 100%, y claro todo sea lo que sea con Traker360.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
29/02/2016, 17:47
Hola a todos/as.
Cuando uno tropieza con algo que desconoce, no se puede hacer idea de lo complicado que puede llegar a ser.
Me refiero a la AP OruxMaps.
Es algo para lo que se necesita un Master, esta súper desarrollado y tiene un montón de aplicaciones.
Me he bajado el manual, pero tendré que imprimirlo y ponerme a estudiar, para sacarle un mínimo partido.

A y si, si que sirve para encontrar un avión perdido, incluso te redirige directamente a los navegadores que tengas, en mi caso Google Maps y Sygic, para que te haga una ruta de acceso al punto de perdida, o sea al ultimo punto que se recibió.

Una pasada de aplicación, pero que se necesitaría ya digo un Máster.

Yo sigo con mis tonterías. JAjajaj jaja jiji.

rortega
29/02/2016, 18:00
Posiblemente esta tarde el EZ-GUI para Multiwii/baseflight/cleanflight reciban también la telemetría desde el tracker.

En mi caso me bastaría con esta app para configurar el micro ZMR y a la vez hacer de estación de tierra.

Simba
29/02/2016, 18:32
Tu crees que es mejor que el Orux map.
Es que si me tengo que aprender uno , que sea el definitivo al menos por un tiempo.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
29/02/2016, 19:21
Tu crees que es mejor que el Orux map.
Es que si me tengo que aprender uno , que sea el definitivo al menos por un tiempo.

Enviado desde mi GT-I9505 mediante Tapatalk

Todo depende de para qué lo quieras. Para ver la posición, guardar logs, etc. tec... Oruxmaps es un buen aliado... Pero si además quieres configurar tu dron, programar misiones y envíarselas, etc., pues tienes que usar un programa específico para el tipo de dron: APM (Droidplanner/Tower), Multigui (EZ-GUI), DJI (UGCS)...etc, etc...

Mi idea es llevar una sola aplicación para ambas cosas, es decir, configurar mi dron desde el móvil y haer un seguimiento don la información que devuelve el tracker...

Si sólo necesitas ver la posición y guardar las rutas para luego analizarlas, pues con oruxmaps te sobra, y por lo que veo es muy completo, aunque tampoco estoy muy al tanto de todo lo que hace porque es la primera vez que lo uso.

Por cierto, entiendo que nuestro tracker también es capaz de entenderse con las controladoras DJI con la telemetría Hott, pero aún no tengo muy claro qué controladoras soporta exactamente y si dependerá de si el software de configuración de DJI para cada modelo de controladora tiene esas opciones, o hay que pagar para tenerlas... Es algo que investigaré si algún día vuelvo a España o me traigo my SpideX aquí.

Simba
29/02/2016, 19:41
Bien pues creo que me quedo con Orux, yo lo único que quiero es tener localizado el avión o el micro250 por si no regresa y tengo que ir a buscarlo.
Lo demás de toda la parafernalia de estación base con horizonte artificial y toda la instrumentación, ya lo tengo en el Osd, y a parte de la curiosidad no le veo ninguna utilidad, en la estación base.
Pero para gusto pues colores, cada uno a su gusto.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
29/02/2016, 23:13
Bueno, pues ya tengo telemetría LTM en EZ-GUI, je je ...

De momento posición y altitud, y lo clava, a la primera...

Simba
01/03/2016, 13:53
Bueno vamos a ver, estoy haciendo pruebas de seguimiento con simulador, y con el Orux.
Me parece, aunque esto de asegurar no puedo de momento, pero me parece que se esta colgando el seguimiento, no se cuelga la placa, solo que se queda el Traker quieto y no lee las coordenadas que le llegan.
Repito el Traker esta vivo, solo que se queda en la ultima posición que tenia, cuando dejo de leer posición.

Esto sucede con el GPS emulator v2.2.15, que me permite aumentar de forma real los Hz de simulación a 4hz, para hacerlo real a mi tipo de seguimiento.

Lo he probado 4 veces y cuando está volando unos 10 minutos y algunas veces antes, se queda parado, lo desconecto y vuelvo arrancar el traker, y todo funciona bien, pero al cavo del rato se queda parado y ya no sigue.

Puedo pensar que lo hace por que tiene una saturación en algún sitio, y no es capaz de mantener esa tasa de datos a 4hz.
En fin no lo se, solo lo comento.

Estoy probando ahora con el simulador tradicional, que no sube de 1hz, luego reporto diferencia.

Simba
01/03/2016, 14:24
Otra cosa, la flecha del cursor (lo que indica la posición y sentido de vuelo) gira invertida, la posición es correcta pero el setido de vuelo esta invertido.
Igual tiene algo que ver con lo de la Latitud, que yo estoy en W.

Simba
01/03/2016, 14:34
Lo del cursor no lo tengas en cuenta rortega, que con el otro simulador el de 4hz va bien, ya comento luego.

Simba
01/03/2016, 15:15
Pregunto, ¿puede ser el puerto de salida del Bluetooht que bloquee el seguimiento?.
Lo comento por que lo he tenido 1/2 hora funcionando bien, lo único que no he tenido conectado es el Orux, el Bluetooht si que estaba conectado, pero sin conexión con el Orux.

rortega
01/03/2016, 15:28
Pregunto, ¿puede ser el puerto de salida del Bluetooht que bloquee el seguimiento?.
Lo comento por que lo he tenido 1/2 hora funcionando bien, lo único que no he tenido conectado es el Orux, el Bluetooht si que estaba conectado, pero sin conexión con el Orux.
Así a ojo, las dos tramas GGA Y RMC enviadas a 4hz supone unos 5560 bits por segundo.

A 4800 bauds es posible que se estén perdiendo muchos bits en el camino y no de tiempo a procesarlas.

Has probado a subir el baudrate?

Simba
01/03/2016, 15:34
Te recuerdo que con el Orange utilizamos los 4800 y 4 hz con solo GPGGA y si utilizamos 2 hz podemos meter las 2 tramas.

Si te refieres a subir el baudrate en la salida del bluetooht la tengo como tu a 9600.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
01/03/2016, 15:37
Lo que se te cuelga es el seguimiento, no? Dices que el tracker se queda quieto a 4hz.

Le estás metiendo a 4hz las dos tramas con el simulador nuevo???

Simba
01/03/2016, 15:38
Si claro y esto puede ser la causa ya que la Flip tiene el puerto de entrada a 4800.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
01/03/2016, 15:41
Tendré que limitar o los hz o las tramas.
Ponerlo a 4h 1 trama como lo tenemos ahora o poner 2 hz y las 2 trama.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
01/03/2016, 15:50
Si claro y esto puede ser la causa ya que la Flip tiene el puerto de entrada a 4800.

Enviado desde mi GT-I9505 mediante Tapatalk
A eso me refiero, que estás saturando la uart1. O subes baudios o bajas hercios o quitas tramas...

Haré la prueba también esta tarde.

Una forma fácil de descartar que sea por culpa del procesamiento de telemetría de salida hacia orux, es desactivar softserial y Telemetry y volver a probar el simulador con las dos tramas a 4hz y 4800

rortega
01/03/2016, 15:51
A eso me refiero, que estás saturando la uart1. O subes baudios o bajas hercios o quitas tramas...

Haré la prueba también esta tarde.

Una forma fácil de descartar que sea por culpa del procesamiento de telemetría de salida hacia orux, es desactivar softserial y Telemetry y volver a probar el simulador con las dos tramas a 4hz y 4800
Pero vamos, me salen 5560 bits por segundo ...

Simba
01/03/2016, 15:54
Por cierto acabo de probar el oleg grande, y resulta totalmente recomendable, una verdadera gozada.

rortega
01/03/2016, 16:01
Por cierto acabo de probar el oleg grande, y resulta totalmente recomendable, una verdadera gozada.
Me voy a pedir uno para el nuevo tracker que me voy a montar. Voy a tener uno para desarrollo y el otro para usarlo en el campo.

Por otro lado tengo muchos frentes abiertos:

Programación de los botones para trimar.

Interface Gráfica para Google Chrome.

Añadir al menú del display las opciones de telemetría de salida.

Mejoras para los que usamos FrskyD. Voy a modificar cleanflight para que inyecte tramas LTM dentro de tramas FrskyD que luego decodificará el firm del tracker. La idea es dotar a FrskyD de un sistema de control de errores en los datos, pues carece de ello.

Modificar cleanflight para que envíe telemetría mavlink...

Y una app para el móvil...

Necesito dos vidas ...

Simba
01/03/2016, 16:18
Bueno pues casi 1 hora en marcha y sin ningún problema.
Ademas antes no lo habia comentado, pero en ocasiones con las 2 tramas y 4 hz, le daba algún que otro espasmo u de Tilt o de Pan, como un tembleque rapido y pasajero, ahora lo veo claro que seria a causa de perdida de datos.

Este es el Simulador tal como lo tengo:

Simba
01/03/2016, 20:22
Bueno llevo toda la tarde probando, y funciona todo perfecto Orux incluido.

Raul con lo comentado de las tramas y los 4800 bauds, lo mejor según mis posibilidades y las del Orange, consiste en utilizar tal como estaba haciendo con el Traker 8 bits, solo la trama GPGGA, con ello solo se sacrifica el vector dirección, del puntero indicador de la posición del avión en el Orux.

El traker funciona exactamente igual, bueno igual no, mejor por que refrescamos posición a 4hz, y en vuelo cercano se nota en el Traker.

El puntero del Orux, en este caso se configura como un pequeño circulo como una diana, que parpadea cambiando de color rojo, verde y blanco, con lo cual se ve perfectamente, y no se necesita la flecha para nada.

La búsqueda en caso de perdida con el Orux es bastante fácil, y te redirige en automático al navegador que tengas en el Móvil, llevándote a la posición mas cercana al siniestro, por carretera y caminos.
Otra cosa sera que en la situación de perdida, ese día yo me acuerde de manejarlo. Jajaja jiji.

rortega
01/03/2016, 21:01
Buenas noticias...

rortega
01/03/2016, 21:03
A mí no me ha dado tiempo aún a sentarme delante del ordenador para hacer pruebas.

Pero vamos, con las que has hecho sobra... A ver si lo grabas y lo vemos.

rortega
02/03/2016, 00:02
Bueno pues casi 1 hora en marcha y sin ningún problema.
Ademas antes no lo habia comentado, pero en ocasiones con las 2 tramas y 4 hz, le daba algún que otro espasmo u de Tilt o de Pan, como un tembleque rapido y pasajero, ahora lo veo claro que seria a causa de perdida de datos.

Este es el Simulador tal como lo tengo:

¿Simba puedes poner el link del GPS Emulator? La versión que yo he encontrado es la 1.26 ...

Simba
02/03/2016, 08:43
No lo tengo.
Este programa venia en conjunto del osd Renzinbi, y al borrarlo del PC se quedo este simulador.
No se si es mismo que comentas pero se que hay uno igual y que se diferencia en la representación gráfica del avión, pero menos eso lo demás es igual.

Enviado desde mi GT-I9505 mediante Tapatalk

m€din@
02/03/2016, 09:24
Hola : Anque no posteo mucho estoy por aqui siguiendo el hilo , voy a empezar a montar mi versión de tracker de 32 bits , iré reportando como me va ,

Rortega aqui tienes el GPS Emulator version 2 http://www.happykillmore.com/Software/RemzibiOSD/GPSEmulator.zip

Saludos A.Medina

javiec
04/03/2016, 16:37
Buenas señores, por fin me llegó mi último juguetito, el querido driver del MFD (adjunto imagenes abajo).

No logró entender muy bien como sería el cableado, yo pensé que era del siguiente modo:

En el RCA amarillo le pongo la salida de vídeo de mi rx (para que el driver reciba entrada de vídeo y descodifique la telemetría). Después del pin 5 y pin 4 del conector lateral blanco sería la telemetría que tengo que conectar a la Crius, esto es así o es de otro modo?

Muchas gracias!!

Un saludo,

Sent from my Redmi Note 3 using Tapatalk

Simba
04/03/2016, 16:59
Buenas señores, por fin me llegó mi último juguetito, el querido driver del MFD (adjunto imagenes abajo).

No logró entender muy bien como sería el cableado, yo pensé que era del siguiente modo:

En el RCA amarillo le pongo la salida de vídeo de mi rx (para que el driver reciba entrada de vídeo y descodifique la telemetría). Después del pin 5 y pin 4 del conector lateral blanco sería la telemetría que tengo que conectar a la Crius, esto es así o es de otro modo?

Muchas gracias!!

Un saludo,

Sent from my Redmi Note 3 using Tapatalk

Mucho me temo que no, por lo que entiendo que pones, el RCA es la salida de video, o sea la salida para ver el video.
Leete bien el manual que está en la www de MFD y comentamos.
De todas formas, tienes que pensar que la filosofia es distinta a la que piensas.
En el conjunto ATT MFD, el Vídeo le llega a la parte a arriba que es donde están las antenas y Rx, y luego de pasar a la parte fija, sale por el conector de aviación, y le entra al Driver este decodifica y vuelve a la parte mocil el cogido para posicionar.

Luego por el RCA sale el video para las gafas o monitor.

sl2.

Simba
04/03/2016, 17:05
Otra cosa rortega, estoy teniendo problemas con la Telemetria, el segmento rotativo de la izquierda, va a trompicones, y el Traker no posiciona.
La duda que tengo y quería preguntar, es si es necesario conectar los 2 cables Tx y Rx para que el UART 1, entrada de Telemetria a la Flip32, funcione bien.
Yo hasta ahora tenia conectado en el UART 1 un Bluetooht, con los 4 cables +- Tx y Rx, pero ahora que ya voy en serio con el Traker, le he conectado solo el - y el Rx.

He copiado lo mismo que en la Crius, si no es esto sera otra cosa.

Gracias.

rortega
04/03/2016, 18:31
Otra cosa rortega, estoy teniendo problemas con la Telemetria, el segmento rotativo de la izquierda, va a trompicones, y el Traker no posiciona.
La duda que tengo y quería preguntar, es si es necesario conectar los 2 cables Tx y Rx para que el UART 1, entrada de Telemetria a la Flip32, funcione bien.
Yo hasta ahora tenia conectado en el UART 1 un Bluetooht, con los 4 cables +- Tx y Rx, pero ahora que ya voy en serio con el Traker, le he conectado solo el - y el Rx.

He copiado lo mismo que en la Crius, si no es esto sera otra cosa.

Gracias.
Qué es el segmento rotativo de la izquierda? [emoji15]

Necesitamos el tx sólo si quieres interactuar con el cli.

rortega
04/03/2016, 18:34
He estado un poco liado esta semana y he avanzado poco. Lo poco que he hecho está relacionado con hacer una interfaz gráfica de configuración.

Simba
04/03/2016, 19:40
Qué es el segmento rotativo de la izquierda? [emoji15]

Necesitamos el tx sólo si quieres interactuar con el cli.
Nada Raul ya está solucionado, me refería al indicador de telemetria de entrada, la rallita que da vueltas, y que por cierto su utilidad tiene.

El problema que tenia de falta de telemetria ya está solucionado, solo era que el Modulo Tx Orange, estaba mal configurado, y tenia un serial baudrate de 115200, cuando debería de tener 4800, lo he cambiado y ha rular.

Pues eso ya esta rulando, totalmente terminado y listo para ir a volar, solo falta sacarlo a pasear al campo de vuelo.

Sl2

rortega
04/03/2016, 19:51
Me alegro que esté todo bien.

Este fin de semana le voy a meter mano al tema del trimado del heading, y tengo previsto hacer alguna mejora en el tema del menú en panatalla, para evitar tener que hacer tantas pulsaciones.

rortega
04/03/2016, 19:54
Bueno, pues parece que el amv-360opentracker de 8 bits está llegando bien lejos ...

https://www.youtube.com/watch?v=ZQiPTIwpXk4

rortega
04/03/2016, 20:03
Simba, mi cerebro ya ha empezado a currar en el trimado ... y empiezan las pajas mentales ... que derivan en preguntas que podrían parecer simples, pero que tienen su complejidad...

¿Cuántos grados timar en cada pulsación? De 1 en 1 no lo vamos a notar hasta que no hayamos pulsado unas cuantas veces, debido al tema de los PIDs, que están actuando en todo momento. El sistema va a entender que queremos desplazarnos a un nuevo heading, y no va a moverse así como a así si el nuevo heading está a muy pocos grados de distancia...

Podríamos empezar a probar con saltos de 2 o 4, y dejar un parámetro para ajustar el ancho de cada salto. ¿Qué opinas?

Guillesan
04/03/2016, 22:20
Bueno, pues parece que el amv-360opentracker de 8 bits está llegando bien lejos ...

https://www.youtube.com/watch?v=ZQiPTIwpXk4


Aparatoso es no creéis, de donde es este vídeo?

Simba
04/03/2016, 22:33
Simba, mi cerebro ya ha empezado a currar en el trimado ... y empiezan las pajas mentales ... que derivan en preguntas que podrían parecer simples, pero que tienen su complejidad...

¿Cuántos grados timar en cada pulsación? De 1 en 1 no lo vamos a notar hasta que no hayamos pulsado unas cuantas veces, debido al tema de los PIDs, que están actuando en todo momento. El sistema va a entender que queremos desplazarnos a un nuevo heading, y no va a moverse así como a así si el nuevo heading está a muy pocos grados de distancia...

Podríamos empezar a probar con saltos de 2 o 4, y dejar un parámetro para ajustar el ancho de cada salto. ¿Qué opinas?

Pues vamos a ver, lo que yo ajustaría con los pulsadores, es el valor de la variable Offset, un pulsador para sumar grados de Offset y el otro para restar grados de Offset, y le daría a cada pulsación 1º.

Lo normal es que no tengamos que variar el Offset en +- 10º como mucho, ya que de lo que se trata es de ajustar fino, y a larga distancia.

A 500m poco o nada se va a notar 20º (+10 -10), pero a 5Km seguro que si se notan, dependiendo de lo estrecho que sea el lovulo, de la antena.
en una de 5,8g de esas helicoidales que tenemos, se aprecia y mucho.

No se como se programaría, eso es cosa tuya, pero la idea es solo variar un poco el valor que cada uno tenemos de Offset, según la posición elegida de la Flip 32.

Sobre lo que comentas de los PID, estos seguirán funcionando igual, solo que el set-point, el error 0 lo tendría en el nuevo valor de Offset.

Simba
04/03/2016, 22:40
Aparatoso es no creéis, de donde es este vídeo?
Me suena a chino chino jajaj jaja jijiji.
Eso que es una parabólica de 5,8g, Guillesan, o un radar de seguimiento de misiles.???????

Guillesan
04/03/2016, 22:41
Ya, me suena s eso pero todo muy aparatoso y desarbolado , no sé mucho cable suelto no sé si me explico

javiec
04/03/2016, 23:17
Alguien que tenga en setup de Crius/Flip puede decir cual es el cableado que están usando?

Gracias!

Sent from my Redmi Note 3 using Tapatalk

Guillesan
04/03/2016, 23:18
Alguien que tenga en setup de Crius/Flip puede decir cual es el cableado que están usando?

Gracias!

Sent from my Redmi Note 3 using Tapatalk


No entiendo tu pregunta, perdona

javiec
04/03/2016, 23:24
No entiendo tu pregunta, perdona
Mi pregunta es si alguien que este usando el diver del MFD puede indicar donde mete el vídeo, donde lo saca y donde salen los dos hilos que van a la Crius/Flip.

Gracias Guillesan y perdonar por mi anterior comentario que no era nada explicativo.

Sent from my Redmi Note 3 using Tapatalk

rortega
04/03/2016, 23:26
Volviendo a lo de los botones, tengo alguna que otra cuestión importante:

1.- ¿Se memoriza el trimado, o lo reseteamos a 0 cada vez que se reinicie el tracker? Entiendo que no en todos los vuelos, aún estando en la misma zona, tienen por qué necesitarse el mismo trimado, unas veces hara más y otras menos, dependiendo de hacia donde volemos y que esté influenciando el ambiente ese día (por ejemplo el sol).

2.- ¿Y que pasa cuando el avión ya no está a 5km o más, que esté por ejemplo a 600 metros, sigue el heading desplazado esos grados que trimamos, imaginemos que 10 grados como decía Simba? Haría falta un mecanismo para desactivar/desmemorizar ese desplazamiento del offset ¿No? Por ejemplo que si regresamos y estamos dentro de un radio de acción, el trimado queda anulado automáticamente, o podemos accionar uno de los botones el tiempo suficiente (2 segundos por ejemplo) par anular el trimado...

3.- Sé que hablamos del tema del potenciómetro, pero al final Simba me convenció por el tema de la "sensibilidad a roces", y que es mejor botones, pero no recuerdo ya si hemos llegado a hablar de usar los mismos botones que ya usamos y no poner ninguno adicional. Yo considero que no es necesario añadir botones, pues en el momento que el tracker inicia el seguimiento, esos botones ya no se usan, podríamos asignarlo a esta función de trimado, y volver a recuperar la función normal una vez que el avión lo tenemos en el radio de acción a parir del cual no se inicia seguimiento.

Guillesan
04/03/2016, 23:29
Ahora sí entiendo, http://uploads.tapatalk-cdn.com/20160304/c181965d4418d1a03d832ee246c5580e.jpghttp://uploads.tapatalk-cdn.com/20160304/1d50456dd839787dc22a74bb658f5ee6.jpghttp://uploads.tapatalk-cdn.com/20160304/790d56fdc6c6514e1ed1add9660570c6.jpg
Por el conector izquierdo entra el vídeo , también sale la telemetria hacia la antena. Por el izquierdo sale el vídeo hacia monitor, gafas etc

javiec
04/03/2016, 23:42
Ahora sí entiendo, http://uploads.tapatalk-cdn.com/20160304/c181965d4418d1a03d832ee246c5580e.jpghttp://uploads.tapatalk-cdn.com/20160304/1d50456dd839787dc22a74bb658f5ee6.jpghttp://uploads.tapatalk-cdn.com/20160304/790d56fdc6c6514e1ed1add9660570c6.jpg
Por el conector izquierdo entra el vídeo , también sale la telemetria hacia la antena. Por el izquierdo sale el vídeo hacia monitor, gafas etc
Sabes que pines del conector usa para la entrada del video y cualea para la telemetria?

Sabéis que modelo de conector es para comprar la hermbra?

Sent from my Redmi Note 3 using Tapatalk

Guillesan
04/03/2016, 23:43
Habré la cajita azul y míralo esta serigrafíado. Creo es 6 GND 4 vídeo no me acuerdo de mas

Guillesan
04/03/2016, 23:54
Volviendo a lo de los botones, tengo alguna que otra cuestión importante:

1.- ¿Se memoriza el trimado, o lo reseteamos a 0 cada vez que se reinicie el tracker? Entiendo que no en todos los vuelos, aún estando en la misma zona, tienen por qué necesitarse el mismo trimado, unas veces hara más y otras menos, dependiendo de hacia donde volemos y que esté influenciando el ambiente ese día (por ejemplo el sol).

2.- ¿Y que pasa cuando el avión ya no está a 5km o más, que esté por ejemplo a 600 metros, sigue el heading desplazado esos grados que trimamos, imaginemos que 10 grados como decía Simba? Haría falta un mecanismo para desactivar/desmemorizar ese desplazamiento del offset ¿No? Por ejemplo que si regresamos y estamos dentro de un radio de acción, el trimado queda anulado automáticamente, o podemos accionar uno de los botones el tiempo suficiente (2 segundos por ejemplo) par anular el trimado...

3.- Sé que hablamos del tema del potenciómetro, pero al final Simba me convenció por el tema de la "sensibilidad a roces", y que es mejor botones, pero no recuerdo ya si hemos llegado a hablar de usar los mismos botones que ya usamos y no poner ninguno adicional. Yo considero que no es necesario añadir botones, pues en el momento que el tracker inicia el seguimiento, esos botones ya no se usan, podríamos asignarlo a esta función de trimado, y volver a recuperar la función normal una vez que el avión lo tenemos en el radio de acción a parir del cual no se inicia seguimiento.
Yo preferiria , mas botones, osea otros aparte.
Y pienso que el trimado podria estar vinculado a la distancia hacia el avion, asi saltaria automaticamente prefijando un mas o menos distancia, que os parece.

rortega
04/03/2016, 23:56
Uno que se va al sobre, mañana más ...

Guillesan
04/03/2016, 23:57
Por cierto en breve editare el primer post de este proyecto tal como solicitaban algunos compañeros , pero es que hay tanta informacion que es tedioso. He ido recopilando fotos y videos de todas las pruebas, montajes etc. Queda hacer el collage y subirlo...... en fin estoy en ello.

Guillesan
04/03/2016, 23:58
Uno que se va al sobre, mañana más ...
Buenas noches que descanses.

Simba
05/03/2016, 00:03
Volviendo a lo de los botones, tengo alguna que otra cuestión importante:

1.- ¿Se memoriza el trimado, o lo reseteamos a 0 cada vez que se reinicie el tracker? Entiendo que no en todos los vuelos, aún estando en la misma zona, tienen por qué necesitarse el mismo trimado, unas veces hara más y otras menos, dependiendo de hacia donde volemos y que esté influenciando el ambiente ese día (por ejemplo el sol).

2.- ¿Y que pasa cuando el avión ya no está a 5km o más, que esté por ejemplo a 600 metros, sigue el heading desplazado esos grados que trimamos, imaginemos que 10 grados como decía Simba? Haría falta un mecanismo para desactivar/desmemorizar ese desplazamiento del offset ¿No? Por ejemplo que si regresamos y estamos dentro de un radio de acción, el trimado queda anulado automáticamente, o podemos accionar uno de los botones el tiempo suficiente (2 segundos por ejemplo) par anular el trimado...

3.- Sé que hablamos del tema del potenciómetro, pero al final Simba me convenció por el tema de la "sensibilidad a roces", y que es mejor botones, pero no recuerdo ya si hemos llegado a hablar de usar los mismos botones que ya usamos y no poner ninguno adicional. Yo considero que no es necesario añadir botones, pues en el momento que el tracker inicia el seguimiento, esos botones ya no se usan, podríamos asignarlo a esta función de trimado, y volver a recuperar la función normal una vez que el avión lo tenemos en el radio de acción a parir del cual no se inicia seguimiento.
No te lies con tantas historias, es mas sencillo de lo que crees.

El trimado siempre es el mismo, y es mas una vez ajustado y siempre y cuando no cambiemos, la posición de montaje de las antenas, el trimado no se tocara para nada, ni cuando estas lejos ni cerca.

Imaginate que las antenas, son una linterna con el el foco muy estrecho, y que quieres iluminar algo bastante lejos, a poco que te desbies lo vas a perder de vista.
Esto es lo mismo con las antenas, y el problema es que cuanto mas nos alejamos, menos potencia se tiene (es igual en transmisión que en recepción) y por lo tanto con poca desviación, la perdida de iluminación del blanco se nota mucho mas.

Resumiendo que solo hay que tocar o ajustar una sola vez mientras no cambiemos antenas, y por lo tanto es algo así como si lleváramos el PC al campo de vuelo, y ajustaramaos en CLI el Offset, y una vez ajustado ya no lo tocaremos.

Simba
05/03/2016, 00:19
Otra cosa diferente, y que no digo que no se pueda hacer, pero es algo que se tendrá que pensar mucho mas, es un ajuste de ganancia automático.

Para esto y para el ajuste de Offset, se necesita una cosa mas, me refiero a una medición del RSSI.
Esta RSSI sera necesaria, para ver físicamente si aumentamos o disminuimos señal al ajustar el Offset, ya que si vamos a ojo por solo la impresión de la calidad del vídeo, puede ser muy engañoso.

Bien pues el ajuste automático de ganancia, seria tal que la Flip32 midiera la RSSI y en función de esta medida, reajustaria el Offset en continuo, por ejemplo en un margen de +- 10º, que seria como un ajuste sobre el ajuste de posición, y si se pudiera tanto para Pan como para Tilt.

Bueno todo esto es posible, pero creo que llevaría bastante faena, aunque yo de momento tengo tiempo para hacer todas las pruebas que querais, Ja jaja ja ja.

Simba
05/03/2016, 00:24
¿No habéis ajustado nunca una parabolica de TV Satelite ?

En el programa de ajuste del Rx TV, salen unas barras que indican dos parámetros, una es la calidad de la señal y la otra el nivel, y ajustando los ángulos de la parabólica, se deja en la posición que mas se lee en las 2 barras.
Las barras son el RSSI.

Simba
05/03/2016, 00:30
Ale todo el mundo a la cama.
Buenas noches.

rortega
05/03/2016, 11:18
Os comento lo que voy a hacer con el tema de los botones, y es una simple cuestión de pragmatismo.

Resulta que no es tarea simple hacer uso de los pines que nos quedan libres como pines de entrada. El problema radica en que hay un montón de código fuente que hace muchas cosas durante la secuencia de inicio, que es donde se determina el uso de los pines en base al hardware utilizado y características activadas. Esa parte de código es para hacer un master ... y aunque yo imparto clases en masters, creo que lo más simple y rápido es hacer lo que proponía, usar los botones que ya tenemos ampliando la funcionalidad.

Y para aquellos que prefieren 4 botones en lugar a dos, simplemente bastaría con conectar esos 2 botones adicionales a los mismos pines.

A mí esta solución me supondría mucho menos trabajo por la simplicidad en su implementación, y creo que a vosotros os debería dar igual, tan sólo tener claro que mientras estamos dentro del radio en el que el seguimiento no está iniciado, los botones sirven para navegar en el menú de configuración y resetear el home, y cuando ya hemos sobrepasado ese radio (start_tracking_distance), los botones nos sirven para trimar (entiendo que sólo trimamos cuando el avión está lejos y el tracker casi ni se mueve).

Guillesan
05/03/2016, 11:21
Bueno como te sea más fácil , se prueba y vemos si es practico

Simba
05/03/2016, 13:24
Por mi lo de los botones, me parece bien y si es mas simple y da menos trabajo, pues mejor.

Bueno ya he probado el Traker360 32, todo bien según lo previsto, pero hay que pulir un par de cosas.

La primera cambiar el servo de Pan por el que mejor me ha funcionado en el 8 buts, el comentado Towerpro. El que llevo no es que valla mal, pero me gusta mas aunque no sirva de nada, el seguimiento mas preciso en vuelo cercano, solo es cuestión de manías, por que a efectos de calidad de vídeo no afecta nada de nada.

La segunda el ajuste de amortiguación del Tilt, Raul no se el motivo pero en este 32 bits, el Easing no funciona igual que en el 8 bits, y no he sido capaz de ajustarlo con efectividad, yo para mi que no se nota.
Voy a subir unos videos a pelo sin montar, de lo que hemos grabado del estreno y presentación y veres que el Tilt no amortigua prácticamente nada y se nota.

Por lo demás todo ha funcionado francamente bien.

sl2.

Guillesan
05/03/2016, 13:27
Mira Simba en el campo no lo he probado del todo pero sí que me pareció ese no efecto en el tilt, en mi antena grande eso le afecta más y si digo tenía yo esa presunción. Veremos qué dice Raul

Guillesan
05/03/2016, 13:29
Venga esos videos

Simba
05/03/2016, 13:44
https://youtu.be/w3OSqUGYngY

Simba
05/03/2016, 13:44
https://youtu.be/wApitBB224E

rortega
05/03/2016, 14:26
La verdad es que es impresionante, ese tracker es una auténtica obra de arte.

¿Con qué valores de easing estabas haciendo la prueba del vídeo?

Yo cuando estoy en modo cli para ver que amortigue tengo que poner el easing_steps a 40.

Y el easing_min_angle lo tengo a 1.

No puedo verificar la amortiguación al no tener montada antena alguna, y probando con un destornillador largo puesto con el puño apuntando hacia el avión, como la punta está imantada se vuelve loco el tracker...

Simba
05/03/2016, 14:33
Yo lo he probado en casa con el simulador, y variado muchos valores, pero no conseguí ponerlo a mi gusto.
Lo que llevo en la prueba es esto:
easing = 1
easing_steps = 20
easing_min_angle = 1
easing_milis = 15

Quizas lo interesante seria en vuelo ir cambiando, pero me temo que al entrar en CLI, se perdería la posición de GPS , o en fin no se ¿ puede hacer?

rortega
05/03/2016, 14:40
Yo lo he probado en casa con el simulador, y variado muchos valores, pero no conseguí ponerlo a mi gusto.
Lo que llevo en la prueba es esto:
easing = 1
easing_steps = 20
easing_min_angle = 1
easing_milis = 15

Quizas lo interesante seria en vuelo ir cambiando, pero me temo que al entrar en CLI, se perdería la posición de GPS , o en fin no se ¿ puede hacer?

Si entras en modo cli envuelo al volver a reiniciar, si llevas gps local no debería haber problema.

Estoy probando con un palito de los de comida china, y para notar el efecto lo tengo puesto a

set easing_steps = 40
set easing_angle=1
set easing_milis = 30

En modo cli noto el efcto...

rortega
05/03/2016, 14:43
El problema está en pequeños angulos
Si salto de 0 a 45 o a 90 se nota
pero si salto de 10 a 15, por ejemplo, no hay apenas efecto, hace el movimiento en pocos pasos, 3 o 4, no más, es como si los pasos intermedios no los tuviera en cuenta. Podría ser un problema de redondeo de números, que en alguna operación matemática se esté comiendo los decimales y no dé valores de pwm precisos.

Le echaré un vistazo esta tarde...nieva y hay tiempo sobrado ...

rortega
05/03/2016, 14:46
Esos valores de configuración tan grande que he puesto no los uses, le mete vibraciones tela cuando está simulando...

Simba
05/03/2016, 15:13
Esos valores de configuración tan grande que he puesto no los uses, le mete vibraciones tela cuando está simulando...
Si ya los probé y por eso los dejé como los llevo.

rortega
05/03/2016, 15:15
Estoy haciendo una prueba muy simple, estando en modo cli, he desactivado el easing, y estoy pasando al tilt de una en una unidad.

Por ejemplo:

tilt 43
tilt 44
tilt 45

Y veo que entre el tilt 43 y el tilt 44 el valor de pwm para tilt no varía, pero al meter el tilt 45 ya varía...

Esta prueba se puede hacer con otros valoresy veréis que está ocurriendo...

Es posible que tenga algo que ver en el hecho de que no se aprecien los pasos intermedios cuando el easing está activado, pues muchos pasos provocan moverse en angulos pequeños, y si vamos de 1 en 1 se salta alguno haciendo un salto brusco de 2 grados...por ejemplo..

Simba
05/03/2016, 18:54
Conclusión que no va bien ¿NO?.
Yo tambien estoy haciendo pruebas dentro de casa, y al subir de 20 cuanto mas mas, los golpes son mas secos y la oscilación mucho mayor.
Tal como está, lo mejor es o meter menos de 20 o anular la función, si no empieza con el baile san Bito.

Guillesan
05/03/2016, 19:14
Anular la función easing?

rortega
05/03/2016, 19:15
Conclusión que no va bien ¿NO?.
Yo tambien estoy haciendo pruebas dentro de casa, y al subir de 20 cuanto mas mas, los golpes son mas secos y la oscilación mucho mayor.
Tal como está, lo mejor es o meter menos de 20 o anular la función, si no empieza con el baile san Bito.

No, yo creo que anularlo no, estoy intentando solucionar el problea ...

Guillesan
05/03/2016, 19:19
Ok, esperamos noticias.

rortega
05/03/2016, 23:44
Me está costando muchísimo dar con el problema del esasing, la única forma que tengo de hacer debug es por el mismo puerto por donde le meto la telemetría, y cuando lo tengo el simulador funcionando no puedo acceder al puerto para leerlo. Además ando en precario desde que se me rompió el conector usb de la Flip32, y ando con el ftdi, poniendo bluetooth, quitando bluetooty y pinchando directamente, una ya otra vez, prueba y error...

He extraído el algoritmo que calcula el easing, creando una aplicación para poder ejecutarlo en el pc y no en la flip32, para ver el comportamiento, y no veo fallo.

Podría ser que haya algún problema de conversión de tipos de datos en alguna parte del códito, pero hasta que no me llegue el FTDI que estoy esperando desde hace una semana, no voy a poder leer del puerto a la vez que escribo. He probado incluso con dos bluetooth en Y, pero no hay forma ...

rortega
06/03/2016, 00:00
Estoy buscando el post en el que Simba decía que función de easing es la que mejor le va.

Por defecto en la de 8 bits está activada la EASE_OUT_CIRC.

Pero en la de 32 bits por defecto está la EASE_OUT_QRT.

Simba recuerdas cual de ellas es la que dijiste que te iba mejor?

rortega
06/03/2016, 09:52
Buenas noticias, ya lo he resuelto... era un pequeño bug, lo tenía delante de los ojos y no ha bía forma de encontralo..

No lo he subido aún al repositorio, estoy añadiendo alguna modificación relacioanda con lo que hablamos de los botones y haciendo tests...

Simba
06/03/2016, 10:05
La buena era la circle esa era la que mejor resultado daba en el 8 bits.


Enviado desde mi GT-I9505 mediante Tapatalk

rortega
06/03/2016, 11:36
Bueno, ya están las pruebas realizadas y el firmware subido, como versión 3.4.

El easing ya es ajustable, ya no hay vibraciones y se corresponde el comportamiento con lo que se especifica en los parámetros.

Espero que ahora si os vaya bien.

rortega
06/03/2016, 11:39
Se me ha olvidado comentar que también está implementado lo de los botones.

En la pantalla de telemetría, junto al heading del tracker y del avión, he puesto el parámetro Of: que toma valores desde -20 a 20 en función de las pulsaciones de los botones.

Cada pulsación se almacena en memoria automáticamente, y es recordada aunque se reinicie el tracker.

Recordad, que sólo tienen ese efecto esas pulsaciones si el seguimiento se ha iniciado y hemos rebasado la distancia mínima.

Simba
06/03/2016, 11:53
Cojonudo lo cargo y lo pruebo.
Luego reporto resultado.

Gracias Raúl .

Enviado desde mi GT-I9505 mediante Tapatalk

carabin
06/03/2016, 13:04
Bueno lo del Azimut ya está implementado Rortega sigues siendo un máquina , si veis que con los botones es engorroso el ajuste , pues yo creo que el ajuste se debería hacer en vuelo y a distancia , se puede hacer con potenciometros multivuelta con un zócalo que con un simple agujero en el chasis y con un simple destornillador de relojero se haga la tarea más fácil , pero bueno esperamos al que Simba nos diga que tal va , es sólo un idea .

http://uploads.tapatalk-cdn.com/20160306/4437d2e81f7e65551daaed3ef20ceebd.jpg

http://uploads.tapatalk-cdn.com/20160306/c1d755a7d0955bab1d61f48133d8b0a3.jpg

Enviado desde mi GT-I9301I mediante Tapatalk

rortega
06/03/2016, 13:11
Simba, si aún no le has metido mano y te puedes esperar, estoy metiendo una nueva función easing, se llama outCubic. Ya la tengo implementada pero aún no la he probado. No me gusta de la outCirc el arranque que hace tan brusco al principio...

rortega
06/03/2016, 13:19
http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64312&stc=1&d=1457266773

rortega
06/03/2016, 13:24
Probada, sigue siendo mejor la outCir, así que no hace falta que eseperes...

Simba
06/03/2016, 13:37
Hola a todos, pues bien ya esta probado el Easing y los botones de Offset.

El Easing funciona y funciona bien, ahora es cuestión de ajustar a la maquina, según que pesos y servos, pero creo que va bastante bien. Voy a poner un video de como me funciona.
Yo le he dejado así:
easing = 1
easing_steps = 60
easing_min_angle = 4
easing_milis = 15


El ajuste de Offset con los botones, muy bien Raul funciona de P.M., sencillo y totalmente efectivo, no se necesita nada mas, OK y mis felicitaciones por el exito.

Sl2.

Simba
06/03/2016, 13:56
https://youtu.be/k1-X9jszxzI

rortega
06/03/2016, 13:57
Bueno, son muy buenas noticias, de verdad...

Al final he metido una nueva función easing, outExpo.

No la voy a subir aún, para no dar más trabajo... Es más parecida a la outQuarq, pero arranca más rápido y desde la mitad en adelante suaviza más incluso que la outCirc (sobre el papel), pero no estoy seguro de que se note mucho la diferencia, al menos con la mini antena simulada con un palo de comida china y un peso en el extremo.

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64313&stc=1&d=1457269008

Otra cosa que he hecho es permitir bajar easing_milis de 15, se puede hasta 5. Se podría subir los steps a 100 y de esta forma tener unos pasos más graduales en la parte final.

La voy a dejar implementado, y ya más adelante la subo para que se pruebe junto a otras mejoras que vengan.

rortega
06/03/2016, 14:00
La verdad es que el movimiento en este vídeo se nota mucho mejor que en el de ayer...

¿¿¿Por cierto, la cascada de la foto es la que está cerca de los Llanos del Hospital, camino del Aneto???

Simba
06/03/2016, 14:04
Si efectivamente es el forau del Aigualluts y el Aneto al fondo.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
06/03/2016, 14:32
Raúl cuando lo subas actualiza al menos el feature y el serial, para no tener que meterlo siempre.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
06/03/2016, 15:08
Raúl cuando lo subas actualiza al menos el feature y el serial, para no tener que meterlo siempre.

Enviado desde mi GT-I9505 mediante Tapatalk

Para la próxima estará activas por defecto las features:

easing display gps vbat softserial

La función outCirc y los parámetros que has puesto para easing también estarán por defecto.

Y el serial para oruxmaps también.

Y no te pongo el serial 0 a 4800 porque para mí va a ser un coñazo, si no te lo ponía nada más que por la cantidad de pruebas que haces.

Simba
06/03/2016, 15:20
Raul tenemos un problema, Turruk me comenta y yo tambien he probado que en el Menu Calibración, no funciona bien, solo da 1/2 vuelta y se para.

Y al margen de esto, en la linea del Oled que sale el Off, cambia de posición según el angulo que tengamos por los dígitos las o menos largos (o a 360) y se hace incomodo, pero vamos que se lee bien.

Simba
06/03/2016, 15:23
Ya puesto te pongo mis datos y así ya los tengo. Ja jajaj ji ji.

version 3.4
# feature
Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 9600 115200
serial 31 0 115200 57600 0 115200

# set
Current settings:
gps_baud = 2
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 6
telemetry_inversion = OFF
battery_capacity = 0
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 7000
i = 130
d = 10000
max_pid_error = 1
max_pid_accumulator = 12000
max_pid_gain = 500
pid_divider = 15
pan0 = 1500
pan0_calibrated = 1
min_pan_speed = 0
offset = 270.000
offset_trim = 2
init_servos = 0
tilt0 = 2050
tilt90 = 1110
easing = 1
easing_steps = 60
easing_min_angle = 4
easing_milis = 15
telemetry_baud = 1
telemetry_protocol = 8
start_tracking_distance = 10
mag_declination = 0
min_logic_level = -20465

rortega
06/03/2016, 15:42
Raul tenemos un problema, Turruk me comenta y yo tambien he probado que en el Menu Calibración, no funciona bien, solo da 1/2 vuelta y se para.

Seguramente se debe a una modificación que añadí, para que en caso de perder la telemetría durante dos segundos, se parase el servo pan y no siga girando. Es solucionable, en un rato lo arreglo y lo subo ...


Y al margen de esto, en la linea del Oled que sale el Off, cambia de posición según el angulo que tengamos por los dígitos las o menos largos (o a 360) y se hace incomodo, pero vamos que se lee bien.

Ésto lo anoto, para próximas actualizaciones.

rortega
06/03/2016, 15:46
min_logic_level = -20465

Mira que error, y nadie se ha fijado ...

Simba
06/03/2016, 15:46
Raúl por lo que comentaste del póster conoces Benasque y el forau, yo estuve en Octubre y lo vi con las primeras nieves del año pasado.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
06/03/2016, 15:47
Si yo lo había visto pero como si na, el que no save no ve.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
06/03/2016, 15:48
Raúl por lo que comentaste del póster conoces Benasque y el forau, yo estuve en Octubre y lo vi con las primeras nieves del año pasado.

Enviado desde mi GT-I9505 mediante Tapatalk

He estado en la zona en varias ocasiones, y he hecho dos intentos fallidos de subir al Aneto por incidencias menores en algún acompañante.

He estado sobre todo en verano, pero una de ellas con nieve, nieve hasta la cintura...

Simba
06/03/2016, 15:51
Si si te pilla una buena tormenta en verano te puede nevar bastante a esa altura.
Yo quiero volver este año en verano y subir al refugió de Estos que este año pasado no nos dio tiempo.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
06/03/2016, 16:15
Ya está arreglado y subido, como 3.5.

Simba
06/03/2016, 16:26
Ok me pilla fuera de casa está noche lo pruebo.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
06/03/2016, 20:32
Comentar que esta tarde estuvimos probando el Traker de Turruk con la V 3.4.0.
En vuelo y ajustando el offset, podemos decir que es una herramienta muy muy buena, hay que probarlo para darse cuenta de lo necesaria que es, ya que pequeñas desviaciones de montaje, tanto de la propia placa como de las antenas, ahora se pueden ajustar de forma muy fácil, y apuntar perfectamente a la dirección correcta.

Me pongo ahora mismo a cargar la nueva V 3.5.

Simba
06/03/2016, 22:11
Reporto resultados y apreciaciones de la V 3.5.

El easing responde bien he variado muchos valores pero al final me quedo de momento con estos:

easing = 1
easing_steps = 90
easing_min_angle = 4
easing_milis = 15

Aprecio mejora en la amortiguación.

El calibrate desde el menu todo OK.

El ajuste de Offset una gozada, ya lo probareis y vereis lo util que resulta.

En fin de momento todo OK, pero amenazamos con Buscar errores :rolleyes2:.

sl2.

rortega
06/03/2016, 22:17
Reporto resultados y apreciaciones de la V 3.5.

El easing responde bien he variado muchos valores pero al final me quedo de momento con estos:

easing = 1
easing_steps = 90
easing_min_angle = 4
easing_milis = 15

Aprecio mejora en la amortiguación.

El calibrate desde el menu todo OK.

El ajuste de Offset una gozada, ya lo probareis y vereis lo util que resulta.

En fin de momento todo OK, pero amenazamos con Buscar errores :rolleyes2:.

sl2.
Por qué pones easing a 1. La outCirc es la 2. Y la nueva outExpo es la 3.

Simba
06/03/2016, 22:56
Por qué pones easing a 1. La outCirc es la 2. Y la nueva outExpo es la 3.
Pues por que no lo sabia, se ve que no he leído todo y no me entere de que estaba operativo.

Simba
06/03/2016, 23:02
No encuentro donde lo explicaste.
De todas formas a priori se debería probar con easing=3 según comentas es la mejor ¿no?

rortega
06/03/2016, 23:08
No encuentro donde lo explicaste.
De todas formas a priori se debería probar con easing=3 según comentas es la mejor ¿no?

Bueno, no sé si es la mejor, habría que probar.

Yo pesnsaba que estabas usando la outCirc (2). Pero por lo que comentas se vé que no.

Está explicado aquí: https://github.com/raul-ortega/amv-open360tracker-32bits/wiki/Efecto-EASING-en-servo-Tilt

Simba
07/03/2016, 00:02
Bueno, no sé si es la mejor, habría que probar.

Yo pesnsaba que estabas usando la outCirc (2). Pero por lo que comentas se vé que no.

Está explicado aquí: https://github.com/raul-ortega/amv-open360tracker-32bits/wiki/Efecto-EASING-en-servo-Tilt

Vale, no habia leido la Wiki después de cambiar de versión, por eso no me entere.
De todas formas y despues de probar las 3 versiones de easing, con diferentes valores, me sigue gustando la que mas la 1: Easing OutQuart, no se el motivo pero a mi es la que mejor me va, supongo que por el tipo de servo, y la distribución de pesos y masas.
Yo aparentemente tengo mucho brazo de palanca, pero lo tengo compensado con un muelle, y sin accionar el servo el conjunto está en equilibrio, con lo que lo único que hay que tener en cuenta son las masas.

El 1: Easing OutQuart, no frena el inicio pero esta la masa que ya hace de freno, y tiene la acción de amortiguar al final, que es cuando se necesita, por eso creo que es la que mejor me va.
Creo que esto a cada cual según tenga la maquina le ira mejor uno que otro.
Mi mejor resultado:
easing = 1
easing_steps = 100
easing_min_angle = 3
easing_milis = 15

En resumen que esto ya es rizar el rizo, por que funcionar funciona cojonudamente, y ya estamos en plan mas que finolis exquisitos. Jaja jaja jaja jiji.

Estoy hasta los hueeeeevvvvvoooosssss de tanta prueba, pero si hay que seguir se sigue.

sl2.

rortega
07/03/2016, 00:11
Que va, no lo toques más, no pruebes más. Ahora a disfrutar ese pedazo de invento que te has montado, y si hay algo más que corregir ya lo vamos haciendo.

Yo a partir de ahora voy a ir mejorando en lo posible el tema de configuración con interfaz gráfica, y añadiendo alguna pijada más, que el autor original de la versión de 8 bits me ha pedido una mejora para ésta de 32.

Quiero mejorar también el menú del display, añadiendo alguna cosilla que me habéis pedido (poner en boot mode por ejemplo), reorganizar las opciones para que al cambiar un parámetro se ponga en exit o save y no tener que pulsar mucho para salir, meterle las opciones de telemetría de salida y poco más.

Tengo pendiente verificar y solucionar los problemas con el buzzer. Estoy esperando otro que pedí.

Y lo del RSSI lo estoy estudiando, no termino de ver como encajarlo, obligaría a tener la antena oscilando constantemente para ese autoajuste, y no me termina de convencer...

Guillesan
07/03/2016, 00:16
Joder chicos aún estás por aquí dándole a la antena? Por mi parte hoy he podido volar un ratito, sabiendo que había un problema con él tilt que ya Raúl ha arreglado, pues salvando esto la prueba ha sido satisfactoria, aunque veo en el pan unas oscilaciones o vibraciones que pienso se pueden arreglar con los PIDs y pregunto , se podría implementar el setup por pantalla esos ajustes igual que as puesto el offset?

Simba
07/03/2016, 00:25
Que va, no lo toques más, no pruebes más. Ahora a disfrutar ese pedazo de invento que te has montado, y si hay algo más que corregir ya lo vamos haciendo.

Yo a partir de ahora voy a ir mejorando en lo posible el tema de configuración con interfaz gráfica, y añadiendo alguna pijada más, que el autor original de la versión de 8 bits me ha pedido una mejora para ésta de 32.

Quiero mejorar también el menú del display, añadiendo alguna cosilla que me habéis pedido (poner en boot mode por ejemplo), reorganizar las opciones para que al cambiar un parámetro se ponga en exit o save y no tener que pulsar mucho para salir, meterle las opciones de telemetría de salida y poco más.
Tengo pendiente verificar y solucionar los problemas con el buzzer. Estoy esperando otro que pedí.

Y lo del RSSI lo estoy estudiando, no termino de ver como encajarlo, obligaría a tener la antena oscilando constantemente para ese autoajuste, y no me termina de convencer...

¿Que no lo toque? ¿que no me conoces?, no hombre no si de lo que se trata es de eso, de tocar y tocar, que aunque me queje sarna con gusto no pica,:laugh: esto se ve que lo llevo muuuuu dentro, cada uno es como es.

Una cosa ya que estas por mejorar el display, hay una cosa que se podia mejorar.
Durante las pruebas me di cuenta, que una vez lanzado el simulador y que entra en seguimiento, se pone en marcha la opción ajuste de Offset, hasta aqui todo OK, pero las pantallas no paran de cambiary molesta.

La solución está en antes de empezar a simular, se elija la primera pantalla y así la tienes fija para el ajuste de offset, pero nos sale un problema, que como la pantalla la dejamos fija, pues ya no disponemos de las otras pantallas, sobre todo la de la bateria.

La petición seria poder volver a inicio de mover pantallas, anulando el ajuste de Offset, y poder volver al ajuste de offset.

¿Como? pues se me ocurre por ejemplo, accionando los dos pulsadores a la ver durante 3 segundos, para cambiar de un estado a otro, de control offset a control pantallas.

Solo es una idea.

Simba
07/03/2016, 01:06
Y lo del RSSI lo estoy estudiando, no termino de ver como encajarlo, obligaría a tener la antena oscilando constantemente para ese autoajuste, y no me termina de convencer...

Si tienes razón y yo casi te diría que lo dejes estar, no creo que valga la pena, y ademas se complicara mucho y aparecerán un montón de efectos colaterales de oscilaciones.
Vamos que yo por mi me olvidaría del tema.

rortega
07/03/2016, 01:17
Joder chicos aún estás por aquí dándole a la antena? Por mi parte hoy he podido volar un ratito, sabiendo que había un problema con él tilt que ya Raúl ha arreglado, pues salvando esto la prueba ha sido satisfactoria, aunque veo en el pan unas oscilaciones o vibraciones que pienso se pueden arreglar con los PIDs y pregunto , se podría implementar el setup por pantalla esos ajustes igual que as puesto el offset?
Sí, se podría, claro que sí. Pero no es tan fácil como lo del offset debido a qué está dentro del menú, y se necesita más mareo, pero por supuesto que se puede.

Lo vamos viendo ...

rortega
07/03/2016, 01:20
Simba, me parece perfecto lo de salir del modo trimado con los dos botones, incluso con uno sólo se puede. Eso es cosa simple de implementar.

Guillesan
07/03/2016, 21:38
Lo que no se debe hacer , y cómo romper tontamente un conector usb, que no va a ser todo un camino de rosas.
Veremos cómo salgo de este accidente estupido, por qué como se puede apreciar estaba la antena terminada y ajustada..... Me cagen......


https://vimeo.com/158078135

rortega
07/03/2016, 22:02
Lo que no se debe hacer , y cómo romper tontamente un conector usb, que no va a ser todo un camino de rosas.
Veremos cómo salgo de este accidente estupido, por qué como se puede apreciar estaba la antena terminada y ajustada..... Me cagen......


Te contesto por aquí lo mismo que por el privado, así si a alguien más le pasa, como a tí y a mí, que sepa que hay vida después de la muerte del conector usb.

Yo llevo un par de semanas, desde que se me rompió, usando el FTDI que uso para la crius, conectándolo a la uart1 de la Flip32. Eso sí, haced la ñapa correspondiente con pines y cables para que n haya problemas de polaridad y se pueda quemar algo...

fazer5
07/03/2016, 22:11
Lo que no se debe hacer , y cómo romper tontamente un conector usb, que no va a ser todo un camino de rosas.
Veremos cómo salgo de este accidente estupido, por qué como se puede apreciar estaba la antena terminada y ajustada..... Me cagen......


https://vimeo.com/158078135

Eso lo arreglas tu seguro, un saludo

Guillesan
07/03/2016, 22:13
Te contesto por aquí lo mismo que por el privado, así si a alguien más le pasa, como a tí y a mí, que sepa que hay vida después de la muerte del conector usb.

Yo llevo un par de semanas, desde que se me rompió, usando el FTDI que uso para la crius, conectándolo a la uart1 de la Flip32. Eso sí, haced la ñapa correspondiente con pines y cables para que n haya problemas de polaridad y se pueda quemar algo...

Gracias Raul por la aclaracion, te habia ooido hablar del usb , y tenia la sospecha de que se podia, pero confirmandolo tu me sacas un peso de encima, y es que este mio la placa ha llegado esta misma mañana , vaya que a durado poco y menos, en mi caso por burro, ya se ve en el video.
Vale solucionado pues.

Guillesan
07/03/2016, 22:14
Eso lo arreglas tu seguro, un saludo
Arreglado Manolo haciendolo por puerto serie .

javiec
07/03/2016, 23:13
Buenas, estoy teniendo problemas con el driver del MFD.

He conectado el driver del siguiente modo:

- Del conector circular en el pin de vídeo y gnd (según imagen adjunta) de la salida del rx de video.

- Del conector circular en el pin del cltr al RX de la telemetría de la Crius.

He alimentado el driver del mfd, Crius y todo de la misma fuente de energía para que el gnd sea el mismo.

¿Veis algo que esté mal?

Muchas gracias

Sent from my Redmi Note 3 using Tapatalk

Guillesan
07/03/2016, 23:52
Buenas, estoy teniendo problemas con el driver del MFD.

He conectado el driver del siguiente modo:

- Del conector circular en el pin de vídeo y gnd (según imagen adjunta) de la salida del rx de video.

- Del conector circular en el pin del cltr al RX de la telemetría de la Crius.

He alimentado el driver del mfd, Crius y todo de la misma fuente de energía para que el gnd sea el mismo.

¿Veis algo que esté mal?

Muchas gracias

Sent from my Redmi Note 3 using Tapatalk
En principio creo esta bien, pero pregunta, le mandas telemetria por video y el led del driver parpadea?

javiec
08/03/2016, 00:05
En principio creo esta bien, pero pregunta, le mandas telemetria por video y el led del driver parpadea?
Mañana te cuento, los baudios son 19200 no?



Sent from my Redmi Note 3 using Tapatalk

Guillesan
08/03/2016, 00:06
Yes

Guillesan
08/03/2016, 09:53
Despues del fustre con el conector USB pongo aqui un video de las pruebas de la antena mini.

https://www.youtube.com/watch?v=_ey4nqK6X48

Simba
08/03/2016, 10:06
Guillermo que servo llevas en Pan, por lo que se escucha parece digital.
Y que placa utilizas ????

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
08/03/2016, 10:15
Placa la 32 bits flip, el servo un Turnigy creo te lo miro
El servo pan es este :
https://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=49838

rortega
08/03/2016, 12:47
Que chulada

Guillesan
08/03/2016, 12:48
Que chulada

Vete haciendo boca, ya sabes.
Saludos.

Simba
08/03/2016, 13:20
Placa la 32 bits flip, el servo un Turnigy creo te lo miro
El servo pan es este :
https://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=49838

Porfa pon los PIDs que le tienes puesto, que me gusta como va.
¿Lo has probado metiendo variación de solo 1º o 2º ? para ver si centra bien y tiene par con errores bajos.
Eso es de lo mas importante.
Yo por lo que veo si que es digital, pero no lo pone en las características.

Simba
08/03/2016, 13:31
Esto es de lo que mas me jjjooorroba, ese que pones es una copia exacta del Towerpro que yo tengo, elMG996R que cuando yo compre el 1º de ellos en BG, llevaba la electrónica Digital, (es el que yo llevo en el 8 bits) y funciona de categoría.
Pues bien he comprado 2 Towerpro MG996R, y ya no son Ditales, son Analogicos y bastante malos de mecanica.

Los de Turnigy de HK, se han quedado con el bueno Digital de Towerpro, le ponen su etiqueta, y los Towerpro te meten la gamba de unos servos malos.

En la etiqueta de la foto si se ve que son Digitales.

Guillesan
08/03/2016, 16:19
Simba aqui va el setup de configuracion que tengo en la mini antena

gps_baud = 4
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 5
telemetry_inversion = OFF
battery_capacity = 5000
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 4000
i = 30
d = 300
max_pid_error = 1
max_pid_accumulator = 5000
max_pid_gain = 500
pid_divider = 15
pan0 = 1508
pan0_calibrated = 1
min_pan_speed = 0
offset = 0.000
offset_trim = 0
init_servos = 1
tilt0 = 900
tilt90 = 1700
easing = 1
easing_steps = 80
easing_min_angle = 4
easing_milis = 15
telemetry_baud = 1
telemetry_protocol = 8
start_tracking_distance = 1
mag_declination = 0
min_logic_level = 15

Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

serial 0 1 4800 57600 0 115200
serial 1 2 115200 38400 0 115200
serial 30 1024 115200 57600 9600 115200
serial 30 0 115200 57600 0 115200
serial 31 0 115200 57600 0 115200

Simba
08/03/2016, 16:21
Ok gracias

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
08/03/2016, 16:36
Simba aqui va el setup de configuracion que tengo en la mini antena

gps_baud = 4
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 5
telemetry_inversion = OFF
battery_capacity = 5000
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 4000
i = 30
d = 300
max_pid_error = 1
max_pid_accumulator = 5000
max_pid_gain = 500
pid_divider = 15
pan0 = 1508
pan0_calibrated = 1
min_pan_speed = 0
offset = 0.000
offset_trim = 0
init_servos = 1
tilt0 = 900
tilt90 = 1700
easing = 1
easing_steps = 80
easing_min_angle = 4
easing_milis = 15
telemetry_baud = 1
telemetry_protocol = 8
start_tracking_distance = 1
mag_declination = 0
min_logic_level = 15

Enabled: VBAT SERVO_TILT SOFTSERIAL GPS TELEMETRY DISPLAY EASING

serial 0 1 4800 57600 0 115200
serial 1 2 115200 38400 0 115200
serial 30 1024 115200 57600 9600 115200
serial 30 0 115200 57600 0 115200
serial 31 0 115200 57600 0 115200

Tienes dos líneas serial 30. Una está anulando a la otra...

Guillesan
08/03/2016, 16:39
Pues es cierto el caso es que no me había dado cuenta. Como en esta no uso softserial. Como quito una

rortega
08/03/2016, 17:32
Pues es cierto el caso es que no me había dado cuenta. Como en esta no uso softserial. Como quito una
No es quitarla, sino volver a ejecutarla. La correcta es la de 1024.

Guillesan
08/03/2016, 17:36
No es quitarla, sino volver a ejecutarla. La correcta es la de 1024.
Perdona Raul pero no entiendo , me parece deberian salir cuatro lineas
y me salen cinco
dos veces la serial 30 como quito una, he vuelto a ejecutarla pero me salen las cinco otra vez.

rortega
08/03/2016, 22:12
Perdona Raul pero no entiendo , me parece deberian salir cuatro lineas
y me salen cinco
dos veces la serial 30 como quito una, he vuelto a ejecutarla pero me salen las cinco otra vez.

No he tenido tiempo aún de ponerme con el tema, voy a enchufar el mío en unos minutos a ver si al listar aparecen 4 o 5, no vaya a ser que en la última actualización haya metido un bug en algún sitio.

Guillesan
08/03/2016, 22:12
A vale

Simba
08/03/2016, 22:21
Pues va a ser que tienes razón Guillesan, a mi también me sale esto :
# serial
serial 0 1 4800 57600 0 115200
serial 1 2 115200 9600 0 115200
serial 30 1024 115200 57600 9600 115200
serial 30 0 115200 57600 0 115200
serial 31 0 115200 57600 0 115200

Simba
08/03/2016, 22:22
¿Que efecto puede producir?

Guillesan
08/03/2016, 22:22
No me afectaba en esta pequeña, pero al pasarte el setup Raúl se ha dado cuenta

rortega
08/03/2016, 22:23
Me salen 5 también.
Seguramente está bien y es sólo un bug al mostrar la lista...

Guillesan
08/03/2016, 22:23
Ok

Guillesan
08/03/2016, 22:24
Por cierto como sé que pronto se tendrá que flashear, podrías decirme concretamente cómo debo hacerlo sin el usb operativo, gracias.

Guillesan
08/03/2016, 22:25
Por cierto , Raúl revisa tu mail......

rortega
08/03/2016, 22:45
Se flasea igual, con el FTDI conectado a la uart1...he visto tu mail :)

Ya tengo localizado el problema de donde viene la 5 línea. Se debe a haber puesto por defecto la salida NMEA para oruxmaps, así que ne la próxima actualización aparecerán 4 serials, estando el 30 sin asignar y habrá que hacerlo a mano.

Que por cierto, haciendo estas pruebas acabo de quemar un módulo bluetooth por meterle 5v al pin equivocado...suerte que tengo más... Lo curioso es que al FTDI no le pasa nada, ni se inmuta, está bien protegido...

Guillesan
08/03/2016, 22:46
Así solo falta conectar ftdi- tx,rx,vcc,y GND para conectarlo al programa para flashear

Simba
08/03/2016, 23:03
Guillesan, hablando de servos, supongo que habrás probado, todo tipo de servos que tengas por casa, y algunos mas que seguro has comprado, yo estoy por poner una tienda con los que tengo, pero vamos a lo que voy.

Yo desde que estamos con el 32 bits, he notado una notable diferencia, en el comportamiento de los servos, del Traker 8 al de 32.
Tengo servos, que los tenia como la joya de la corona, en el 8 bits, y que en el 32 bits, no hay forma humana de hacerlos funcionar bien, y que he terminado por retirar, concretamente un Bluebird Digital que tenia de reserva del clclico de un Helicoptero, hera y fue el que mas fino y preciso se comportaba en el 8 Bits y en el 32 es imposible de ajustar.

El misterio es saber cual es el motivo, de esta diferencia tan grande, en el comportamiento.
Se supone que deberían de funcionar igual, ya que los pulsos de mando son los mismos, pero hay algo que altera el comportamiento, y no se lo que es.

El que llevo yo en estos momentos, en el 32 bits, es este:
http://www.banggood.com/Spring-RC-360-Degree-Rotation-Robot-Servo-SM-S4306R-p-919271.html

Ya lo habéis visto funcionar, va bastante bien pero le noto un poco falto de fuerza, en los últimos 2º, antes de alcanzar el 0 error, que al final lo clava pero no con la firmeza del que llevo en el 8 bits.

Esto es algo que lo tenemos muy comentado Turruk y yo, y a el le pasa exactamente igual que a mi.

En fin esto son solo reflexiones que hacemos, con el animo de mejorar en lo posible, y adecuar el mejor servo para el 32 bits.

rortega
08/03/2016, 23:21
Así solo falta conectar ftdi- tx,rx,vcc,y GND para conectarlo al programa para flashear

Ojo que en el conector de la uart1 está en orden inverso.

En cualquier caso:

UART 1 GND ------ GND FTDI
UART 1 5V --------- 5V FTDI
UART 1 RX --------- TX FTDI
UART 1 TX --------- RX FTDI

Y sigues el mismo procedimiento de carga que seguías con el usb.

Guillesan
08/03/2016, 23:27
Guillesan, hablando de servos, supongo que habrás probado, todo tipo de servos que tengas por casa, y algunos mas que seguro has comprado, yo estoy por poner una tienda con los que tengo, pero vamos a lo que voy.

Yo desde que estamos con el 32 bits, he notado una notable diferencia, en el comportamiento de los servos, del Traker 8 al de 32.
Tengo servos, que los tenia como la joya de la corona, en el 8 bits, y que en el 32 bits, no hay forma humana de hacerlos funcionar bien, y que he terminado por retirar, concretamente un Bluebird Digital que tenia de reserva del clclico de un Helicoptero, hera y fue el que mas fino y preciso se comportaba en el 8 Bits y en el 32 es imposible de ajustar.

El misterio es saber cual es el motivo, de esta diferencia tan grande, en el comportamiento.
Se supone que deberían de funcionar igual, ya que los pulsos de mando son los mismos, pero hay algo que altera el comportamiento, y no se lo que es.

El que llevo yo en estos momentos, en el 32 bits, es este:
http://www.banggood.com/Spring-RC-360-Degree-Rotation-Robot-Servo-SM-S4306R-p-919271.html

Ya lo habéis visto funcionar, va bastante bien pero le noto un poco falto de fuerza, en los últimos 2º, antes de alcanzar el 0 error, que al final lo clava pero no con la firmeza del que llevo en el 8 bits.

Esto es algo que lo tenemos muy comentado Turruk y yo, y a el le pasa exactamente igual que a mi.

En fin esto son solo reflexiones que hacemos, con el animo de mejorar en lo posible, y adecuar el mejor servo para el 32 bits.

Este servo spring es el que llevo yo en la antena grande pero el desarrollo de dientes es menor , es decir el engranaje del servo es bastante mas pequeño que en otras antenas y la grande conectada al eje de antena es bastante mas grande.tu habras visto los videos que he subido con esa grandota se porta bien pero se necesitaba fuerza para mover todo el montaje.
voy a grabar unos videos conmparativos de la grande y la pequeña, con movimientos muy cercanos , es decir por ejemplo heading 45,heading 47,heading 52.
Es en eso movimientos cortos donde se ve si estas ajustando bien o no.
Te parece correcto

Guillesan
08/03/2016, 23:29
Ojo que en el conector de la uart1 está en orden inverso.

En cualquier caso:

UART 1 GND ------ GND FTDI
UART 1 5V --------- 5V FTDI
UART 1 RX --------- TX FTDI
UART 1 TX --------- RX FTDI

Y sigues el mismo procedimiento de carga que seguías con el usb.
Vale Raul entendido perfectamente.
Pasos:
conecto hercules por el ftdi
boot mode
cierro hercules (close)
habro flasheador
puerto comX (ftdi)
pa lante

rortega
08/03/2016, 23:31
El misterio es saber cual es el motivo, de esta diferencia tan grande, en el comportamiento.
Se supone que deberían de funcionar igual, ya que los pulsos de mando son los mismos, pero hay algo que altera el comportamiento, y no se lo que es.

Indagué en su día un poco en la documentación de cleanflight a ver si sacaba algo en conclusión, y resulta que no todos los servos funcionan bien a la frecuencia de trabajo de las salidas pwm. Aunque se le envíe un pulso de la misma duración en milisegundos, no se comporta igual en función de la frecuencia a la que esté configurado el reloj que controla los pulsos.

"Output frequency (in Hz) servo pins. Default is 50Hz. When using tricopters or gimbal with digital servo, this rate can be increased. Max of 498Hz (for 500Hz pwm period), and min of 50Hz. Most digital servos will support for example 330Hz.”

El parámetro que sirve para modificar esa frecuencia es:

set servo_pwm_rate=valor

Lo voy a dejar operativo en la próxima actualización para que puedas trastear con él a ver si con esa info que te he puesto y ajustando el valor consigues que te funcione bien.

rortega
08/03/2016, 23:33
Indagué en su día un poco en la documentación de cleanflight a ver si sacaba algo en conclusión, y resulta que no todos los servos funcionan bien a la frecuencia de trabajo de las salidas pwm. Aunque se le envíe un pulso de la misma duración en milisegundos, no se comporta igual en función de la frecuencia a la que esté configurado el reloj que controla los pulsos.

"Output frequency (in Hz) servo pins. Default is 50Hz. When using tricopters or gimbal with digital servo, this rate can be increased. Max of 498Hz (for 500Hz pwm period), and min of 50Hz. Most digital servos will support for example 330Hz.”

El parámetro que sirve para modificar esa frecuencia es:

set servo_pwm_rate=valor

Lo voy a dejar operativo en la próxima actualización para que puedas trastear con él a ver si con esa info que te he puesto y ajustando el valor consigues que te funcione bien.

La idea sería por tanto probar con 330 HZ una vez que suba la nueva versión...

rortega
08/03/2016, 23:34
La idea sería por tanto probar con 330 HZ una vez que suba la nueva versión...

Y confirmo que por defecto la tenemos a 50.

Guillesan
08/03/2016, 23:40
La idea sería por tanto probar con 330 HZ una vez que suba la nueva versión...

Y digo yo, por enmerdar, no seria interesante pensar en pasarse a motores paso a paso ?
Ya lo he dicho en otra ocasion y no se si es mucho lio, ni idea, pero pienso que de hacerse daria una exactitud muy mejorada no.

Simba
08/03/2016, 23:54
Pues me parece que estas poniendo el punto sobre la I.
Esa puede ser la razón y me acabas de dar una pista sobre el problema.
¿Habría alguna forma de saber que diferencia tenemos entre el 8 y 32 bits???


Enviado desde mi GT-I9505 mediante Tapatalk

Simba
08/03/2016, 23:58
Este servo spring es el que llevo yo en la antena grande pero el desarrollo de dientes es menor , es decir el engranaje del servo es bastante mas pequeño que en otras antenas y la grande conectada al eje de antena es bastante mas grande.tu habras visto los videos que he subido con esa grandota se porta bien pero se necesitaba fuerza para mover todo el montaje.
voy a grabar unos videos conmparativos de la grande y la pequeña, con movimientos muy cercanos , es decir por ejemplo heading 45,heading 47,heading 52.
Es en eso movimientos cortos donde se ve si estas ajustando bien o no.
Te parece correcto
Si eso es lo que quiero conseguir, es en esos 2° últimos donde se nota, si tiene fuerza para llegar al 0 error.

Enviado desde mi GT-I9505 mediante Tapatalk

TURRUK
08/03/2016, 23:59
Y digo yo, por enmerdar, no seria interesante pensar en pasarse a motores paso a paso ?
Ya lo he dicho en otra ocasion y no se si es mucho lio, ni idea, pero pienso que de hacerse daria una exactitud muy mejorada no.

Hola, hace tiempo yo decía a Simba que si se podria usar motores paso a paso, pero hay una cosa que motor paso a paso siempre esta en marcha para mantener esos pasos , esta claro que puede ser que mas preciso, pero eso puede producir el campo magnético y afectar a la brújula digital. Hace par de días dando por la web encontro un proecto bastante interesante que funciona con motores de coriente continua y con una reductora incorporada con un codificador, y un tipo de variador. Pero claro falta escribir programa para esto... Son esto: http://www.amazon.co.uk/29-Gearmotor-37Dx52L-Encoder-365rpm/dp/B008K7GAJK/ref=sr_1_fkmr2_1?ie=UTF8&qid=1361815717&sr=8-1-fkmr2

rortega
09/03/2016, 00:00
Bueno, voy a subir la nueva versión en unos minutos, pero sin haberlo probado del todo. Así que antes de flashear guardar el hex anterior por si tenéis que volver a dejarlo como estaba.

Os cuento lo que lleva la versión 3.6:



Cuando estamos en modo trimado del offset, podemos hacer que los botones vuelva a tener el comportamiento habitual. Para ello, pulsamos únicamente el botón home durante un par de segundos o mas, y al soltarlo le botón menú y el botón home ya actuan como hacían antes.



Pero el valor de trimado de offset sigue teniendo efecto, no se queda desactivado, y no podemos volver a trimar a no ser que aterrizemos y nos metamos dentro del radio de distancia que hay entre el tracker y la distancia mínima a partir de la cual se inicia el seguimiento.



Sí aterrizamos el aeromodelo y lo metemos dentro de ese radio, el segimiento deja de realizarse, hay que salir fuera del radio para que empieze nuevamente (esto antes no pasaba).



Mejora en la página de telemetría del display. Para que H: A: y Of: no estén bailando todo el rato, se rellenan los dígitos con ceros por la izquierda. Esta mejora se la he añadido a algún dato en alguna otra página, por ejemplo en el modo Cli, a los milisegundos de pan y tilt.



Se ha eliminado la asignación por defecto la telemetría de salida NMEA para Oruxmaps al softserial 30. Es necesario introducir a mano en modo cli la linea serial correspondiente como hacíamos antes.



Se ha habilitado en modo cli el parámetro set servo_pwm_rate=valor para el ajuste con servos digitales.

En estos momentos estoy subiendo el archivo al repositorio, cuando acabéis de leer en el respositorio aparecerá el hex como versión 3.6.

Guillesan
09/03/2016, 00:09
Pues venga mañana le metemos mano.

rortega
09/03/2016, 00:10
Seguramente voy a decir una barbaridad, pero y usar motores Brushless. Es bien sabido la eficacia y precisión usados en los gimbals de los multicópteros... Lo que no tengo claro si tienen fuerza suficiente como para mover una antena pesada.

TURRUK
09/03/2016, 00:17
Seguramente voy a decir una barbaridad, pero y usar motores Brushless. Es bien sabido la eficacia y precisión usados en los gimbals de los multicópteros... Lo que no tengo claro si tienen fuerza suficiente como para mover una antena pesada.

Y servos con motores brujles?:rolleyes:
Esto proecto que yo decía: http://zoomworks.org/fpv/antenna_tracker/bill_of_materials.html

Guillesan
09/03/2016, 00:19
Pues habra que probar, si señor

Guillesan
09/03/2016, 00:25
Simba este lo has probado ?
http://www.hobbyking.com/hobbyking/store/__40923__D50024MG_360_degree_Continuous_Travel_Digital_N_Roll_Gimbal_Servo_5_0kg_0_05s_60g.html

rortega
09/03/2016, 00:26
Simba este lo has probado ?
http://www.hobbyking.com/hobbyking/store/__40923__D50024MG_360_degree_Continuous_Travel_Digital_N_Roll_Gimbal_Servo_5_0kg_0_05s_60g.html

Caro ...

Simba
09/03/2016, 00:27
OK, ya está bajada, pero no me voy a liar que se me haran las tantas, mañana lo pruebo.

Guillesan
09/03/2016, 00:27
Caro ...

Cierto pero rapido lo es el jodido.

rortega
09/03/2016, 00:28
Y servos con motores brujles?:rolleyes:
Esto proecto que yo decía: http://zoomworks.org/fpv/antenna_tracker/bill_of_materials.html

Pedazo de lista de la compra ...

TURRUK
09/03/2016, 00:34
Pedazo de lista de la compra ...

Ya, pero o lo mejor no se falta doto solo motor y controlador de motor y nada, luego adaptar el programa , ahi como tu dices la magia.

Simba
09/03/2016, 00:36
Simba este lo has probado ?
http://www.hobbyking.com/hobbyking/store/__40923__D50024MG_360_degree_Continuous_Travel_Digital_N_Roll_Gimbal_Servo_5_0kg_0_05s_60g.html

Ese es muy parecido al Bluebird que comentaba, y lleva también el motor coreles, es prácticamente las mismas características de velocidad, solo que el mio es de 9 Kg.

Lo que yo mas he notado, es que los servos muy rapidos como por ejemplo estos dos que comentamos, van bastante peor en el 32 bits, independientemente de que sean digitales o analógicos, y los que mejor de pueden ajustar son los mas lentos.
Estos digitales están sobre los 0.05sg/60º, y los que van bien están sobre los 0,2 sg/60º.

Guillesan
09/03/2016, 00:38
Ese es muy parecido al Bluebird que comentaba, y lleva también el motor coreles, es prácticamente las mismas características de velocidad, solo que el mio es de 9 Kg.

Lo que yo mas he notado, es que los servos muy rapidos como por ejemplo estos dos que comentamos, van bastante peor en el 32 bits, independientemente de que sean digitales o analógicos, y los que mejor de pueden ajustar son los mas lentos.
Estos digitales están sobre los 0.05sg/60º, y los que van bien están sobre los 0,2 sg/60º.

Vale igual con el nuevo parametro que ha introducido Raul se puede ajustar. Tu lo tienes y podras juzgar.

rortega
09/03/2016, 00:40
Lo que yo mas he notado, es que los servos muy rapidos como por ejemplo estos dos que comentamos, van bastante peor en el 32 bits, independientemente de que sean digitales o analógicos, y los que mejor de pueden ajustar son los mas lentos.

Prueba el parámetro servo_pwm_rate a ver que pasa ...

He estado probando la 3.6 y parece que está ok, me falta probar lo de quedarse dentro del radio para que no haga tracking, pero eso ya lo probaré mañana, toca dormir.

Buenas noches...

Guillesan
09/03/2016, 00:41
Prueba el parámetro servo_pwm_rate a ver que pasa ...

He estado probando la 3.6 y parece que está ok, me falta probar lo de quedarse dentro del radio para que no haga tracking, pero eso ya lo probaré mañana, toca dormir.

Buenas noches...
Venga buenas noches a todos

Simba
09/03/2016, 00:42
Vale igual con el nuevo parametro que ha introducido Raul se puede ajustar. Tu lo tienes y podras juzgar.
Si pero la putada es que Raul comenta que por defecto lo tenemos a 50Hz, otra cosa es que no sea exactamente así, pero de antemano se que si lo tenemos a 50Hz, los servos que tenemos, la grandisima mayoría son de 50Hz.

En fin ya veremos.

Simba
09/03/2016, 00:42
Ok, buenas noches.

Simba
09/03/2016, 13:51
Bueno pues ya esta probada la V3.6.0.

Respecto al nuevo parametro: servo_pwm_rate = 50, no veo que tenga ningun efecto que haga funcionar mas fino al servo pan, todo lo contrario, ya que al subir por encima de 200, el servo se bloquea y a valores de +- 70 no aprecio diferencia alguna.
Lo que saco en conclusión es que a 50, es como debe de ir, ya que según he estado revisando, a 50 Hz, corresponden los 20ms que corresponden a una señal standar de PWM, concretamente es la duración que tiene, la trama de toda la señal, que se manda para todos los canales, y por lo tanto si aumentamos los hz, disminuimos lo ms de la trama y nos quedamos con menos espacio para los canales, llegando a dejar la trama tan corta, que ya no cave ni un solo canal, y se bloquea el servo.

Lo que si he visto a base de tanto prueba y eeror, y me sorprende mucho, es que el parametro: pid_divider = 15 tiene una influencia brutal, y con tan solo subirlo a 16, me ha permitido subir muchisimo la PIDs, el accumulador lo he subido solo a 6000 y parece que el conjunto se comporta mejor.

estos son los valores que he dejado para el servo de marras, el rapido Bluebird con motor coreles, y con este setup, se comporta bastante bien.

Current settings:
servo_pwm_rate = 50
gps_baud = 2
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 6
telemetry_inversion = OFF
battery_capacity = 0
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 4500
i = 60
d = 500
max_pid_error = 1
max_pid_accumulator = 6000
max_pid_gain = 500
pid_divider = 16 (MUY IMPORTANTE)
pan0 = 1505
pan0_calibrated = 1
min_pan_speed = 0
offset = 270.000
offset_trim = 0
init_servos = 0
tilt0 = 2050
tilt90 = 1110
easing = 1
easing_steps = 100
easing_min_angle = 3
easing_milis = 15
telemetry_baud = 1
telemetry_protocol = 8
start_tracking_distance = 10
mag_declination = 0
min_logic_level = 15

Esta tarde si hace bueno lo probamos, que por cierto tenemos una visita importante.

sl2

rortega
09/03/2016, 18:28
Joder Simba, no paras, desde luego que con esto podríamos hacer una tesis doctoral ...

Yo estoy con esta cosa ... Cualquier día os digo que migramos a Raspberry ...

Si llego con fuerzas y lucidez a casa, avanzaré en las mejoras del menú que hemos ido comentando estos días ...

rortega
09/03/2016, 18:28
La cosa es esta ...

http://images.tapatalk-cdn.com/16/03/09/0cb310288fbe35a1b7d079935a0494b0.jpg

rortega
09/03/2016, 18:30
Simna me has dejado intrigado con lo de la visita ...

Simba
09/03/2016, 19:09
Simna me has dejado intrigado con lo de la visita ...
Pues nada que hemos pasado la tarde, con nuestro amigo Carabin, y nos hemos enseñado nuestras cosas, (trastos y demás cachivaches OK).

Lo malo es que ha hecho una tarde de perros, pero bueno hemos charrado y ajustado sus Traker.

Simba
09/03/2016, 19:25
Raul, no se si seria posible, implementar en el versión 32, el sistema sustituto del control por PIDs, que preparaste para el 8 bits.

De ser posible y no te da mucha faena, lo considero muy interesante, ya que no veo la forma de hacer funcionar, al menos igual que funciona la versión 8 bits.
Sigo opinando que independientemente, de los servos que utilicemos, el Traker 8 bits al menos a Turuk a mi y nos funciona mucho mas fino, el seguimiento es mas continuo y el desfase entre el avión y el Traker sobre todo en vuelo cercano, es mucho menor.

También de forma independiente al sistema de control por PIDs o con la formula rortega que diseñaste, funciona mucho mejor, ya comentamos que el resultado era igual de bueno.

Turruk que es el que mas ha volado con el sistema sin PIDs, no para de decirme que te lo diga a ver si es posible hacerlo igual en el 32 bits.

Sl2.

rortega
09/03/2016, 19:47
Sí, es perfectamente viable, lo haremos.

Simba
09/03/2016, 19:55
Pues no sabes lo que me alegro, igual parece que es dar un paso atrás, pero si responde como en el 8 bits, seria la solución perfecta.

rortega
09/03/2016, 22:28
Pues no sabes lo que me alegro, igual parece que es dar un paso atrás, pero si responde como en el 8 bits, seria la solución perfecta.

Ya está implementado, ha sido fácil pues ha sido insertar el código que ya tenía y agregar los parámetros al cli, más alguna limpieza.

Ahora voy a hace pruebas a ver si funciona ...

Simba
09/03/2016, 22:30
OK quedo a la espera de resultados.

javiec
09/03/2016, 22:54
La cosa es esta ...

http://images.tapatalk-cdn.com/16/03/09/0cb310288fbe35a1b7d079935a0494b0.jpg
Que es este invento??? Que buena pinta!

Sent from my Redmi Note 3 using Tapatalk

rortega
09/03/2016, 23:17
Un cluster que estoy montando ...

Volviendo al tema, me está pasando algo extraño, mi tracker oscila, se vuelve majara en modo cli ...

He vuelto a subir la última versión antes de los cambios y no se vuelve loco del todo, pero está oscilando suavemente de un lado a otro todo el tiempo...

Algo tengo en el ambiente hoy raro ...

rortega
09/03/2016, 23:19
¿Simba, habéis notado algo raro en la 3.6 como lo que estoy comentando? Ayer cuando la probé no me pasaba nada de ésto que comento ...

Simba
09/03/2016, 23:21
Pues no de ese modo no.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
09/03/2016, 23:25
Hoy hay algo raro en el ambiente aquí, el compás del móvil también me oscila...

Mañana sigo, estoy que me caigo de sueño ... buenas noches a todos...

Simba
09/03/2016, 23:27
Ok Buenas noches

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
10/03/2016, 18:46
Saludos a todos los anteneros, sigo yo tambien haciendo practicas.
Si no es que lo hago mal pienso que he encontrado un bug.
Sigo con la version 3.5.0 , he intentado cambiar el protocolo desde la misma antena con los pulsadores, el caso es que llegado al "protocolo" para cambiarlo no me hace caso , intento entrar y pulsando calib. como en todos los demas no entra, lo he probado pelsando los dos a la vez y nada, lo estoy haciendo mal o no funciona.....
Ya me direis.

Me respondo yo mismo, he aprovechado el momeno y el flasheado a la 3.6.0
Ya funciona el cambio de protocolo , no digo que antes no funcionara pero ahora si lo hace.

MisterW
10/03/2016, 20:05
La cosa es esta ...

http://images.tapatalk-cdn.com/16/03/09/0cb310288fbe35a1b7d079935a0494b0.jpg

Eso que es lo que es? :laugh:

Por cierto lo de abajo a la derecha , es tambien una raspberry??? (caja metalica perforada) ¿es una caja que vendan en algun sitio?

rortega
10/03/2016, 20:58
... y pulsando calib. como en todos los demas no entra...

Entra pulsando HOME, calib sólo nos cambia de una opción a otra del menú.
Me alegro que ya lo hayas resuelto.

Guillesan
10/03/2016, 20:59
Solucionado Raúl, otro tema es el "offset" , voy a releer sobre esto que se pusiste un método de ajuste pero no sé bien cómo funciona

rortega
10/03/2016, 21:19
Por cierto lo de abajo a la derecha , es tambien una raspberry??? (caja metalica perforada) ¿es una caja que vendan en algun sitio?

Afirmativo, es lo que vés y sí, la venden, y muy cara:

https://www.adafruit.com/products/2198

Simba
10/03/2016, 21:22
Raúl como vas con los fantasmas magnéticos? ???.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
10/03/2016, 21:24
Solucionado Raúl, otro tema es el "offset" , voy a releer sobre esto que se pusiste un método de ajuste pero no sé bien cómo funciona

No busques, aquí está explicado (justo debajo del vídeo):

https://github.com/raul-ortega/amv-open360tracker-32bits/wiki/Botones:-MEN%C3%9A

https://github.com/raul-ortega/amv-open360tracker-32bits/wiki/Botones:-HOME

Uno es el uso del botón MENU (anteriormente llamado calibración) y el otro el botón HOME.

Empieza por el de MENU, y luego te vas al link del botón HOME y también está en la parte final (verás que ambas explicaciones se complementan una a la otras).

Y si te lees ambas páginas enteras mejor :wink2:

Sólo te falta una cosa que aún no he puesto ahí, y es que una vez que ya has dejado el offset trimado, con una pulsación larga del botón home los botones vuelven a tener su uso normal, es decir, ya puedes fijar páginas y resetear la posición home si lo necesitas.

rortega
10/03/2016, 21:26
Raúl como vas con los fantasmas magnéticos? ???.

Enviado desde mi GT-I9505 mediante Tapatalk

Aún no he tenido tiempo de ponerme a ello, espero en una media hora volver a meterle mano. Es que salgo loco del curro, y me quedo literalmente dormido en el sofá, y enseguida empieza uno con la cena (aquí se cena a las 7 más o menos pues se almuerza entre la 11:00 y las 13:00 horas)...y en unos minutos estoy ya en modo parienta.

rortega
10/03/2016, 23:37
Bueno, pues ya está subida la versión 4.0 con el sistema de control sin pids:

Para activarlo:feature nopid
Para desactivarlo:feature -nopid

Los parámetros de configuración por defecto son:set nopid_min_delta = 0.200
set nopid_map_angle = 90
set nopid_max_speed = 200
Lo mismo en el último paráemtro 200 es demasiado, el servo pega un buen tiron, habría que ajustarlo a la baja.

Espero "buenas" noticias ...

Guillesan
10/03/2016, 23:38
Joder Raúl eres la leche tío. Venga flasheando. Saludos

rortega
10/03/2016, 23:51
En el foro alemán ya hay quien está empezando a probar la versión de 32 bits. Es complicado llear un seguimiento por tema del idioma, pero como estoy suscrito al hilo me llegan a diario las notificaciones, y como son pocas, paso el mensaje por el traductor y más o menos me voy enterando. Ya he tenido algún mensaje por privado con algún usuario para dar instrucciones ...

Simba
11/03/2016, 00:10
Gracias Raul, hoy ya se me hace tardo, mañana en cuanto pueda cargo y pruebo.
Buenas noches.

rortega
11/03/2016, 00:56
Para referscar la memoria, dejo por aquí el link a la explicación de la función que tiene cada parámetro:

https://github.com/raul-ortega/amv-open360tracker-32bits/wiki/Configuraic%C3%B3n:-Sistema-de-control-NOPID

Esta explicación también les viene bien a los que usen la de 8 bits...

Simba
11/03/2016, 01:04
Gracias Raul, hoy ya se me hace tardo, mañana en cuanto pueda cargo y pruebo.
Buenas noches.
Nada, que no he podido resistir y me he puesto, ya está probada Raul , y así de entrada creo que es un éxito Jejeje, va francamente muchísimo mejor.

Me falta pulir los comandos que actualmente ya no me acuerdo lo que hace cada uno, pero siguiendo lo que has puesto, le he tenido que bajar el set nopid_max_speed = 70.
Con los 200 iniciales lo he tenido que desconectar, por lo brusco de las grandes oscilaciones, pero habrá que ajustar algo mas.

Tiene una viveza y velocidad sorprendentes, que con este servo son realmente grandes, y con el sistema PIDs era del todo imposible de ajustar, por que si quería velocidad oscilaba y si le quitaba la oscilación, iba lento y no seguía bien.

Mañana primero me leo lo que es cada cosa, y luego ajusto, pero esto promete y mucho.
Ya te dije que el método era la caña, y que deberías patentarlo, y no es broma.

Ale ahora si que me voy al catre.

Buenas noches si aun estáis presentes.

rortega
11/03/2016, 01:06
La verdad es que me siento abrumado...yo también me meto en la cama en 200 max_speed, je je...

rortega
11/03/2016, 08:41
He escrito una entrada en el subforo de "Escaparate del desarrollador". Me hacía ilusión, pues creo que es el primer producto software presentado en ese subforo:

http://www.aeromodelismovirtual.com/showthread.php?p=494536

Simba
11/03/2016, 09:08
Raul hoy seguiré con los ajustes, pero ayer me enrede con el tema y no puse, que parece que el trimado de offset, no funcione bien.
El pulsador de Cal, me mete -Xº de 1 en 1, pero el pulsador de Home, no mete +Xº, y aunque la pulsación sea muy corta (menos de 1/2"), en algunas ocasiones se sale del trimado, y otras se queda como rallado, y se pone a dar vueltas sin parar.

rortega
11/03/2016, 12:21
Lo miraré esta tarde a ver que pasa.

Simba
11/03/2016, 13:21
Lo miraré esta tarde a ver que pasa.
Bueno parece que hay mas problemas con los botones.
El querer entrar en calibración, se bloquea y sale en el oled letras raras, que parecen chinas.
Vamos que o no se puede entrar en menú o se bloquea.

rortega
11/03/2016, 14:11
Qué raro, hice algunas pruebas como cambiar de protocolo y baudios, aunque no probé intensamente todas las opciones de menú... Con la 3.6 tenías estos problemas? No he modificado nada al respecto en el código del menú, por eso digo que me resulta extraño.

Guillesan
11/03/2016, 15:59
Tambien yo he visto inconsistencia, tanto es asi que he vuelto a la 3.5.0 , por tenerlo todo preparado para el vuelo de mañana.Ya ajustarmos.

Simba
11/03/2016, 17:06
Qué raro, hice algunas pruebas como cambiar de protocolo y baudios, aunque no probé intensamente todas las opciones de menú... Con la 3.6 tenías estos problemas? No he modificado nada al respecto en el código del menú, por eso digo que me resulta extraño.
Hola, pues con tanta prueba no recuerdo, pero si que note algo raro, incluso pensé si no seria que el botón de home, no haria buencontacto o estaria desoldado, fue estando con Carabin que incluso lleguen a destapar el traker para mirar, pero como hacia una tarde de perros, y tenia otros problemas ya no preste mucha mas atención.

Otra cosa que noto muy de tarde en tarde, es que el Tilt pega un arreón arriba y abajo y sigue funcionando bien, ya digo muy de tarde en tarde sin determinar, pero es algo que mosquea un poco.

Simba
11/03/2016, 17:07
Tambien yo he visto inconsistencia, tanto es asi que he vuelto a la 3.5.0 , por tenerlo todo preparado para el vuelo de mañana.Ya ajustarmos.
Guillesan lo define bien, con lo de inconsistencia.

Guillesan
11/03/2016, 17:08
Sí señor todos esos efectos los he visto también yo.

Guillesan
11/03/2016, 17:58
Fundamentalmente veo un mala funcion en los botones, version 3.5.0 .
El boton calib me deja entrar en menu y pulso por ejemplo hasta calibracion, pero cuando pulso home para activar no me responde, evidentemente he revisado conexiones y el caso es que alguna vez si lo hace, de ahi diga inconsistencia.

rortega
11/03/2016, 17:59
Necesito saber si os pasa en la 3.6 o sólo en la 4.0? Lo digo porque tengo que revisar el histórico de cambios y descartar que lo de ayer tenga algo que ver, así me centro en los cambios de la 3.5 a la 3.6 directamente.

Guillesan
11/03/2016, 18:00
Yo estoy ahora en la 3.5.
Y encuentro el fallo.
Carge la 4.0 y he encontrado fallos que pensaba era de la nueva por eso he bajado a la actual.

Simba
11/03/2016, 18:03
Hola, pues con tanta prueba no recuerdo, pero si que note algo raro, incluso pensé si no seria que el botón de home, no haria buencontacto o estaria desoldado, fue estando con Carabin que incluso lleguen a destapar el traker para mirar, pero como hacia una tarde de perros, y tenia otros problemas ya no preste mucha mas atención.

Otra cosa que noto muy de tarde en tarde, es que el Tilt pega un arreón arriba y abajo y sigue funcionando bien, ya digo muy de tarde en tarde sin determinar, pero es algo que mosquea un poco.

Me cito lo de antes, creo que era la 3.6

rortega
11/03/2016, 18:05
Fundamentalmente veo un mala funcion en los botones, version 3.5.0 .
El boton calib me deja entrar en menu y pulso por ejemplo hasta calibracion, pero cuando pulso home para activar no me responde, evidentemente he revisado conexiones y el caso es que alguna vez si lo hace, de ahi diga inconsistencia.
Éste es un problema que detectó Turruk y que me comentó Simba. Fué corregido en la 3.6.

Simba
11/03/2016, 18:07
Éste es un problema que detectó Turruk y que me comentó Simba. Fué corregido en la 3.6.
Pues sigue igual, e inconsistente.

Guillesan
11/03/2016, 18:07
Éste es un problema que detectó Turruk y que me comentó Simba. Fué corregido en la 3.6.
Bueno pues rectificare a la 3.6 pero juraria que tenia la antena en perfecto funcionamiento con la 3.5 .
A probar toca

rortega
11/03/2016, 18:10
Yo hasta dentro de una hora más o menos no puedo hacer pruebas. Probaré la 3.6 y la 4 en cuanto pueda.

Guillesan
11/03/2016, 18:19
Vale rectifico, la inconsistencia era...... el jodido pulsador, estaba mal.
A veces funcionaba y me llevaba loco, resulta que la antena grande esta todavia con la 3.5 y la he probado en menu, perfecto esto me ha hecho revisar el pulsador de la pequeña y voila.

Simba
11/03/2016, 18:20
Sin animo de marear la perdiz.
Yo sigo con las pruebas de nopid, y de momento la cosa promete con simulador.
Pero quiero comentar que me da la sensación, siempre por comparación con el 8 bits, que es como si la salida de señal de servos, estuviera un poco retrasada, o que no todas las posiciones de GPS las reflejara, como si le faltara un poco (poco pero se nota) de fluidez.
Esto se nota por que va como a pequeños saltitos, no como un movimiento fluido, que yo recordaba del 8 bits.

Simba
11/03/2016, 18:22
Vale rectifico, la inconsistencia era...... el jodido pulsador, estaba mal.
A veces funcionaba y me llevaba loco, resulta que la antena grande esta todavia con la 3.5 y la he probado en menu, perfecto esto me ha hecho revisar el pulsador de la pequeña y voila.
Si puede ser, pero no te confundas por que lo otro también se da, no solo eres tu, soy yo y Turruk con el mismo problema.

Guillesan
11/03/2016, 18:27
Si la que estoy probandoes la 3.5 cuando lo he hecho con la 4.0 efectivamente tenia mal funcion.

javiec
11/03/2016, 18:50
Buenas, el MFD driver ya se queda fijo el rx y saca el vídeo por la salida del rca. Tengo un problema con la Crius que tiene que ser una tontería pero ya estoy yo creo saturado... El pulsador de calibrar ni el home hacen nada en ningún modo... He timbrado los pines del conector y dan continuidad cuando le pulso así que si que lo tira a gnd cuando pulso.

Tengo conectado una pata del pulsador al - de la Crius (también he probando al menos de la entrada de servos) y la otra para del pulsador al pin 6, el otro el gnd al mismo sitio y al pin 5 como indica en el defines.h

Cuando pulso el pulsador veo que los 5v que tiene se ponen a 0 y no hace el calibración, se os ocurre algo?

Seguro que es una tontería....

Sent from my Redmi Note 3 using Tapatalk

rortega
11/03/2016, 19:50
Sin animo de marear la perdiz.
Yo sigo con las pruebas de nopid, y de momento la cosa promete con simulador.
Pero quiero comentar que me da la sensación, siempre por comparación con el 8 bits, que es como si la salida de señal de servos, estuviera un poco retrasada, o que no todas las posiciones de GPS las reflejara, como si le faltara un poco (poco pero se nota) de fluidez.
Esto se nota por que va como a pequeños saltitos, no como un movimiento fluido, que yo recordaba del 8 bits.
Desactiva la salida de telemetría a ver si es eso:

feature -telemetry
feature -softserial

rortega
11/03/2016, 20:30
He realizado algunas pruebas, aún me quedan muchas por hacer.

Estoy con la 4. La calibración con el menú la hace bien, habilitar deshabilitar batería y gps con el menú también. Aún no he probado el trimado, será después de cenar.

En cuanto a la fluidez, podría ser un un problema de "precisión", me explico, puede que en la versión de 8 bits no haya suficiente velocidad de cálculo como para que tarde bastante en acercar el error a 0, por lo que continúa con el movimiento, intentando moverse a una nueva posición cada vez que el error es mayor que el valor fijado en max_pid_error.

En 32 bits, es posible que consiga acercarse con menos ciclos (o pasos para entendernos) al punto deseado y, por tanto, tienda a pararse (llegar al pan0) más rápidamente de lo que lo hace la de 8 bits, y por tanto aparentemente se mueva menos...

No sé si realmente está sucedienco así, ahora así en caliente no sé como podría verificarlo, es sólo una teoría ...

Simba
11/03/2016, 20:43
En cuanto a la fluidez, podría ser un un problema de "precisión", me explico, puede que en la versión de 8 bits no haya suficiente velocidad de cálculo como para que tarde bastante en acercar el error a 0, por lo que continúa con el movimiento, intentando moverse a una nueva posición cada vez que el error es mayor que el valor fijado en max_pid_error.

En 32 bits, es posible que consiga acercarse con menos ciclos (o pasos para entendernos) al punto deseado y, por tanto, tienda a pararse (llegar al pan0) más rápidamente de lo que lo hace la de 8 bits, y por tanto aparentemente se mueva menos...

No sé si realmente está sucedienco así, ahora así en caliente no sé como podría verificarlo, es sólo una teoría ...

Lo he probado quitando sotserial, y no noto diferencias, con -Telemetry no se puede Raul, que entonces no puedo simular JiJiJi Jaja.

Pues me gusta tu teoría y podrías estar en lo cierto, yo según lo veo, esta mas que volable, y perdonarme por ser tan triquis miquis, que la verdad es que en cuanto a el seguimiento, lo hace bastante bien o va por que no decirlo, lo sigue a nivel de simulador MUY BIEN. Solo falta probarlo en vuelo y quitarnos pajas mentales.
Lo he probado con dos servos diferentes, el rápido Bluebird, y el Spingring que es bastante mas lento.
Los dos son perfectamente configurables con los parámetros del NOPID, aun no se cual me gusta mas.

Lo de los botones y el menú es otra cosa, eso no funciona bien y hay algo que se nos escapa.

rortega
11/03/2016, 20:51
Lo de los botones y el menú es otra cosa, eso no funciona bien y hay algo que se nos escapa.

Aún no he hecho las pruebas pertinentes, pero por si acaso tuviese algo que ver, necesito que comprobéis una cosa:

Si estáis con el corta y pega de los parámetros, recuerdo que en su momento había un error en el volcado de parámetros. Para min_logic_level os salía un valor negativo alto. ¿Recordáis? Mirad que valro os sale al hacer en el cli lo siguiente:

set min_logic_level

Yo creo que os va a salir 15 por defecto.

Y luego, probad a ver si podéis cambiarlo, que yo creo que no. Y el motivo es porque ese parámetro ha desaparecido del CLI,y no es por arte de magia, es por culpa mía. Literalmente he borrado la línea de código en la que se define, y ha sido por usarla como "plantilla" para las líneas de código de los nuevos parámetros nopid.

El valor 15 para ese parámetro a mí me va bien, pero recuerdo que a alguno de vosotros le hacía falta subirlo más para que fuese estable.

Creo que es eso lo que os está pasando...

rortega
11/03/2016, 20:53
Os confirmo que es eso, no váis a poder mostrar el valor ni modificarlo.
Es ese el problema.

Simba
11/03/2016, 20:56
Aún no he hecho las pruebas pertinentes, pero por si acaso tuviese algo que ver, necesito que comprobéis una cosa:

Si estáis con el corta y pega de los parámetros, recuerdo que en su momento había un error en el volcado de parámetros. Para min_logic_level os salía un valor negativo alto. ¿Recordáis? Mirad que valro os sale al hacer en el cli lo siguiente:

set min_logic_level

Yo creo que os va a salir 15 por defecto.

Y luego, probad a ver si podéis cambiarlo, que yo creo que no. Y el motivo es porque ese parámetro ha desaparecido del CLI,y no es por arte de magia, es por culpa mía. Literalmente he borrado la línea de código en la que se define, y ha sido por usarla como "plantilla" para las líneas de código de los nuevos parámetros nopid.

El valor 15 para ese parámetro a mí me va bien, pero recuerdo que a alguno de vosotros le hacía falta subirlo más para que fuese estable.

Creo que es eso lo que os está pasando...
Pues va a ser que tienes razón, ha desaparecido me sale esto:

# set min_logic_level
Invalid name


T clalro en CLI esa linea no existe

rortega
11/03/2016, 20:58
Lo arreglo en unos minutos y lo subo como 4.0.1 (antes de subirlo lo pruebo).

rortega
11/03/2016, 21:21
Ya está subido, disculpad las molestias ...:-beg:

Simba
11/03/2016, 21:24
Quedas disculpado :ansioso:, esto es de locos contentos :worthy:

Simba
11/03/2016, 21:59
Ya está probado, pero lo siento seguimos igual, el boton de Home no responde y a la 3ª punsación corta, se sale del trimado de offset.

Y en el menu sigue igual en calibración me salen caracteres raros.

Es como si fuera la versión anterior, ¿no te habrás confundido y subiste la anterior?

rortega
11/03/2016, 22:27
Ya está probado, pero lo siento seguimos igual, el boton de Home no responde y a la 3ª punsación corta, se sale del trimado de offset.

Y en el menu sigue igual en calibración me salen caracteres raros.

Es como si fuera la versión anterior, ¿no te habrás confundido y subiste la anterior?

No, no creo haberme equivocado, lo que si podría suceder es que durante el proceso de sincronización del repositorio se corrompan los datos.

Voy a compilarlo nuevamente y volver a subirlo.

Para distinguirlo voy a ponerle 4.0.2

rortega
11/03/2016, 22:44
Y en el menu sigue igual en calibración me salen caracteres raros.

Puedes de alguna forma hacer una foto para que yo vea que caracteres te salen???

Simba
11/03/2016, 22:45
Lo intento

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
11/03/2016, 22:56
Pues resulta que ahora no le da la gana, y hace la maniobra de calibración bien, o sea que no salen las letras raras.
Pero el botón home no funciona en el trim de offset, y curiosamente siempre repito siempre, a la 3ª pulsación se sale de telemetria, (HOME NOT SET).

Es lo que hay.

rortega
11/03/2016, 23:00
Pues resulta que ahora no le da la gana, y hace la maniobra de calibración bien, o sea que no salen las letras raras.
Pero el botón home no funciona en el trim de offset, y curiosamente siempre repito siempre, a la 3ª pulsación se sale de telemetria, (HOME NOT SET).

Es lo que hay.

Bueno, he experimentado el problema de la tercera pulsación del home. Creo que sé a que se debe y lo he corregido, ahora voy a probarlo, otra vez.

Lo de los caracteres raros me gutaría saber qué es, o a qué se debe. Si puediera hacer exactamente lo mismo que tú haces desde que enciendes el tracker hasta que te sale, podría averiguarlo...

Normalmente pasa cuando se desarrolla que el programador sigue siempre los mismos pasos una y otra vez, pero hasta que un usuario no lo usa y realiza las cosas siguiendo otra secuencia, no aparecen esas cosas raras...

rortega
11/03/2016, 23:10
Subida versión 4.0.2 corrigiendo lo de la tercera pulsación.

Simba
11/03/2016, 23:12
Normalmente enciendo y luego de estar pasando pantallas y para fijar la 1° apreto botón, fijo pantalla, arrancó simulador, cuando veo telemetria, apretó botón home y empieza el seguimiento, si ahora apretó 3 veces home además de no hacer timado, se sale del home .

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
11/03/2016, 23:16
Mientras probáis (si es que ya probáis algo a estas horas), comento un supuesto bug que me habéis reportado sobre el "trancazo" del tilt.

El único trancazo del tilt que yo observo es el que se produce cuando iniciamos el tracker, coge posición home y le metemos telemetría.

En ese momento el tilt calcula hacia donde tiene que apuntar, pero en ese cálculo hay un problema, y es que no sabemos en que posición está realmente, así que no sabemos desde donde tiene que realizar los calculos. Eso provoca que pegue un tirón. Depues de eso, los cálculos ya parten de una posición conocida.

Si reseteamos el tracker, bien quitando y poniendo la alimentaicón, bien al salvar tras configurar (ya sea desde cli o desde menú), se vuelve a repetir la situación, porque al reiniciar el tracker no conoce la posición en la que se quedo (no guardamos el valor del último pulso).

¿Es ésto lo que os pasa o lo experimentáis durante el seguimiento?

rortega
11/03/2016, 23:19
Normalmente enciendo y luego de estar pasando pantallas y para fijar la 1° apreto botón, fijo pantalla, arrancó simulador, cuando veo telemetria, apretó botón home y empieza el seguimiento, si ahora apretó 3 veces home además de no hacer timado, se sale del home .

Enviado desde mi GT-I9505 mediante Tapatalk

Simba, mientras escribías ésto subí la versión 4.0.2 corrigiendo definitivamente lo de la tercera pulsación del home, te lo comento por si se te ha pasado mi mensaje.

rortega
11/03/2016, 23:29
Normalmente enciendo y luego de estar pasando pantallas y para fijar la 1° apreto botón, fijo pantalla, arrancó simulador, cuando veo telemetria, apretó botón home y empieza el seguimiento, si ahora apretó 3 veces home además de no hacer timado, se sale del home .

Enviado desde mi GT-I9505 mediante Tapatalk

Acabo de seguir tus pasos. Cambio ventanas, y finalmente dejo fija la de telemetría...Luego he pulsado el botón de calibración para que aparezca el menú, he navegado a la opción para calibrar y zás, veo los caracteres raros, je je...

rortega
11/03/2016, 23:31
¿Ésto es?

http://images.tapatalk-cdn.com/16/03/11/9f3330ba9e5f780cad1eb42c481188a6.jpg

Simba
11/03/2016, 23:33
Pues ale ya los tienes, por lo menos tu los podrás identificar.

Supongo que me espero a la próxima versión. ¿NO?

Simba
11/03/2016, 23:36
Mientras probáis (si es que ya probáis algo a estas horas), comento un supuesto bug que me habéis reportado sobre el "trancazo" del tilt.

El único trancazo del tilt que yo observo es el que se produce cuando iniciamos el tracker, coge posición home y le metemos telemetría.

En ese momento el tilt calcula hacia donde tiene que apuntar, pero en ese cálculo hay un problema, y es que no sabemos en que posición está realmente, así que no sabemos desde donde tiene que realizar los calculos. Eso provoca que pegue un tirón. Depues de eso, los cálculos ya parten de una posición conocida.

Si reseteamos el tracker, bien quitando y poniendo la alimentaicón, bien al salvar tras configurar (ya sea desde cli o desde menú), se vuelve a repetir la situación, porque al reiniciar el tracker no conoce la posición en la que se quedo (no guardamos el valor del último pulso).

¿Es ésto lo que os pasa o lo experimentáis durante el seguimiento?
No no es eso, es lo segundo se experimenta durante el seguimiento, pero muy de tarde en tarde y en estas ultimas versiones, no lo aprecie o no me di cuenta.

rortega
11/03/2016, 23:38
Pues ale ya los tienes, por lo menos tu los podrás identificar.

Supongo que me espero a la próxima versión. ¿NO?

Más o menos me imagino lo que puede estar pasando, pero no estoy seguro de si voy a poder solucionarlo antes de acostarme...

Si no me da tiempo, yo creo que puedes llevarlo a volar sin problemas. Lo único que tines que hacer es cambiar la secuencia de acciones que realizas:



Enciende el tracker
Entre en el menú
Calibra

Y ya puedes usar el tracker. Lo importante es no hacer lo de la paginación previa, directamente ir al menú para calibrar.

Simba
11/03/2016, 23:41
Ok y dejalo para mañana, que no hay prisa y tienes que descansar.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
12/03/2016, 00:01
Creo que ya está resuelto, tras el cambio que he realizado (cosa simple que no debería afectar a nada más), he probado la misma secuencia que me daba el problema y ya no lo he vuelto a experimentar (he probado varias veces).

Ya vamos por la 4.0.3 ...

macgver
12/03/2016, 06:49
Hi Master

This is what I try to do the AAT 8bit.
https://www.youtube.com/watch?v=ZQiPTIwpXk4

And

My try use NAZE32 revo 6 version. then update amv-open360tracker_NAZE.hex (3.5-4.0.3).

A:My step:
1.Update amv-open360tracker_NAZE.hex
2.In CLI command line set pan0=1500.
3.set pan0_calibrated=1
4.Disable VBAT & GPS.
5.Set telemetry_baud=38400
6.save .

My question.B2 & C2-3

Can you tell how to fix issue?
Please forgive my poor English
Thank you very much


B:CLI command line Testing :
1.tilt 0 or tilt 90 ....etc . is working.
2.heading 0~360 . is not working.
3.calibrate . is working .



C.Use GPS Simulator .
1.set HOME
2.change GPS location. but pan not working.
3.change GPS location & altitude . tilt sometime working.


-------------my Current settings:----

Current settings:
servo_pwm_rate = 50
gps_baud = 2
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 6
telemetry_inversion = OFF
battery_capacity = 0
vbat_scale = 126
vbat_max_cell_voltage = 42
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 2500
i = 20
d = 250
max_pid_error = 10
max_pid_accumulator = 5000
max_pid_gain = 500
pid_divider = 15
pan0 = 1500
pan0_calibrated = 1
min_pan_speed = 0
offset = 345.000
offset_trim = 0
init_servos = 1
tilt0 = 1050
tilt90 = 2025
easing = 2
easing_steps = 60
easing_min_angle = 4
easing_milis = 15
telemetry_baud = 4
telemetry_protocol = 8
start_tracking_distance = 10
mag_declination = 0
min_logic_level = 15
nopid_min_delta = 0.200
nopid_map_angle = 90
nopid_max_speed = 200

Enabled: SERVO_TILT SOFTSERIAL TELEMETRY DISPLAY EASING

macgver
12/03/2016, 06:52
I do not know how to delete this response, please ignore him.

rortega
12/03/2016, 08:49
Hi macgver, thanks so much for sharing your proyect and contacting with us. I've sent to you a private message. Try it and if you have success, please share with us the results (a video would be great)...

Que traducido del spanglish al castellano viene a decir:

Hola macgver, muchas gracias por compartir tu proyecto y contactar con nosotros. Te he enviado un mensaje privado. Pruébalo y si tienes éxito, por favor comparte los resultados con nosotros (un víeo sería genial).

macgver
12/03/2016, 08:58
Hi macgver, thanks so much for sharing your proyect and contacting with us. I've sent to you a private message. Try it and if you have success, please share with us the results (a video would be great)...

Que traducido del spanglish al castellano viene a decir:

Hola macgver, muchas gracias por compartir tu proyecto y contactar con nosotros. Te he enviado un mensaje privado. Pruébalo y si tienes éxito, por favor comparte los resultados con nosotros (un víeo sería genial).


Hi Rortega

32bit AAT is working .
Thank you very much.

I'll shareing my video.

rortega
12/03/2016, 09:01
Hi Rortega

32bit AAT is working .
Thank you very much.

I'll shareing my video.

Bravo!

rortega
12/03/2016, 10:19
Una cosa que quiero comentar, que no es exactamente un bug, es una mala configuración.

Ya me ha pasado varias veces (no ahora, viene ya de lejos), que en algún momento el pulso de tilt cae a 0 milisegundos, y la antena se pone a apuntar por debajo del horizonte unos 45 grados.

Se debe a los pulsos que he con figurado por defecto para tilt0 y tilt90.

Lo lógico es poner el tilt90 a 1500 y ahí ajustar un poco. Y el tilt0 lo más próximo a 0 posible para que no suceda.

Yo imagino que vosotros que ya tenéis mucho recorrido en esto del RC, os habéis percatado antes que yo lo tenéis bien configurado.

Por si acaso ahí queda el comentario.

Simba
12/03/2016, 14:20
Raul siento tener que volver a reportar lo mismo, sigo igual no funciona el botón de Home para hacer trimado de Offset, y a la 3ª pulsación se sale de Home y se bloquea el menú, cosa que antes no hacia, y la única solución es desconectar y volver a conectar.
O sea que seguimos igual o peor.

La secuencia de maniobre es la misma que ya reporte.

Es lo que hay.

Simba
12/03/2016, 14:36
Ya estoy pensando si no habrá algo que no hago bien, o que se compila mal o yo que se, pero si a ti te funciona bien, no lo entiendo.

rortega
12/03/2016, 14:37
Tú estás usando GPS Local o lo tomas el home de la telemetría?

Simba
12/03/2016, 14:48
Tú estás usando GPS Local o lo tomas el home de la telemetría?
Es algo que te iba a comentar, yo estoy dentro de casa y pulso el home para Home set aircraft, siempre con el del avión.

Pero te comento que no se cuantas versiones anterior, si que funcionaba bien tal como esta y hacia el trim de offst con los 2 botones.

rortega
12/03/2016, 14:58
Es evidente que algún cambio en el código fuente le ha afectado, ahora tengo que averiguar que és.

Yo las pruebas las hacía ayer con GPS Local, así que voy a ver si experimento el problema.

Si te digo, que está programado para que al hacer una pulsación larga del botón home (2 segundos o más) se sale del modo trimado y vuelve a tener las funciones normales, para poder cambiar de páginas y tal. Y ya no podemos entrar al modo trimado hasta que aterricemos y reiniciemos el tracker. Lo expliqué el otro día.

Voy a probarlo y si me sigue funcionando, vo ya subirlo a 3 segundos o más, para evitar posibles problemas...

rortega
12/03/2016, 15:03
Estableciendo el HOME como AIRCRAFT experimento el problema.

Guillesan
12/03/2016, 18:19
Por mi parte os dire que he volado esta mañana con la antena mini, version 3.5.0.
Resultado una gozada, no he llegado a tocar nada de offset por si las moscas, la verdad es que hacia un dia esplendido y me he limitado a volar cerca, lejos, para ver el comportamineto de la antena. Pasando muy cerca y bajo la antena sigue al avion sin mas, de hecho algunas veces que no sabes ciertamente donde esta el avion con mirar donde apunta lo confirmas. Lo dicho espero Raul puede encontrar este fallo que reportamos pero en lo general un puntazo. Saludos.

rortega
12/03/2016, 19:40
Estoy reescribiendo el código que gestiona todas las funciones del botón home. Como ha uso evolucionado sobre la marcha, tiene un bug que ya he localizado, y en lugar de parchear el código, estoy reescribiéndolo para que no vuelva a fallar.

Guillesan
12/03/2016, 19:42
Pues muchas gracias, eres nuestro baluarte.

rortega
12/03/2016, 19:44
No creo que hoy lo acabe, porque tengo muchos frentes abiertos: la cena, la videconferencia con mi mujer y preparando los bártulos para mañana irme a esquiar. Y tengo que irme pronto a la cama para el madrugón.

Pero prometo dejarlo fino en cuanto pueda.

Guillesan
12/03/2016, 19:45
Joder pues claro , solo faltaba. En fin que vaya todo bien.

Simba
12/03/2016, 20:16
Raul, olvidate de nosotros, hazme el favor y disfruta de la nieve, ya que es de lo que mas hay por esos lares, ya nos contaras.

Un saludo y que tengas buen tiempo.

rortega
12/03/2016, 23:02
casi está ...

Guillesan
12/03/2016, 23:16
Pero tio tu no duermes coñe, mañana vas a esquiar sobao.

rortega
12/03/2016, 23:23
Bueno, ya está subida la versión 4.0.4.

He tenido tiempo de terminarlo y hacer pruebas, lo he probado tanto estableciendo el home como <AIRCRAFT> así como <GPS>. Aparentemente funciona el trimado, ya no se cuelga a la tercera pulsación cuando estamos con home establecido como <AIRCRAFT>...

He relizado además pruebas de vuelo en MFD y GPS telemetry, comprobando que el menú funciona, activando desactivando gps, cambiando protocolo, calibrando. También he probado el sistema nopid, etc ...

En el display se muestra ahora el valor de Of entre <> cuando se ha dejado fijo tras pulsar el botón home varios segundos, así sabremos si ya están o no los botones en modo normal.

rortega
12/03/2016, 23:23
Pero tio tu no duermes coñe, mañana vas a esquiar sobao.

Sí, justo ahora voy a la cama, de cabeza. Si no termino ésto no duermo pensando en como arreglarlo.

Guillesan
12/03/2016, 23:24
Y churros con chocolate no hace....... bueno lo flasheamos y probamos, que menos.
Venga suerte mañana, y mas gracias.

Simba
12/03/2016, 23:27
Vale tío te entiendo pero ahora tomate un lexatin y a dormir.
Gracias por todo y que disfrutes.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
12/03/2016, 23:54
Bueno pues si, ahora parece que esta funcionando bien, no lo probé todo, pero lo que me fallaba está todo OK.

Mañana seguiré probando.

Simba
13/03/2016, 16:41
Sigo informando, ya navegue por todo el menú y todo OK.

El ajuste con los botones del trimado en, + y - , y la salida a menú pantallas con botón Home, todo OK .

En lo que respecta a la precisión de seguimiento, sigue siendo de vital importancia, la calidad del servo y su rapidez, si no disponemos de un buen servo, con banda muerta estrecha y rapidez, no se le pueden pedir peras al olmo. Funcionara bien a cierta distancia, pero en las proximidades del Traker, (- de 150m) se le vera siempre cierto retraso.

Estamos esperando el servo de Guillesan, que está en Bakcorder para probarlo, pero con el Spinrin que llevo, bien ajustado que al final, y en particular con este servo, me funciona bien con los PIDs, creo que está bastante bien para volar.

Creo que estamos llegando al final del Proyecto Traker360 32, para mi tal como comente en su día con el de 8 Bits, se puede decir que es totalmente operativo.

sl2.

rortega
13/03/2016, 20:12
Bueno, me alegro que al final funcione. Seguramente saldrá algún que otro bug, que ya iremos corrigiendo.

A partir de ahora retomaré el tema de la interfaz gráfica, y realizar alguna mejora en el menú desl display como ya había comentado...

Guillesan
13/03/2016, 20:57
Hola, hoy he probado la antena mini, con version 3.5.0 , y comento.
En los dos protocolos probados, Mavlink (avion) y gps_telemetry (multi) , los resultados han sido bastante diferentes, me explico.
Avion (mavlink) como anteriormente habia dicho la prueba es satisfactoria pero..... querria saber como se gestiona en la antena el valor altura, y es que por ejemplo en MyFlyDream que es el osd usado en setup permite escoger quien da este dato barometrico o gps, una vez hecho el home en pantalla aparece "0" , y en la antena marca la altura por gps local evidentemente hay una diferencia, y es que teniendo el avion al lado mismo de la antena y teniendo seguimiento a 1 m el tilt ni se inmuta y pienso que puede ser este error. Comentamos y por no enrrollarme mas en otro comento el tema prueba multi.

rortega
13/03/2016, 22:33
...querria saber como se gestiona en la antena el valor altura...

Cuadno se recibe telemtría mavlink en el tracker, la alutra la toma llamando a estas dos funciones:



mavlink_msg_gps_raw_int_get_alt
mavlink_msg_global_position_int_get_alt

La pregunta es si el MyflyDream está manipulando las tramas gps_raw y gps_position dejando el dato a 0, y pudiera estar enviando alguna otra trama con datos de los sensores (baro en este caso), que el tracker no utiliza.

Y si está enviando la altitud del baro ¿Podría estar enviando la altitud relativa y no la absoluta? sería cuestión de erchar a volar el avión y que alguien te diga si el dato de altitud varía...

Prueba a configurar el MyflyDream metiendo la altitud desde el GPS a ver si aparece un valor absoluto.

Guillesan
13/03/2016, 22:42
Ese era mi tema, voy a seguir haciendo pruebas, con ese valor por que aunque el tilt funciona, no lo hace con la rapidez que se espera, estoy hablando en tierrra, me explico no. Es casi seguro que evidentemente haciendo el home el pone a cero la altura en lo que se refiere al OSD, habra que saber si manda ese cero o no, y el gps local de la antena toma altura si pero con respecto al mar es asi?
Aunque ese dato tambien podria saberlo conectando directamente el mavlink del avion a APM Planner no.

rortega
13/03/2016, 22:50
Ese era mi tema, voy a seguir haciendo pruebas, con ese valor por que aunque el tilt funciona, no lo hace con la rapidez que se espera, estoy hablando en tierrra, me explico no. Es casi seguro que evidentemente haciendo el home el pone a cero la altura en lo que se refiere al OSD, habra que saber si manda ese cero o no, y el gps local de la antena toma altura si pero con respecto al mar es asi?
Aunque ese dato tambien podria saberlo conectando directamente el mavlink del avion a APM Planner no.

Cuando el tracker usa la altitud del gps local, es la "abosoluta" (o con respecto al mar).

Así que la cuestión es averiguar si te está enviando una altitud relativa, es decir, toma como cero el suelo que pisas. Suele ser lo normal, pues suele enviar esa información para visualizarla en un OSD, y se supone que el aeromodelista no tiene un gps local en las gafas o monitor para hacer el cálculo de altitud relativa. Tiene sentido que esté pasando eso...

Te veo comprando el AAT driver, o tomando la telemetría desde el gps del avión haciendo lo de la Y...

Simba
13/03/2016, 23:12
Hola compis, la verdad es que cada vez se complica mas, solo nos faltaba la altura relativa y la absoluta, es para ponerse a mear y no echar gota :locos:.

Bueno yo he estado esta tarde haciendo un poco el gilis, me explico.
Queria comprobar como funcionaba con un Micro 250, y gili de mi no he cambiado el modelo, y he salido con el Quad como si fuera el ala, con el resultado que se puede esperar, he tenido suerte y solo han sido 3 palas.

Pero bueno siempre se saca algo en positivo, luego he podido comprobar que el Tilt no se posiciona en la horizontal, teniendo el Quad a 200m y en el suelo.
En cambio en casa y con el simulador si que aparentemente se situa en la horizontal, y cuando he ajustado el Tilt0 y el Tilt90, todo esta OK, horizontal y vertical.

Me pregunto si esto que comento, no tendrá algo que ver con lo que comenta Guillesan de la inclinación errónea del Tilt.

Luego comento algo mas del menú, que no me cuadra del todo.

rortega
13/03/2016, 23:31
...el Tilt no se posiciona en la horizontal, teniendo el Quad a 200m y en el suelo....

¿Y varía muchos grados?

En estos casos es importante alguna captura de datos, si es posible, viendo los datos se podría sacar algo en claro.

Simba
13/03/2016, 23:41
Creo que unos 15 o 20 pero tengo que volver a comprobarlo.
A ver si Guillesan puede confirmar lo que yo he notado o solo es un error mio.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
13/03/2016, 23:47
Y en esa prueba que has hecho, dices que es en el suelo, pero ¿Todo el tiempo, sin llegar a volarlo? Quiero decir, el micro no lo has elevado por encima del tracker. Lo pregunto porque cando el aeromodelo no coge altitud por encima del tracker, creo recordar que no se actualiza el tilt, y este se queda en la posición que estaba inicialmente. En el mometo que se eleva ya debería reaccionar.

Si es así como lo has comprobado, sin elevarlo, podría ser consecuencia de tener paráemtro init_servos igual a 0, que hace que el servo tilt no se actualice en el arranque y no se ponga al nivel horizontal.

Si has llegado a elevarlo y no se ha actualizado la altitud, o se ha actualizado y no apunta correctamente, entonces tenemos un "problema".

rortega
13/03/2016, 23:52
A ver si Guillesan puede confirmar lo que yo he notado o solo es un error mio

Bueno, Guillesan comenta que hay mucha diferencia entre la altitud que reporta el MyflyDream (0 metros) y la que reporta el gps local. En su caso el tilt debería apuntar hacia arriba al hacer home del gps, los grados depende de los metros, pero si no se ha alejado del tracker, apuntará hacia el cielo casi vertical, seguramente.

Guillesan
13/03/2016, 23:55
Y eso es justo lo que no hace, también he notado que han poniendo lis dos juntos( Avion--antena) en oled sale una distancia bastante grande entre 23-34 metros cosa que esperando que la dos GPSs tomen la totalidad de satélites posibles no baja a 1 o 2 metros se mantiene más alejado.

Simba
13/03/2016, 23:58
Bien pues si que se ha elevado, antes del aporrizage se ha elevado unos 15 m y volado unos 10m.
Luego con el cuad sin apagar ni perder telemetria lo he alejado a más de 200m para probar video y me he dado cuenta de lo del desfase de altura.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
13/03/2016, 23:59
Volado unos 100 m quería decir

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 00:15
Os comento algunas cosas sobre como se calcula el ángulo del tilt.

Lo primero es que no se hace ningún cálculo si no se ha iniciado el seguimiento.

Durante el seguimiento se comprueban las altitudes del tarcker y del aeromodelo:

if (targetPosition.alt < trackerPosition.alt){
targetPosition.alt = trackerPosition.alt;
}

Es decir, si la altitud del aeromodelo es menor que la del tracker (0 es menor que la altitud del gps siempre), se igualan las altitudes.

Con lo cual, en el caso de Guillesan, el tilt no debe apuntar al cielo, debería quedarse horizontal. Si apunta con cierto ángulo, es porque aún no se ha iniciado el seguimiento y está en la posición en la que estaba al encender el tracker.

Hecha esa comprobación (estamos con el seguimiento iniciado ya), el ángulo del tilt se calcual así:

tiltTarget = toDeg(atan((float)(targetPosition.alt - trackerPosition.alt) / targetPosition.distance));

Es decir, se calcula el arcotangente de:

(targetPosition.alt - trackerPosition.alt) / targetPosition.distance

Si ambas altitudes son iguales el resultado es 0, y el arcotangente de 0 es 0 grados (ver http://www.calculadoraconversor.com/arcotangente/)

Sea cual sea el valor de distancia, si la diferancia entre ambas altitudes es cero, el resultado es cero grados.

Por tanto, hay que realizar seguimiento y levantar el aeromodelo por encima del tracker para tener un ángulo en el tilt.

Lo de que veas 21-24 metros de distancia estando el avión junto al tarcker no sé de dónde puede venir. En caso de ser un bug del código del tracker, podría estar indicando que se ha interpretado mal algún dato de la trama entrante.

La distancia se calcula siempre en base a las posiciones GPS. Si es trata de un bug, podría deberse a fallos de redondeo o truncamiento. Si no es un bug, es que las posiciones local y del aeromodelo son distintas.

Guillesan
14/03/2016, 00:18
Entendido, voy a hacer pruebas sin GPS local, se entiende que si uso la posición del avión para la antena la variación inicial debería ser cero, esperando que el GPS avión tenga 6 o más satelites

rortega
14/03/2016, 00:19
Estoy pensando que ésto puede ser un problema y podría tener algo que ver:

if (targetPosition.alt < trackerPosition.alt){
targetPosition.alt = trackerPosition.alt;
}

Hay situaciones en las que puede darse que la altitud de aeromodelo sea menor que la del tracker, y no únicamente el problema que se quiso solucionar al meter ese condicional.

Guillesan
14/03/2016, 00:22
Hombre la variación en tierra es mínima , medio metro o un metro a lo sumo, pero te recuerdo que tengo el inicio seguimiento a 1m , se espera que si muevo el avión se inicia el seguimiento casi inmediato .

rortega
14/03/2016, 00:26
Hombre la variación en tierra es mínima , medio metro o un metro a lo sumo, pero te recuerdo que tengo el inicio seguimiento a 1m , se espera que si muevo el avión se inicia el seguimiento casi inmediato .

Bueno, no sé, pero yo en mi avión y mis multis, cuando he visualizado la telemetría sobre un mapa, siempre he visto como oscilaba una y otra vez la distancia, unas veces pocos metros otras muchos. Si tenemos dos GPS pues tenemos el problema duplicado, es posible que se produzca esa variación sin ni tan siquiera moverlos del sitio.

Yo primero de nada comprobaría si desactivando el gps local y tomando únicametne la telemetrái del avión, esos problemas persisten. A mi me huele que no se van a dar los problemas...

Guillesan
14/03/2016, 00:28
Ok eso pensaba hacer tomar la posición de un solo gps(avión) y de ahí partir con las pruebas

rortega
14/03/2016, 00:29
Simba, ¿tus pruebas eran con GPS local o sin él?

Ojo, no descarto un bug en el tracker, sólo intento dilucidar por donde nos viene el problema...

rortega
14/03/2016, 00:31
Entendido, voy a hacer pruebas sin GPS local, se entiende que si uso la posición del avión para la antena la variación inicial debería ser cero, esperando que el GPS avión tenga 6 o más satelites

En tu caso Guille, si se está produciendo esa variación de distancia por el tema de los GPS, el seguimiendo se activa sin tan siqueira haber movido el avión del suelo

rortega
14/03/2016, 00:42
Una cosa, la influencia del GPS local no es variable, me explico, una vez que se establece el HOME, la posición no varía, es siempre la misma, salvo que reiniciemos el establecimiento del home pulsando el botón o reiniciando el tracker.

Guillesan
14/03/2016, 00:46
Por eso decía que en las pruebas he esperado a que el GPS avión o multi tuviera mas satélites esperando la distancia decreciera

Simba
14/03/2016, 00:46
Confirmo que estaba en gps local.
Y que en todas las simulaciones en casa sin que diera ningún problema estaba en gps avión.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
14/03/2016, 00:50
También sospecho que el otro día cuando estuve con Carabin también note es desfase y yo diría que siempre es el mismo o parecido pero no me fije en ese momento por que tenia un video oro rosa y no estaba totalmente pendiente del Traker.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 00:54
En la versión de 8 bits, con GPS local, si movíamos el tracker a otro sitio, su nueva posición se tenía en cuenta.

En esta de 32 bits no se está teniendo en cuenta la nueva posición, eso debería corregirlo.

rortega
14/03/2016, 00:57
En la versión de 8 bits, con GPS local, si movíamos el tracker a otro sitio, su nueva posición se tenía en cuenta.

En esta de 32 bits no se está teniendo en cuenta la nueva posición, eso debería corregirlo.

Pues ésto que comento si que tendría que ver algo en ese desfase. Pues tomamos posición (lat,lon y alt) con menos satélites que en el avión. Seguramente cuando vamos a volar el avión ya tiene 11 o 12, y no lo estamos actualizando en el tracker...

Simba
14/03/2016, 01:02
No se si viene al caso, pero siempre que empiezo una simulación con gps avion, cuando el avión vuela sin coger altura, el tilt esta paralizado, y al meterle metros de altura sobre unos 30m, de repente se descuelga como si se quedara sin mando el servo y a partir de ese momento empieza a simular parece que correctamente la altura del vuelo.

rortega
14/03/2016, 01:12
No se si viene al caso, pero siempre que empiezo una simulación con gps avion, cuando el avión vuela sin coger altura, el tilt esta paralizado, y al meterle metros de altura sobre unos 30m, de repente se descuelga como si se quedara sin mando el servo y a partir de ese momento empieza a simular parece que correctamente la altura del vuelo.

Eso es porque el servo está en una posición inicial. Lo comentaba el otro día, que como no sabemos en que posición está, la primera vez que se calcula no lo hace como se espera que se haga, debido a la forma que se calcula el ánguo del tilt.

El init_servos=1 debería de solucionar este problema, pues inicia el servo durante el arranque y lo pone a 0 grados.

Por otro lado, he hecho una pequeña modificación para que el home del tarcker se actualice constantemente, así nos aseguramos que si se mueve el tracker su nueva posición se tiene en cuenta. Y a la vez, si mejora la recepción de satélites, mejora tanto en avión como en el tracker, siendo ambas más precisas.

Lo voy a subir con versión 4.0.5.

Guillesan
14/03/2016, 01:13
Se entiende que eso sucede antes de iniciar seguimiento no?

Simba
14/03/2016, 01:17
No la subas todavía que mañana quiro hacer una comprobación del funcionamiento del menú con gps local, por que sospecho que hay algo más.
Bueno yo ya me retiro.
Buenas noches.

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
14/03/2016, 01:17
Cavilando me pregunto , la flip no tiene barómetro, si es así no se podría tomar la altura con el, más preciso que GPS sería no

rortega
14/03/2016, 01:18
Se entiende que eso sucede antes de iniciar seguimiento no?

¿Qué? Es que hemos dicho varias cosas a la vez ...

Lo de actualziar el gps constantemente es a partir de que se haya establecido el home

Guillesan
14/03/2016, 01:18
Venga si a dormir

Guillesan
14/03/2016, 01:19
Para la antena variar la posición , no pillo ahora, pero entiendo que lo dices por si se embarca en un coche por ejemplo y pudiera seguir trabajando no

Simba
14/03/2016, 01:20
Guillesan edo no vale y no funcionaria, el barómetro es mucho más influenciable y da muchos más errores que el gps.

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
14/03/2016, 01:21
Estas seguro de eso, el dato altura es el que peor da un GPS por el tema de la achatado de la tierra.

rortega
14/03/2016, 01:22
Cavilando me pregunto , la flip no tiene barómetro, si es así no se podría tomar la altura con el, más preciso que GPS sería no

Bufff, precisión, que va, eso varía más ... depende de la atmósfera y puede ambiar en cualquier momento. A parte que nos obliga a repensar todo lo que hemos hablado y hacerlo de nuevo...y si te manda la altitud absoluta un gps desde el avión ¿Que hacemos comparándola con una altitud que puede que no tenga relación alguna con respecto al nivel del mar?

Guillesan
14/03/2016, 01:23
Vale , pues nada

rortega
14/03/2016, 01:23
Señores, me voy a la cama...hasta mañana.

Guillesan
14/03/2016, 01:27
Ya sería hora un saludo

rortega
14/03/2016, 01:37
Una última cosa antes de desconectar... Simba, has medido los grados de inclinación que hay entre tu tracker y tu avión o micro cuando está en el suelo? El tracker está sobre un trípode elevado a metro y medio del suelo como mínimo. Ahí podría estar parte del desfase...acabo de caer en la cuenta ...

macgver
14/03/2016, 02:45
Os comento algunas cosas sobre como se calcula el ángulo del tilt.

Lo primero es que no se hace ningún cálculo si no se ha iniciado el seguimiento.

Durante el seguimiento se comprueban las altitudes del tarcker y del aeromodelo:

if (targetPosition.alt < trackerPosition.alt){
targetPosition.alt = trackerPosition.alt;
}

Es decir, si la altitud del aeromodelo es menor que la del tracker (0 es menor que la altitud del gps siempre), se igualan las altitudes.

Con lo cual, en el caso de Guillesan, el tilt no debe apuntar al cielo, debería quedarse horizontal. Si apunta con cierto ángulo, es porque aún no se ha iniciado el seguimiento y está en la posición en la que estaba al encender el tracker.

Hecha esa comprobación (estamos con el seguimiento iniciado ya), el ángulo del tilt se calcual así:

tiltTarget = toDeg(atan((float)(targetPosition.alt - trackerPosition.alt) / targetPosition.distance));

Es decir, se calcula el arcotangente de:

(targetPosition.alt - trackerPosition.alt) / targetPosition.distance

Si ambas altitudes son iguales el resultado es 0, y el arcotangente de 0 es 0 grados (ver http://www.calculadoraconversor.com/arcotangente/)

Sea cual sea el valor de distancia, si la diferancia entre ambas altitudes es cero, el resultado es cero grados.

Por tanto, hay que realizar seguimiento y levantar el aeromodelo por encima del tracker para tener un ángulo en el tilt.

Lo de que veas 21-24 metros de distancia estando el avión junto al tarcker no sé de dónde puede venir. En caso de ser un bug del código del tracker, podría estar indicando que se ha interpretado mal algún dato de la trama entrante.

La distancia se calcula siempre en base a las posiciones GPS. Si es trata de un bug, podría deberse a fallos de redondeo o truncamiento. Si no es un bug, es que las posiciones local y del aeromodelo son distintas.


Hi Rortega

My tested 8 bit (0.9) & 32 bit Version also has the same problem.

8bit my user TinyGPS 1.2 library seems to have overcome the problem. ( No local gps mode)

In 32bit ,Only Home head (Home location = 0M , New GPS my set alttude 100M ) TILT=90. Other coordinate and alttude does not seem to how to move.

rortega
14/03/2016, 09:40
Hi Rortega

My tested 8 bit (0.9) & 32 bit Version also has the same problem.

8bit my user TinyGPS 1.2 library seems to have overcome the problem. ( No local gps mode)

In 32bit ,Only Home head (Home location = 0M , New GPS my set alttude 100M ) TILT=90. Other coordinate and alttude does not seem to how to move.

Chicos, contesto a macgver y luego os traduzco, pues es como una especie de resumen de lo hablado para ver si nos podemos aclarar entre todos.

Hi magver.

I think we are talking about / experiencing different issues:



The tilt servo doen't move on start up (32 bit version) and is pointing to a fix angle. This causes the servo tilt to make a extrange movement when the tracking starts.
The tilt servo doesn't point to the correct angle.

Which of both problems are you experiencing in 8 and/or 32 bits?

The issue 1 could be explained by the fact that whe have a parameter which is influencing the behaivor of tilt servo:


When init_servos=0 the servo tilt is not initiated and doesn't point to 0 degrees.
When init_servos=1 the servo tilt is initiated on start up and it moves to 0 degrees (horizontal possition). After the tracking is initiated (the tracker has home position and the start_tracking_distance is reached, It should move.


The issue 2 could be also happening at the same time, but I think that the origin it is different, and could be caused by several things:



The acuracy of the local GPS and aircraft GPS positions (could affect altitude and distance).
The conditional "if" which equilibrate both altitudes. If the altitude of the aircraft is lower than the altitude of the local gps, it could affect the angle.
The source of the altitude coud be from baro (relative) or from aircraft (gps)...
When the aircraft is on the floor, close to the antenna tracker (no more than 2 o 3 meters), and our antenna tracker is elevated between 1.5 and 2 meters over the floor (with a tripod), the angle should be negative, but the firmware is not taking this into account. When the aircrat reach 1.5 or 2 meters the tracker is still thinking the aircraft is in its horizontal line.

Traducido al castellano (desde el espanglish):


Creo que tenemos dos problemas distintos:




El servo tilt no se mueve al inicio en la versión de 32bits, y apunta a un ángulo fijo, lo que causa un movimiento extraño que describía Simba cuando empieza el seguimiento antes de alcanzar el ángulo calculado por primera vez.
El servo tilt no apunta al ángulo correcto.

Cuál de los dos problemas estás experimentando en 8/32 bits?


El problema 1 podría estar explicado por el ehcho de que tenemos un parámetro que influye en el comportameinto del servo tilt:




Cuando init_servos = 0, el servo tilt no se inicia, y no apunta a 0 grados, la horizontal.
Cuando init_servos=1 el servo tilt se inicializa al arrancar y se mueve a los 0 grados (posición horizontal). Una vez que se inicia el seguimiento (tiene posición home y se ha rebasado el start_trancking_distance), el servo debería apuntar al avión.

El problema 2 puede estar pasando al mismo tiempo, pero creo que su origen es distitno, y podría deberse a distintos motivos, que podrían estar ocurriendo también al mismo tiempo:


La precisión del gps local y del gps del avión, que podría affectar a las altitudes y distancia.
El condiciona "if" que iguala ambas altitudes. Si durante el seguimiento la altitud del avión es menor que la del gps local podría afectar al cálculo del ángulo
Que la fuente de la altitud del aeromodelo sea el baro (relativa) o del gps.
Cuando el avión está en el suelo, cerca del tracker, no más de 2 o 3 metros, y el tracker está elevado sobre un trípode de 1.5 a 2 metros, hay un ángulo negativo que no estamos teniendo en cuenta. Cuando el avión se eleva esos 1.5 o 2 metros, el tracker aún piensa que está en su horizontal, a 0 metros de altitud.

Para verificar todo esto hay que hacer muchísimas pruebas en muy distintas condiciones. No es lo mismo empezar el tracking a 1 metros, que a 10, que a 20, la precisión de los gps y el ángulo de inclinación ese que coment ocuando el tracker está en el suelo puede variar un montón.


Es por tanto posible que en unas ocasiones el desfase sea mayor o menor, dependiendo de los parámetros de configuración. Es cuestión de intentar identificar como se comporta en todas estas situaciones que comento para buscar soluciones...


Y por supuesto, buscar algún bug en el código, que tampoco se descarta.


De momento hice que el gps local del tracker cuando usamos 32 bits tenga el mismo efecto que en 8 bits, pues no se actualizaba consantemente en 32 bits como sucede en 8 bits. Ésto podría mitigar problemas por precisión en la posición y/o altitud (entiendo que si el avión detecta más satélites, el tracker también).


Es difícil con todo ésto que estoy contando identificar problemas, porque cada uno usamos un setup distinto, en el que también influye la telemetría que recibimos...en fin, un lío.


A mi se me ocurren cosas para solucionar parcialmente algunos posibles orígenes.

Simba
14/03/2016, 09:43
Una última cosa antes de desconectar... Simba, has medido los grados de inclinación que hay entre tu tracker y tu avión o micro cuando está en el suelo? El tracker está sobre un trípode elevado a metro y medio del suelo como mínimo. Ahí podría estar parte del desfase...acabo de caer en la cuenta ...
No creo que ese sea el problema, en todos los dias de vuelo normal con el 8 bits, cuando se desplaza uno con el avión en la mano, para ver que el Traker te sigue, siempre he visto un cierto grado de error, asumible por la corta distancia, pero que cuanto mas te separas va mejor y llega casi a la horizontalidad estando con el avión en tierra, y a unos 40 m.
En cambio con el 32 bits, ya desde el inicio llama la atención el desfase de unos 20º hacia arriba de las antenas.

rortega
14/03/2016, 09:50
No creo que ese sea el problema, en todos los dias de vuelo normal con el 8 bits, cuando se desplaza uno con el avión en la mano, para ver que el Traker te sigue, siempre he visto un cierto grado de error, asumible por la corta distancia, pero que cuanto mas te separas va mejor y llega casi a la horizontalidad estando con el avión en tierra, y a unos 40 m.
En cambio con el 32 bits, ya desde el inicio llama la atención el desfase de unos 20º hacia arriba de las antenas.
Simba, cuando puedas verifica si ese desfase es el mismo con init servos a 1 o a 0.

Y que hagas la misma prueba tanto con gps local como con gps del avión.

Y que me digas que librería estás usando en 8 bits, pues he entendido que macgver con la 1.2 de TyniGPS y gps local no lo experimenta, y yo he trasladado a la versión de 32 bits parte de la librería versión 1.3.

Para saber por qué pasa tengo que descartar cosas.

Simba
14/03/2016, 09:52
Bien ahora no puedo ya reportare

Enviado desde mi GT-I9505 mediante Tapatalk

asamnc
14/03/2016, 11:33
Hola compañeros. He seguido con interés, pero sin tiempo, este desarrollo.
Se que implica un poco de dejadez y morro, pòr mi parte, pero me interesaría saber si existe la manera de poder conseguir uno y a qué precio.

Gracias.

Guillesan
14/03/2016, 11:49
Hola asamnc te refieres montado?

rortega
14/03/2016, 13:41
No creo que ese sea el problema, en todos los dias de vuelo normal con el 8 bits, cuando se desplaza uno con el avión en la mano, para ver que el Traker te sigue, siempre he visto un cierto grado de error, asumible por la corta distancia, pero que cuanto mas te separas va mejor y llega casi a la horizontalidad estando con el avión en tierra, y a unos 40 m.
En cambio con el 32 bits, ya desde el inicio llama la atención el desfase de unos 20º hacia arriba de las antenas.
Efectivamente, cuanto más lejos y más alto, ese desfase pierde importancia.

A efectos de ilustrar el valor que tiene y ver si nos está afectando en las pruebas que hacemos, he realizado una tabla con diferentes cálculos, y que he subido aquí: https://github.com/raul-ortega/amv-open360tracker-32bits/blob/master/docs/tilt-efecto-altura-tracker.pdf

En esa tabla, diferencia calculada y ángulo calculado son los que realiza el tracker.

Diferencia Real y Ángulo Real es lo que en debería obtenerse si tuviésemos en cuenta la altura del trípode.

En la última columna tenemos un "Desfase". Eso es lo que está levantando de más el tilt por no haber tenido en cuenta la altura del trípode.

Los valores negativos de la columna ángulo real indica que el tilt debería estar apuntando hacia abajo esos grados pero no lo hace como consecuencia del condicional.

Si por lo que sea durante el seguimiento la altitud variase, de forma que el tracker entienda que el avión está por debajo suyo, volvería a igualar altitudes y el desfase aumentaría.

Eso se podría comprobar con el simulador seguramente.

Ojo, no digo que ésto sea el problema, seguramente será algo que esté mal en el código, pero a corta distancia ese desfase nos puede llegar a influenciar y confundir en nuestras pruebas, como se deduce de los datos que muestra esa tabla.

Guillesan
14/03/2016, 13:49
Hola Raul, algo se nos escapa, he podido hacer alguna de las pruebas que habla ayer. resumo.
Version 4.0.5
Gps_telemetry 4800
2 hz de refresco.
Inicio de tracking a 1 metro
Inicio prueba sin gps local, espero tener 6 satelites , proviene del multi, en pantalla salen 6 intento hacer home , los botones no me funcionan, no soy capaz de decirle a la antena haga home .
Paso a cambiar a gps local, espero tener satelites, termina haciendo solo el home, el multi a estado todo el rato debajo mismo de la antena (sin palas por si acaso) , muevo el multi la antena no se mueve coherentemente.
Por poder hacerlo subo el multi a 3 metros por encima mismo de la antena, sigue sin darme una apreciacion de funcionamiento coherente pero el tilt no se a movido para nada , seguire haciendo pruebas pero me huele a que algo no se nos escapa.

Simba
14/03/2016, 13:52
Simba, cuando puedas verifica si ese desfase es el mismo con init servos a 1 o a 0.

Y que hagas la misma prueba tanto con gps local como con gps del avión.

Y que me digas que librería estás usando en 8 bits, pues he entendido que macgver con la 1.2 de TyniGPS y gps local no lo experimenta, y yo he trasladado a la versión de 32 bits parte de la librería versión 1.3.

Para saber por qué pasa tengo que descartar cosas.
Hola de nuevo, vamos por partes:
La libreria del TyniGPS no se cual es pero estoy casi seguro que es la 1.2 pues es la del principio y no se ha tocado.

Lo del init servos a 1 o a 0, puede ser parte del problema, esta claro que su función es la que es y la cumple, con 0 no mueve servo hasta ¿¿¿ ??? esa es la cuestión, y con 1 de entrada pone el servo a 0º.

La cuestión es que cuando estamos tanto con 0 como con 1, hasta que la altura del avión, no supera al Traker en unos 30m o 40m, el Tilt no se mueve, si está en init servos a 1, se queda en 0º y si está en init servos a 0, se queda donde este y esto puede llegar a confundir, puesto que si no superas la altura de vuelo, de la marcada como arranque, el tilt no se mueve y despista un montón.

He realizado pruebas con GPS local, tomando posición de mi casa, en la terraza a unos 8m de altura +- errores por estar en ciudad.

Luego he puesto esa altura en el simulador, antes de iniciar simulación y partiendo del mismo punto GPS o muy cerca.

Al iniciar simulación sin ganar altura, el tilt no se nueve y así permanece hasta que, le meto una altura superior a unos 30m, o sea al meter 40m en el simulador, empieza a reaccionar y marca la inclinación de tilt correcta.
He realizado pruebas concluyentes, midiendo el angulo de Tilt, cuando la distancia es igual a la altura, y siempre corresponde a 45º que es lo que toca, y poniendo la altura a la misma del Traker, el angulo siempre es de 0º, esto que comento es valido, tanto para init servos a 1 como a 0.

Total que parece según me indican las pruebas, que todo funciona OK.

Puede que sumando los errores de posición Traker + errores posición Avión, se alcance una altura de puesta en marcha del Tilt de +- 70m, y haciendo un vuelo cercano y por debajo de esa altura el despiste puede ser total, pero me resisto a que este sea solo el problema, hasta que no vuele tranquilo se pueda probar bien.

Por otro lado no veo la necesidad, de este inicio de seguimiento a partir de alguna altura, esto creo que en el de 8 bits, no estaba o yo no lo recuerdo.
Si lo has puesto por algo, puede ser el problema y quizás no solo en el momento del inicio, si no a lo largo del vuelo, que se pueda enganchar y producir errores.

De momento es todo lo que puedo aportar.

Sl2

Simba
14/03/2016, 14:40
Bueno comento otro problema relacionado con los botones y el menú.
Ya comente que había algo que no me gustaba, y ya se lo que es.

En el caso de estar volando y tener el Home GPS local, se inicia ajuste de Trimado de Offset, al terminar quieres salir y volver al menú pantallas, apretamos el botón de Home durante unos 3 segundos o mas, aquí empiezan los problemas.
El Traker no tiene memorizada la ultima posición de Home, no recuerda donde está el Traker, y se vuelve loco empezando a girar sin sentido.
Esto se produce, por que el Traker a perdido satelites, y en el momento de apretar el Home, no tiene satelites.

Esto se soluciona muy fácil o muy difícil, por que si el Traker vuelve a pillar satelites, todo sigue funcionando bien, pero de lo contrario ya nunca encontrara al avión.

Resumiendo que no memoriza la posición ultima de Traker.

Simba
14/03/2016, 14:42
Editado

macgver
14/03/2016, 17:49
[quote=rortega;494905]Chicos, contesto a macgver y luego os traduzco, pues es como una especie de resumen de lo hablado para ver si nos podemos aclarar entre todos.

Hi magver.

I think we are talking about / experiencing different issues:



The tilt servo doen't move on start up (32 bit version) and is pointing to a fix angle. This causes the servo tilt to make a extrange movement when the tracking starts.
The tilt servo doesn't point to the correct angle.

Which of both problems are you experiencing in 8 and/or 32 bits?

The issue 1 could be explained by the fact that whe have a parameter which is influencing the behaivor of tilt servo:


Hi Rortega

OK , I know what you mean, I will test to see.

Thank you.

rortega
14/03/2016, 19:46
Hola de nuevo, vamos por partes:
La libreria del TyniGPS no se cual es pero estoy casi seguro que es la 1.2 pues es la del principio y no se ha tocado.

Lo del init servos a 1 o a 0, puede ser parte del problema, esta claro que su función es la que es y la cumple, con 0 no mueve servo hasta ¿¿¿ ??? esa es la cuestión, y con 1 de entrada pone el servo a 0º.

La cuestión es que cuando estamos tanto con 0 como con 1, hasta que la altura del avión, no supera al Traker en unos 30m o 40m, el Tilt no se mueve, si está en init servos a 1, se queda en 0º y si está en init servos a 0, se queda donde este y esto puede llegar a confundir, puesto que si no superas la altura de vuelo, de la marcada como arranque, el tilt no se mueve y despista un montón.

He realizado pruebas con GPS local, tomando posición de mi casa, en la terraza a unos 8m de altura +- errores por estar en ciudad.

Luego he puesto esa altura en el simulador, antes de iniciar simulación y partiendo del mismo punto GPS o muy cerca.

Al iniciar simulación sin ganar altura, el tilt no se nueve y así permanece hasta que, le meto una altura superior a unos 30m, o sea al meter 40m en el simulador, empieza a reaccionar y marca la inclinación de tilt correcta.
He realizado pruebas concluyentes, midiendo el angulo de Tilt, cuando la distancia es igual a la altura, y siempre corresponde a 45º que es lo que toca, y poniendo la altura a la misma del Traker, el angulo siempre es de 0º, esto que comento es valido, tanto para init servos a 1 como a 0.

Total que parece según me indican las pruebas, que todo funciona OK.

Puede que sumando los errores de posición Traker + errores posición Avión, se alcance una altura de puesta en marcha del Tilt de +- 70m, y haciendo un vuelo cercano y por debajo de esa altura el despiste puede ser total, pero me resisto a que este sea solo el problema, hasta que no vuele tranquilo se pueda probar bien.

Por otro lado no veo la necesidad, de este inicio de seguimiento a partir de alguna altura, esto creo que en el de 8 bits, no estaba o yo no lo recuerdo.
Si lo has puesto por algo, puede ser el problema y quizás no solo en el momento del inicio, si no a lo largo del vuelo, que se pueda enganchar y producir errores.

De momento es todo lo que puedo aportar.

Sl2
Ese puede ser un bug, que provoque que hasta que no alcance cierta altura no reaccione el tilt. No es ninguna restricción que haya metido a cosa hecha.

Bueno, todas esas pruebas que haces me van a ayudar bastante.

Una cuestión, has realizado alguna de esas pruebas anulando el easing? Si no la has hecho dímelo para hacerla yo esta tarde.

Simba
14/03/2016, 19:50
No el easing no lo he tocado y está en marcha.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 19:53
Bueno comento otro problema relacionado con los botones y el menú.
Ya comente que había algo que no me gustaba, y ya se lo que es.

En el caso de estar volando y tener el Home GPS local, se inicia ajuste de Trimado de Offset, al terminar quieres salir y volver al menú pantallas, apretamos el botón de Home durante unos 3 segundos o mas, aquí empiezan los problemas.
El Traker no tiene memorizada la ultima posición de Home, no recuerda donde está el Traker, y se vuelve loco empezando a girar sin sentido.
Esto se produce, por que el Traker a perdido satelites, y en el momento de apretar el Home, no tiene satelites.

Esto se soluciona muy fácil o muy difícil, por que si el Traker vuelve a pillar satelites, todo sigue funcionando bien, pero de lo contrario ya nunca encontrara al avión.

Resumiendo que no memoriza la posición ultima de Traker.
Cuando pulsas 3 segundos para desactivar el trimado, no debería desactivarse la posición home.

Para que eso suceda, tal y como lo he programado, es necesario una segunda pulsación de tres segundos. Es entonces cuando se desactiva el home. Lo revisaré nuevamente a ver si he metido la pata.

Lo de recordar la última posición conocida del tracker creo recordar que la de 8 bits lo hacía bien. Revisaré eso también.

Simba
14/03/2016, 19:58
Si pones lo de la segunda pulsación larga para quitar el home, es fácil hacerlo por descuido.
Seria mejor hacerlo con un condicionante que fuera por ejem estar apretando el otro botón, o mejor aún meter la opción en el menú.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 20:27
Si pones lo de la segunda pulsación larga para quitar el home, es fácil hacerlo por descuido.
Seria mejor hacerlo con un condicionante que fuera por ejem estar apretando el otro botón, o mejor aún meter la opción en el menú.

Enviado desde mi GT-I9505 mediante Tapatalk
En realidad no es que la segunda pulsación sea una obligación, es sólo una consecuencia.

Al desactivar el trimado los botones home y calibración pasan a su función normal, y entre esas funciones está la del reset del home. Es por eso que una segunda pulsación larga desactiva el home.

Simba
14/03/2016, 20:34
Pues mala historia por que de seguro, lo dejaremos sin home.
Por eso te decía lo del menú, las acciones y situaciones no tienen que dejar dudas de si le dado una pulsación o dos.
Y de toda acción se debe de poder salir fácilmente, no teniendo que aterrizar y estar dentro de la distancia de activación del Traker.
Si no es así, todo conduce a cometer errores.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 20:39
Pues mala historia por que de seguro, lo dejaremos sin home.
Por eso te decía lo del menú, las acciones y situaciones no tienen que dejar dudas de si le dado una pulsación o dos.
Y de toda acción se debe de poder salir fácilmente, no teniendo que aterrizar y estar dentro de la distancia de activación del Traker.
Si no es así, todo conduce a cometer errores.

Enviado desde mi GT-I9505 mediante Tapatalk

Está claro...

Se sabe que se ha salido del trimado porque en el display aparecen los símbolos < > englobando el valor del dato Of:

Bueno, pensaré cual de todas las opciones que se me ocurren es mejor...quizás restrinjo el poder resetar el home estando el seguimiento activado, y sólo poder resetearse si el avión está en el radio donde el seguimiento se inicia.

rortega
14/03/2016, 20:43
Simba, una pregunta un poco simplona, pero que me tiene mosquedo. ¿Has realizado las pruebas con qué simulador, con el NMEA Simulator o el del OSD?

Si has usado el NMEA simulator ¿Los cambios en valores de altitud los has metido a mano tecleando el número?

Simba
14/03/2016, 20:45
Pues a prioridad me parece mucho mejor, pero sobre todo ya que tenemos maniobra de trimado, se debería poder salir y entrar siempre y también poder fijar una determinada pantalla a voluntad y poder cambiarla.
Es algo que a base de probar me doy cuenta que si no es así, no puedes manipular lo que quieres, y eres presa del sistema, cuando debiera ser al contrario, el sistema siempre debería estar bajo nuestro mando.



Enviado desde mi GT-I9505 mediante Tapatalk

Simba
14/03/2016, 20:50
Con el nmea simulador, y claro la altura se mete manual y tecleando el número, pero con cuidado y la primera altura a nivel tierra la meto antes de iniciar telemetria.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
14/03/2016, 20:52
He tratado de simular todo lo más fiel y real posible, para evitar errores de interpretación

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 20:58
Yo estoy haciendo pruebas ahora mismo con la 4.0.4. En modo gps telemetry.

He desactivado el gps desde el cli para asegurarme que no entra en juego.
He puesto init_servos a 1 para asegurarme que el servo tilt se queda a 0, completamente horizontal.

Esta es la prueba que estoy realizando, paso por paso:



En el simulador, antes de activar la casilla para mandar la telemetría, pongo a mano una altitud de 100 metros y pongo el gas abajo del todo. Además, escribo a mano el ángulo de True Heading a 90 grados.
Activo la casilla y empieza a enviar telemetría. Aún no le he dado gas.
Pulso el botón home y se pone en <AIRCRAFT>
Le doy al gas muy poco y lo dejo que alcance unos metros para que se inicie el seguimiento. En cuanto pasa los 10 metros, se orienta hacia el Este
Quito el gas, el avión se ha quedado a 21 metros de distancia.
La altitud aún está a 100 metros, así que lo subo clic a clic pulsando los botones hacia arriba o hacia abajo de la barra de scroll de la altitud.
A muy poquitas pulsaciones, con 3 o 4 metros de altitud incrementados (103 o 104 metros de altitud total) ya noto que el tilt empieza a subir.
Al llegar a 121 metros de altitud, el tilt se queda clavado en 45 grados.

rortega
14/03/2016, 21:03
http://images.tapatalk-cdn.com/16/03/14/e3034640e0781fc71ba169a1d9ef98c5.jpg

Simba
14/03/2016, 21:04
Ok lo haces igual que yo.
Y con gps home igual pero partiendo de la altura del Traker

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 21:10
No lo he comentado, pero el easing lo tenía activo y el start_tracking_distance lo tenía a 10.

Luego he cambiado el star_tracking_distance para que reaccione el seguimiento a un metro de distancia.

Y he realizado la misma prueba, pero poniendo otra altitud de partida, en esta caso 200 metros.

Acelero muy despacito, clic a clic y cuando llega a 10 metros me paro.

Y luego empiezo clic a clic con la altitud, metro a metro, y empieza a moverse el tilt al primer clic, llegando a los 45 grados perfectos en cuando alcanzo los 10 metros de altitud.

Simba
14/03/2016, 21:15
Si si eso ya lo hice yo y por eso comente que para mi era correcto.
Lo hacemos más o menos igual, yo más en dinámica, más en movimiento, pero con el mismo resultado.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 21:18
He vuelto a realizar otra prueba.

He vuelto a poner el start_tracking_distance a 10 metros.

He puesto el init_servos a 0.

He partido de los 0 metros.

El tilt se había quedado anteriormente a 45 grados, fijo.

Al acelarar y rebasar los 10 metros de distancia, el tracker se orienta sin problema al Este, pues tenía 90 grados escritos a mano.

He bajado el acelarador quedándose a 16 metros.

El tilt evidentemente no se ha movido, sigue a 45 grados, pues no hay cambio en altitud y el init_servos impide que se mueva al inicio.

Meto a mano un 1 metro en la altitud, y el tilt se pone horizontal, baja al 0 (o casi, no se aprecia si está al 0 o al 1 grados).

Si hago clic metro a metro en la altitud hacia arriba, el tilt va subiendo a caca pulsación, y al llegar a los 16 metros de altitud, se queda clavado nuevamente a 45 grados

Editado: quito la pregunta al ver tu último mensaje.

rortega
14/03/2016, 21:22
He releído tus pruebas, así que pongo la pregunta que borré ¿Qué estamos haciendo diferente?¿O qué tenemos configurado diferente?

rortega
14/03/2016, 21:34
Cuando dices que tienes que poner 30 o 40 metros de altitud, incluso 70, ¿Está el avión parado o en movimiento? Si está en movimiento, es lógico que haya que poner una altitud considerable, pues de lo contrario no se levanta, pero eso es algo que creo que es evidente y que no hace falta que te explique.

Este comentario te lo hago porque no termino de entender si en esa explicación me estás diciendo que eso de meter 30 o 40, o 70 metros lo consideras un fallo.

Yo de estas pruebas que he realizado en con el home establecido como AIRCRAFT llego a la conclusión de que funciona correctamente.

Simba
14/03/2016, 21:42
Nada funciona igual o sea como se espera.
Yo como dije he simulado incluso el gps home, y funciona igual de bien.
Solo queda volver a probar en vuelo real.
Y que no nos liemos con los botones.
Lo del menú imagino que tiene su miga, pero te comento que a mi que he tenido que hacer en mi vida, algunas listas deprocedimientos o cheklist, lo mejor es seguir un menú, de otro modo a la más mínima posibilidad el que gana siempre es Murfy, ya me entiendes.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
14/03/2016, 22:00
Bueno, acabo de hacer una prueba para corroborar mis sospechas.

Acabo de realizar una prueba como las demás, pero con una diferencia, algo que no hice a posta en ninguna de las pruebas anteriores, bajar por debajo de la altitud de partida, y el resultado es nefasto.

Todo igual que antes, pero esta vez parto de 500 metros de altitud, y empiezo a volar haciendo el seguimiento, subiendo la altitud normalmente y viendo que reacciona bien el tilt.

Pero me pongo a volar por debajo, a menos de 500 metros, unas veces a 400 y pico, otras a 0, otras a 300 y pico, pero volviendo a subir una y otra vez por encima de los 500, alternando...

Al cabo de un rato volando, detengo el avión a 576 metros de distancia.

Y pongo la altitud a 576 metros de altitud y .... el tilt se queda casi en la horizontal.

Creo que es por culpa del condicional. Cada vez que paso por debajo del tracker, el condicional "if" iguala las altitudes de tracker y avión, y al subir otra vez, el desfase comienza, y se va a cumulando cada vez que bajo de los 500 metros y vuelvo a subir.

El problema creo que es que le da a la altitud del avión la que tiene el tracker, y debería ser del revés, debería darle a la altidud del tracker la que tiene el avión.

Esto es lo que tenemos (tanto en 8bits como en 32bits):

if (targetPosition.alt < trackerPosition.alt){
targetPosition.alt = trackerPosition.alt;
}

Y creo que deería ser así:

if (targetPosition.alt < trackerPosition.alt){
trackerPosition.alt = targetPosition.alt ;
}

rortega
14/03/2016, 22:03
Ésto es un problema. Yo creo que no debemos igualar nada, creo que la solución es simplemente evitar que el tilt se mueva hacia abajo.

Guillesan
14/03/2016, 22:14
Bingo, estoy siguiendo vuestras pruebas desde fuera de casa, Raúl creo que ahí le as dado.... Saludos

Simba
14/03/2016, 22:33
Esperar un poco, no cantemos victoria aun, esto del condicional es algo que resulto, como solución a un problema seria que teniamos, y que a resultas de muchas pruebas, Raul rectifico en el programa original, y posterior mente el amigo alemán, reconoció el fallo.
Recuerdo que a mi me pasaba sin el condicional, que el Traker se ponia loco cuando estaba en tierra y a unos cuantos metros del traker.
La causa es el error de medición del Gps del avión, que puede dar posiciones por debajo del traker, y esto no le sentaba nada bien a la logica del sistema.

OK, lo recordáis?????

Simba
14/03/2016, 22:35
Ademas si en el 8 bits va bien ¿porque en el 32 no funciona?????

Simba
14/03/2016, 23:03
Creo que debería de funcionar bien, es cuestión de volver a probar en el campo, y tener las cosas claras.

Igual nos encontramos con el mismo problema, pero entonces ya sabremos que es algo diferente a lo que pensamos ahora.

Raul, comentaste (ya son muchos los comentarios y nos liamos), que en la versión de 32 bits, le metiste otra librería de TyniGPS distinta, ¿no sera algo relacionado?.

Yo no entiendo mucho de GPS, pero igual que en la configuración con U-Center, tiene un montón de parámetros, como punto Geodésico por el achatamiento de la Tierra, y otras cosas, podría estar tomando el GPS Local una altura diferente al GPS del avión.
Yo no se si esto tiene algo que ver con la librería, lo comento solo por dar ideas, y quizás seria interesante, ver realmente cual es la altura que esta tomando el GPS Local.

rortega
14/03/2016, 23:07
Ademas si en el 8 bits va bien ¿porque en el 32 no funciona?????
El amigo macgver decía que en 8bits tenía el problema...

Simba
14/03/2016, 23:10
Pues yo nunca a partir de la ñapa que le hiciste del condicional, tuve ningún problema, ni con el GPS avión ni con el GPS Local, y he volado mucho y muchos días.

Simba
14/03/2016, 23:13
Estoy pensando en volar el próximo día con GPS Aircraft, que creo que se puede seleccionar desde el menú ¿NO?.
Si funciona bien seria determinante.

rortega
14/03/2016, 23:18
Creo que debería de funcionar bien, es cuestión de volver a probar en el campo, y tener las cosas claras.

Igual nos encontramos con el mismo problema, pero entonces ya sabremos que es algo diferente a lo que pensamos ahora.

Raul, comentaste (ya son muchos los comentarios y nos liamos), que en la versión de 32 bits, le metiste otra librería de TyniGPS distinta, ¿no sera algo relacionado?.

Yo no entiendo mucho de GPS, pero igual que en la configuración con U-Center, tiene un montón de parámetros, como punto Geodésico por el achatamiento de la Tierra, y otras cosas, podría estar tomando el GPS Local una altura diferente al GPS del avión.
Yo no se si esto tiene algo que ver con la librería, lo comento solo por dar ideas, y quizás seria interesante, ver realmente cual es la altura que esta tomando el GPS Local.
Las pruebas las he realizado sin gps local y el vuelo ha sido completamente simulado. En las primeras pruebas, a posta no rebasaba la altitud del tracker por debajo para ver que los cálculos eran correctos.

El ver que lo hacía bien descartaba el fallo de la parte de la librería TinyGPS.

La prueba rebasando la altitud por debajo es concluyente para aislar la fuente del problema.

Yo de memoria ando muy mal, pero el código fuente está conmentado afortunadamente por el autor original.

Resuelve únicamente el problema de apuntar el tilt hacia arriba cuando la altitud del avión era inferior a la del tracker.

Pero como estamos comprobando, volar por debajo y volver a subir una y otra vez hace que el tilt no se calcule bien.

Yo creo que simplemente comentando ese código debe funcionar bien. No he podido probarlo aún por la cena y la conferencia de Skype, pero me voy a poner a ello en breve.

rortega
14/03/2016, 23:19
Estoy pensando en volar el próximo día con GPS Aircraft, que creo que se puede seleccionar desde el menú ¿NO?.
Si funciona bien seria determinante.
Desde menú desactivas gps y listo.

Pero te va a fallar si rebasas la altitud por debajo varias veces.

Simba
14/03/2016, 23:28
Desde menú desactivas gps y listo.

Pero te va a fallar si rebasas la altitud por debajo varias veces.
Sera imposible por que el GPS es el del avión, y una vez despegas seguro que estás por encima, si el problema es ese, estaría claro que el GPS del Traker, estaría dando una posición, muy por encima del avión, y ese seria el problema.

rortega
14/03/2016, 23:33
Sera imposible por que el GPS es el del avión, y una vez despegas seguro que estás por encima, si el problema es ese, estaría claro que el GPS del Traker, estaría dando una posición, muy por encima del avión, y ese seria el problema.

Depende de donde estemos volando... y depende de el error de la señal gps. No de que haya más o menos satélites, sino de un efecto que ahora se me ha olvidado como se llamaba, que hace que los valores de lat/lon y altitud puedan variar considerablemente.

Guillesan
14/03/2016, 23:35
Es un efecto añadido a drede por el control de los GPS s para que no puedan usarse para cosas"malas" . Error aleatorio, solo para el GPS gratis , el que usamos. El de pago y el militar no sufre de eso.

rortega
14/03/2016, 23:37
Dilution of Precision, se llama, y puede afectar a cualquiera de las 3 dimensiones, y depende de cuan inclinados estén los satélites con respecto al receptor. Tenemos la idea de que una posición puede variar en latitud y longitud en varios metros, pero nunca nos hemos parado a pensar en que en la altitud puede haber error, y lo hay.

Guillesan
14/03/2016, 23:39
Si Raúl pero también se le aplica a la señal GPS un error variable a drede como decía para que no se mal use. De memoria te diré que Clinton por orden presidencial rebajo ese error a menos por presiones internacionales.

Guillesan
14/03/2016, 23:42
Y lo de la altura hablábamos ayer es el dato peor dado por el servicio GPS por la razón que tú apuntabas lo de la no perfección de globo terráqueo, tengo mis dudas si la precisión barométrica es mejor , de hecho se usa en aviónica,

Simba
14/03/2016, 23:45
Hola de nuevo, vamos por partes:
La libreria del TyniGPS no se cual es pero estoy casi seguro que es la 1.2 pues es la del principio y no se ha tocado.

Lo del init servos a 1 o a 0, puede ser parte del problema, esta claro que su función es la que es y la cumple, con 0 no mueve servo hasta ¿¿¿ ??? esa es la cuestión, y con 1 de entrada pone el servo a 0º.

La cuestión es que cuando estamos tanto con 0 como con 1, hasta que la altura del avión, no supera al Traker en unos 30m o 40m, el Tilt no se mueve, si está en init servos a 1, se queda en 0º y si está en init servos a 0, se queda donde este y esto puede llegar a confundir, puesto que si no superas la altura de vuelo, de la marcada como arranque, el tilt no se mueve y despista un montón.

He realizado pruebas con GPS local, tomando posición de mi casa, en la terraza a unos 8m de altura +- errores por estar en ciudad.

Luego he puesto esa altura en el simulador, antes de iniciar simulación y partiendo del mismo punto GPS o muy cerca.

Al iniciar simulación sin ganar altura, el tilt no se nueve y así permanece hasta que, le meto una altura superior a unos 30m, o sea al meter 40m en el simulador, empieza a reaccionar y marca la inclinación de tilt correcta.
He realizado pruebas concluyentes, midiendo el angulo de Tilt, cuando la distancia es igual a la altura, y siempre corresponde a 45º que es lo que toca, y poniendo la altura a la misma del Traker, el angulo siempre es de 0º, esto que comento es valido, tanto para init servos a 1 como a 0.

Total que parece según me indican las pruebas, que todo funciona OK.

Puede que sumando los errores de posición Traker + errores posición Avión, se alcance una altura de puesta en marcha del Tilt de +- 70m, y haciendo un vuelo cercano y por debajo de esa altura el despiste puede ser total, pero me resisto a que este sea solo el problema, hasta que no vuele tranquilo se pueda probar bien.

Por otro lado no veo la necesidad, de este inicio de seguimiento a partir de alguna altura, esto creo que en el de 8 bits, no estaba o yo no lo recuerdo.
Si lo has puesto por algo, puede ser el problema y quizás no solo en el momento del inicio, si no a lo largo del vuelo, que se pueda enganchar y producir errores.

De momento es todo lo que puedo aportar.

Sl2

Antes preguntabas por lo que quería decir, de meter los 40m para que inicie el movimiento de tilt, pues me explico:
1º El vuelo simulado es alrededor de mi casa con un radio de unos 80m, (con el Orux es facil), la altura de inicio la misma que fisicamente tengo el Traker unos 8m, y volando a esos 8m a 80m de radio, el Traker esta en horizontal.

2º Empiezo a incrementar altura de vuelo, a los 20m el Traker ni se entera, a los 30m sigue igual sin enterarse, cuando alcanzo los 40m reacciona y empieza a dar posición de altura.

3º A partir de este momento, parece que la inclinación del Traker es correcta, y lo verifico al comprobar que a 80m de altura, la inclinación del Traker es de 45º, altura = distancia.

¿Que está pasando aquí? empiezo a comprender que es el GPS del Taker que esta dando una altura superior a la real en unos 32m, pero no se como demostrarlo.

Es por todo esto que te comente lo anterior de los 40m de diferencia, y que incluso podría pensar que es por error de estar en una ciudad, pero creo que no, creo que el problema es real y lo tenemos en el GPS Local.

Te comentaba también lo ultimo subrayado, por que parece que sea algo que esta programado que funcione así y es totalmente reproducible.

Editado

rortega
14/03/2016, 23:52
No he implementado ni probado aún, sigo dándole vueltas porque el comentar esa parte del código no mitiga el problema si la altitud es próxima a cero.

Me explico con un ejemplo: si el tracker en un momento dado tiene altitud negativa y el avión está cerca del suelo y también da altitud negativa, pero la del tracker es una altitud por debajo de la del avión, puede haber problemas también:

Ejemplo:

Tracker: - 6 metros
Avión: -1 metro
Distancia: 1 metro

El avión vuela por encima del tracker con esos datos. Calculamos:

(altura avion - altura tracker) / distancia = ((-1) - (-6)) / 1 = 5

El arcotangente en grados de 5 es 78 grados.

El tilt apuntaría hacia el cielo.

Esta situación puede darse aunque creamos que no.

Simba
14/03/2016, 23:58
Por favor, entendiste el tema que he puesto de los 40m ?????????

rortega
15/03/2016, 00:00
Por favor, entendiste el tema que he puesto de los 40m ?????????

Estoy en ello, tengo la mente ya saturada, ja ja ja .

rortega
15/03/2016, 00:34
Todo igual que antes, pero esta vez parto de 500 metros de altitud, y empiezo a volar haciendo el seguimiento, subiendo la altitud normalmente y viendo que reacciona bien el tilt.

Pero me pongo a volar por debajo, a menos de 500 metros, unas veces a 400 y pico, otras a 0, otras a 300 y pico, pero volviendo a subir una y otra vez por encima de los 500, alternando...

Al cabo de un rato volando, detengo el avión a 576 metros de distancia.

Y pongo la altitud a 576 metros de altitud y .... el tilt se queda casi en la horizontal

Esta prueba está mal. Si la distancia era 576 metros, la altitud debía haber sido 500 + 576 = 1076. Por eso no levantaba el tilt.

El tilt funciona bien si pasamos el avión por debajo del racker y subimos...

Es decir, si tomo la posición y altitud del avión no experimento problema alguno aunque rebase por debajo la altitud del tracker.

La teoría de Simba de que el problema lo tenemos en el GPS local podría estar cogiendo más fuerza...

rortega
15/03/2016, 01:00
Las pruebas que hago co GPS local también me salen bien, no observo fallo alguno.

Me acuesto, mañana sigo con ésto...

rortega
15/03/2016, 01:01
Las pruebas que hago co GPS local también me salen bien, no observo fallo alguno.

Me acuesto, mañana sigo con ésto...

Sigo con la 4.0.4...

Simba
15/03/2016, 12:52
Sigo con la 4.0.4...
Yo también sigo con la 4.0.4.

He vuelto ha hacer pruebas (simulación) con Home Set GPS, en las diferentes pruebas al hacer Fix en automatico, ha dado diferentes resultados.

Me refiero concretamente, a la altura del avión en la cual el Tilt empieza a reaccionar.

De esto deduzco la altura que en las diferentes pruebas, el GPS Local a dado satelites y ha realizado el Fix.

El un prueba a resultado ser 44m, en otras 18m y 24m, y en cada una de ellas, al alcanzar esta altura de vuelo el avión, se ha activado el Tilt.

Es como si esa altura en la que se hizo el Fix, para el Traker significara 0m y es a partir de esa altura, que ve al avión como si estuviera a 0m.

Creo que una de las posibles soluciones, seria que el Traker fijara la altura de inicio de seguimiento, tomando el dato de altura del avión, sea cual sea esta altura, y la metiera en su Fix.
Con esto siempre estaría de inicio a la misma altura del avión, de igual forma a cuando hacemos Home GPS Aircraft.

Pese a todo este lio, creo que el problema está en otro sitio, y tenemos la suerte de poder comparar, con el Traker de 8 bits que no tiene en absoluto este problema.

Las diferencias entre los dos Trakers, en principio es lo que puede dar la solución.

rortega
15/03/2016, 13:38
Yo también sigo con la 4.0.4.

He vuelto ha hacer pruebas (simulación) con Home Set GPS, en las diferentes pruebas al hacer Fix en automatico, ha dado diferentes resultados.

Me refiero concretamente, a la altura del avión en la cual el Tilt empieza a reaccionar.

De esto deduzco la altura que en las diferentes pruebas, el GPS Local a dado satelites y ha realizado el Fix.

El un prueba a resultado ser 44m, en otras 18m y 24m, y en cada una de ellas, al alcanzar esta altura de vuelo el avión, se ha activado el Tilt.

Es como si esa altura en la que se hizo el Fix, para el Traker significara 0m y es a partir de esa altura, que ve al avión como si estuviera a 0m.

Creo que una de las posibles soluciones, seria que el Traker fijara la altura de inicio de seguimiento, tomando el dato de altura del avión, sea cual sea esta altura, y la metiera en su Fix.
Con esto siempre estaría de inicio a la misma altura del avión, de igual forma a cuando hacemos Home GPS Aircraft.

Pese a todo este lio, creo que el problema está en otro sitio, y tenemos la suerte de poder comparar, con el Traker de 8 bits que no tiene en absoluto este problema.

Las diferencias entre los dos Trakers, en principio es lo que puede dar la solución.

Vamos a ver Simba, que yo creo que el problema es un problema de concepto, y no es problema del tracker.

Si tu GPS Local fija la altitud a 44m, esa es la altitud absoluta donde estás tú, tu tracker, tua vión cuando está en el suelo y Turruk grabándote... Por tanto, también el GPS de tu avión está al mismo nivel y marcará también 44 metros aproximadamente. Ambos deben estar a la misma altitud absoluta al inicio, +- un error y +- la altura del trípode.

Esa premisa hay que trasladarla siempre al simulador, no podemos tene en el GPS Local 44 metros y en el simulador 0, sencillamente porque no es una situación real, salvo que hayas puesto tu tracker sobre un edificio o un montículo y tú estes en un llano más abajo.

En esa situación de 44 metros en GPS Local y 0 metros en el simulador, es completamente lógico y normal que hasta que el avión no llegue a los 45 metros el tilt no se levantará. Es más, si quitásemos el condicional (edito: quita el condicional y otro condicional más que hace que tampoco apunte hacia abajo), el tilt apuntaría hacia abajo los grados necesarios, y podrías usar tu tracker situado en la azotea del edificio perfectamente siguiéndo tu avión que está 44 metros más abajo.

Yo pensaba que ésto lo tenías claro, pero deduzco de tu explicación que no, o bien yo me estoy confundiendo y no he terminado de entenderte.

rortega
15/03/2016, 13:43
Yo creo que el tilt del tracker funciona perfectamente y no le pasa nada, tan sólo nos estamos haciendo la picha un lío.

El que si puede tener un problema es Guillesan porque su MyFlyDream le está metiendo la altitud relativa y no la absoluta del GPS. El si que puede estar experimentando algún problema con el tilt. Pero tú y yo con gps teleemtría directa no podemos tener problema alguno si el concepto lo aplicamos correctamente.

Simba
15/03/2016, 13:57
Bueno yo primero lo probare en vuelo real y luego comentare.

Lo único que espero es que funcione igual al de 8 bits.

Si luego salen los tipicos problemas de menús y otras cosas, es normal que se tenga que pulir con mejoras.


Enviado desde mi GT-I9505 mediante Tapatalk

Simba
15/03/2016, 14:25
Yo creo que el tilt del tracker funciona perfectamente y no le pasa nada, tan sólo nos estamos haciendo la picha un lío.

El que si puede tener un problema es Guillesan porque su MyFlyDream le está metiendo la altitud relativa y no la absoluta del GPS. El si que puede estar experimentando algún problema con el tilt. Pero tú y yo con gps teleemtría directa no podemos tener problema alguno si el concepto lo aplicamos correctamente.

+1 en todo Raul, confirmo al 100% tu comentario, y no son solo conjeturas.

Acaba de probar en las mismas condiciones exactas, el Traker de 8 bits, (como no se me había ocurrido antes), y resulta que funciona exactamente igual.
Lo dicho todo esta OK, y solo debemos fijarnos en mejorar en lo posible la interface, tanto Menú (prioritario) como la otra que estás implementando.

Sl2.

Simba
15/03/2016, 14:56
Vamos a ver Simba, que yo creo que el problema es un problema de concepto, y no es problema del tracker.

Si tu GPS Local fija la altitud a 44m, esa es la altitud absoluta donde estás tú, tu tracker, tua vión cuando está en el suelo y Turruk grabándote... Por tanto, también el GPS de tu avión está al mismo nivel y marcará también 44 metros aproximadamente. Ambos deben estar a la misma altitud absoluta al inicio, +- un error y +- la altura del trípode.

Esa premisa hay que trasladarla siempre al simulador, no podemos tene en el GPS Local 44 metros y en el simulador 0, sencillamente porque no es una situación real, salvo que hayas puesto tu tracker sobre un edificio o un montículo y tú estes en un llano más abajo.

En esa situación de 44 metros en GPS Local y 0 metros en el simulador, es completamente lógico y normal que hasta que el avión no llegue a los 45 metros el tilt no se levantará. Es más, si quitásemos el condicional (edito: quita el condicional y otro condicional más que hace que tampoco apunte hacia abajo), el tilt apuntaría hacia abajo los grados necesarios, y podrías usar tu tracker situado en la azotea del edificio perfectamente siguiéndo tu avión que está 44 metros más abajo.

Yo pensaba que ésto lo tenías claro, pero deduzco de tu explicación que no, o bien yo me estoy confundiendo y no he terminado de entenderte.

Joerrrrrr rortega, tienes mas razón que un santo, te puedes creer que no había visto hasta este momento.

Nada chico que al final como decías tenemos la picha un lio.

Esto está funcionando igual de BIEN, luego tu ya le pones y le quitas, todos los condicionantes que quieras, para que pueda apuntar al valle o a las nubes, eso ya es cosa tuya.

En fin perdona por tanto lio, aunque lo importante es que nos entendemos.

sl2.

rortega
15/03/2016, 20:49
Joerrrrrr rortega, tienes mas razón que un santo, te puedes creer que no había visto hasta este momento.

Nada chico que al final como decías tenemos la picha un lio.

Esto está funcionando igual de BIEN, luego tu ya le pones y le quitas, todos los condicionantes que quieras, para que pueda apuntar al valle o a las nubes, eso ya es cosa tuya.

En fin perdona por tanto lio, aunque lo importante es que nos entendemos.

sl2.

Bueno, lo vamos a dejar como está...uffffff. ja ja ja ... Hay momentos en los que nos liamos a darle vueltas a la perola y no veas...

Voy a ir intentando mejorar cositas, pero ya con tranquilidad, que estos días han sido cansinos con estos bugs que parecían infinitos ...

No he probado la versión 4.0.5, pero supongo que lo hará bien. Como comenté hace un par de días, había incluído algo que ya tenía la versión de 8 bits, es el "refresco constante" de la posición home cuando estamos usando un GPS local.

Para refrescar la memoria, en su día hablamos de este tema, y alguien comentaba al respecto que el tracker parecía haberse diseñado para usarlo desde un vehículo en movimiento.

Pues bien, al hacer la migración a 32 bits no implementé el código para uso del GPS local en una primera fase. Más tarde ya lo puse en marcha, con todas las mejoras que tenemos, pues hacía uso del código empleado para la gestión del GPS en cleanflight. Fue en ese punto donde aparqué la parte del refresco constante, y más adelante se me olvidó implementarlo.

Con las vueltas que le hemos dado al tema del mal funcionamiento del establecimiento del home por culpa de la integración del trimado de offset, me percaté de que aún no había implementado ese "refresco constante" de la posición del tracker con los datos del GPS local.

Ese es el cambio incluído en la versión 4.0.5.

Es complicado para mí realizar la prueba porque no puedo salir a la calle a hacerlo, el tiempo no da tregua... Si alguien la carga y puede reportar resultados, sería bueno que verificase dos cosas:


si muevo el tracker de posición (pongamos 20 metros) el seguimiento sigue haciéndose correctamente.
Si desconectando el cable del GPS, la posición home se mantiene, es decir, si el tracker sigue fielmente al avión.

Es importante hacer la prueba sin trastear los botones de trimado para verificar que eso lo hace correctamente.

Una vez comprobado que esas dos cosas se hagan correctamente, procederé a mejorar el tema salida del modo trimado de offset y reseto del home con segunda pulsación, con idea de que se reestablezca el home con la última posición conocida. Es fácil hacerlo, pero antes necesito esa verificación para asegurarme de que va a funcionar bien.

Guillesan
15/03/2016, 20:52
Raúl mañana te hago esa prueba, tengo la 4.0.5 cargada en las dos antenas ok

Simba
15/03/2016, 21:19
Vale tomo nota y luego si puedo igual me ponga y la pruebo.

rortega
15/03/2016, 21:47
Unas preguntas:

¿Qué soléis hacer cuando aterrizáis el avión?
¿Os acercáis con él al tracker dentro de la distancia donde no hace seguimiento?¿Reseteáis el tracker o volvéis a echar el avión a volar tras cambiar baería sin más?
¿Y cuando finalizáis la jornada?

Las preguntas van encaminadas a saber en qué estado se queda el tilt, pues estoy maquinando como recordar la última posicón conocida para tenerla en cuenta en el próximo reinicio. O bien la almaceno sin más, o bien añadimos la funcionalidad de "aparcar" el servo tilt en una posición concreta.

No puedo estar almacenando cada posición, pues estaría escribiendo constantemente en la memoria toda la configuraición, y lleva su tiempo, el tracker no funcionaría correctamente.

Así que la idea es almacenar esa posición cuando suceda algo muy concreto:


Acercamos el avión al tracker y guardamos la última posición.
Usamos una opción de menú para "aparcar el tilt".
Pulsamos el botón de calibración X segungos para "aparcar el tilt".

En todos los dos últimos casos podemos poner un parámetro de configuración en el que definamos el ángulo en el que queremos que quede si decidimos aparcar el tilt, pensando en que os interse más tenerlo en un ángulo que en otro por motivos de transporte.


Ya me diréis si os gusta la idea o pasamos de ella porque no lo véis necesario.

Guillesan
15/03/2016, 21:49
Pues , cuando termino recojo avión y luego apago antena.

rortega
15/03/2016, 21:53
Pues , cuando termino recojo avión y luego apago antena.

Pérdida de telemetría ... ahí sería un buen momento para guardar la posición...

Guillesan
15/03/2016, 21:54
En medio del campo, los GPSs no tardan nada en pillar satélites de hecho al volver a volar enciendes antena y avión sea como fuera esperas a que tengan posición y eso cuesta muy poco

rortega
15/03/2016, 22:05
En medio del campo, los GPSs no tardan nada en pillar satélites de hecho al volver a volar enciendes antena y avión sea como fuera esperas a que tengan posición y eso cuesta muy poco

No quise decir "guardar posición del GPS", lo que quise decir es guardar la posición del servo tilt.

Guillesan
15/03/2016, 22:07
A vale, yo lo tengo a "1" cuando conectas se pone horizontal, espero tener telemetria y posición y palante

Simba
15/03/2016, 22:11
Yo también recojo el avión y lo traigo cerca del Traker luego apago avión para evitar que entre en failsafe y apago traker y emisora.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
15/03/2016, 22:59
Lo de guardar la posición de los servos, es indiferente, yo por mi no lo pondría.
Yo cuando desmonto antenas siempre manipulo a mano los servos, para guardar en la maleta, y sin problemas.

carabin
15/03/2016, 23:13
Simba decirte que en la de 8 bits puse el potenciómetro para ajustar pan0 a 1500 baje a 2; 1 la relación ajuste pid y en servo test se movía bastante bien pero en la realidad con el simulador a veces da como picos en los impulsos que no me gusta . Así que ahora seguir probando con otro .
Gracias al todos por el ríf y rafe de los últimos mensajes se os ve pensando como el tracker .ja ja

Enviado desde mi GT-I9301I mediante Tapatalk

Simba
15/03/2016, 23:31
Simba decirte que en la de 8 bits puse el potenciómetro para ajustar pan0 a 1500 baje a 2; 1 la relación ajuste pid y en servo test se movía bastante bien pero en la realidad con el simulador a veces da como picos en los impulsos que no me gusta . Así que ahora seguir probando con otro .
Gracias al todos por el ríf y rafe de los últimos mensajes se os ve pensando como el tracker .ja ja

Enviado desde mi GT-I9301I mediante Tapatalk
Hola Carabin, si con servo test va bien y se fija posición con seguridad, sin oscilar o con un pequeño ajuste final, eso esta bien.

Con el simulador y sobre todo si vuelas cerca +-150m de radio veras que va como a saltitos, por la acción del servo, que con muy poco error no tiene fuerza, y al abrir un poco el angulo empieza a mover, total que va un poco como a saltitos, eso es normal, y lo puedes corregir y afinar aumentando el min_pan_speed, yo lo tengo = 12, pero lo mejor es dejarlo lo mas alto que puedas sin que el servo empiece a moverse u oscilar.

Venga me alegro que ya estés otra vez en marcha.

Sl2.

Simba
15/03/2016, 23:54
Es complicado para mí realizar la prueba porque no puedo salir a la calle a hacerlo, el tiempo no da tregua... Si alguien la carga y puede reportar resultados, sería bueno que verificase dos cosas:


si muevo el tracker de posición (pongamos 20 metros) el seguimiento sigue haciéndose correctamente.
Si desconectando el cable del GPS, la posición home se mantiene, es decir, si el tracker sigue fielmente al avión.

Es importante hacer la prueba sin trastear los botones de trimado para verificar que eso lo hace correctamente.

Una vez comprobado que esas dos cosas se hagan correctamente, procederé a mejorar el tema salida del modo trimado de offset y reseto del home con segunda pulsación, con idea de que se reestablezca el home con la última posición conocida. Es fácil hacerlo, pero antes necesito esa verificación para asegurarme de que va a funcionar bien.

Bueno Raul, no es que yo te meta prisa, nada de eso pero yo ya tengo probada la 4.0.5. Jajajaja jaja.

Realizada con simulador y con Home GPS set.

1º En terraza pille 7 satelites, hizo Fix y tal cual me baje a la leonera, puse el Traker en ventana.

2º Los satelites bajaron y oscilaba entre 3 y 5, al bajar a 3 perdia en el Oled Fix, y con 5 recuperaba Fix.

3º Meto Simulador, meto telemetria, empizo vuelo, subo altura, mantengo radio de vuelo en +-150m, compruebo que el Tilt me sigue en la altura, con el Orux veo por donde va y que el Traker PAN apunta justo por donde vuela.

4º Me translado con el Traker en la mano, al otro lado de mi casa, pierdo satelites y Fix, pero el Traker sigue funcionando igual, por tener memorizada la posición.

5º Vuelvo coger satelites y fix, en esta parte de la casa, pero el Traker sigue a su marcha sin ningún problema.

6º Pierdo cobertura de Telemetria Bloutooht, se para el Traker, la recupero y se vuelve a orientar y seguir el vuelo.

7º Me vuelvo a la leonera y todo sigue funcionando bien.

Hasta aquí la prueba esta realizada, pero como siempre pasa, sale un pero.

Empiezo a manipular los botones, ajusto un poco por probar el Offset.
Salgo del ajuste Offset con pulsación larga.
Y esto es lo peor, SIN DARME CUENTA APRIETO BOTÓN HOME, Craso error.
El Traker pilla el Home (Aircraft) y la cagamos, de estar volando en realidad, el Traker se va a la Mi-----eer------da.

Esto es algo que no puede pasar.

Simba
15/03/2016, 23:57
Raul no le des vueltas ahora, déjalo para mañana o cuando tengas ganas, por hoy ya vale, yo voy a plegar Yaaaaaa.

rortega
16/03/2016, 00:47
Empiezo a manipular los botones, ajusto un poco por probar el Offset.
Salgo del ajuste Offset con pulsación larga.
Y esto es lo peor, SIN DARME CUENTA APRIETO BOTÓN HOME, Craso error.
El Traker pilla el Home (Aircraft) y la cagamos, de estar volando en realidad, el Traker se va a la Mi-----eer------da.

Esto es algo que no puede pasar.

Completamente de acuerdo.

En cuanto al test, gracias por el reporte, impresionante la rapidez.

Vamos a ver mañana Guille que tal le va en el campo, interesa ver que pasa si desplazamos el tracker muchos metros, para ver que apunte a su sitio con su nueva posición, que la va renovando el gps local.

Y eso, ya mañana tranquilamente voy "capando" lo de los botones para que no se dé el problema. Creo que lo más simple, seguro, y para mí rápido de implementar, es que no se pueda resetear el home mientras está el avión en el aire.

Tras terminar con el trimado únicamente podremos usar el botón para fijar las pantallas o entrar al menú. El botón home se recuperá para resetear el home si el avión está dentro del radio en el que no hay seguimiento.

Guillesan, tendrás que poner un star_tracking_distance un poco mayor de 1...

Guillesan
16/03/2016, 00:48
Cuánto te parece bien 10

rortega
16/03/2016, 00:50
Cuánto te parece bien 10

Puede que incluso 5 te sirva, es que si pones 1 no va a funcionar el tema, y habría que usar alguna alternativa para poder hacerlo.

Creo que metiendo el avión en el radio de no tracking es una solución bastante simple para poder reactivar el uso del boton home. Nadie va a usarlo estando el avión en vuelo, porque es una "locura"...

Guillesan
16/03/2016, 00:51
Ok pondré 5

Guillesan
16/03/2016, 00:55
Esta posibilidad de antena en movimiento se comentó ya hace mucho en el foro alemán , en la posibilidad de embarcar la antena en un coche( movil) y tener la posibilidad de controlar el avión o lo que fuera desplazándose. Eso habré la puerta a realizar "ciertas virgerias" , la verdad no sé si lo haré nunca.

rortega
16/03/2016, 00:55
Estoy probando lo de guardar la última posición de tilt, en principio va, no parece que pegue trancazo...

rortega
16/03/2016, 00:59
Esta posibilidad de antena en movimiento se comentó ya hace mucho en el foro alemán , en la posibilidad de embarcar la antena en un coche( movil) y tener la posibilidad de controlar el avión o lo que fuera desplazándose. Eso habré la puerta a realizar "ciertas virgerias" , la verdad no sé si lo haré nunca.

Eso es lo que decía yo hace unos mensajes más atrás, que alguien había comentado eso mismo que comentas tú... Ésto lo que abre la puerta es la puerta a que la nueva norma no impida que nos alejemos más de 500 metros con al avión en FPV, je je ... ¿Imaginas uno subido en el coche haciendo fpv mientras el amiguete conduce y tiene el avión a vista? Las leyes siempre tienen lagunas, y la tecnología siempre va por delante, je je.

Guillesan
16/03/2016, 01:02
Hace ya tiempo puse el link de un vídeo de un tío que se había montado un remolque con todo lo imaginable para controlar el avión , tiraba de el un 4x4 , pilotaba un hidroavión y después de un largo vuelo por carretera siguiéndolo aterrizaba en un lago

rortega
16/03/2016, 01:03
Hace ya tiempo puse el link de un vídeo de un tío que se había montado un remolque con todo lo imaginable para controlar el avión , tiraba de el un 4x4 , pilotaba un hidroavión y después de un largo vuelo por carretera siguiéndolo aterrizaba en un lago

No me des ideas, que en España tengo una fregoneta :ansioso:

Guillesan
16/03/2016, 01:04
No as visto el vídeo?

Simba
16/03/2016, 01:09
El Traker de Turruk un MFD AT, hace eso que comentáis, instalandole un GPS local.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
16/03/2016, 01:13
Vi un vídeo de un tipo con un remolque espectacular, pero no recuerdo a ver visto la parte en la que se desplaza.

Guillesan
16/03/2016, 01:14
Ok parece que si era ese. Había montado una carlinga excepcional en un remolque

Guillesan
16/03/2016, 01:20
Lo encontre, ved y flipar:
https://www.youtube.com/watch?v=LJ4tmWvzcAY

rortega
16/03/2016, 01:25
Queee fuerte !!!

Bueno señores, hasta mañana.

Guillesan
16/03/2016, 01:25
Ok buenas noches

macgver
16/03/2016, 13:12
Hi Rortega

Today I tested MAVLINK. But the coordinates seem to be a problem, I ask whether this protocol can operate properly?

MY User APM Copter 3.3.3 version.

https://youtu.be/dHrTgQsGQwk

macgver
16/03/2016, 15:01
This is what I use the GPS simulator to test 8 & 32 Bit Version Video.

https://www.youtube.com/watch?v=sd_AWnqm0hE

rortega
16/03/2016, 15:45
Hi Rortega

Today I tested MAVLINK. But the coordinates seem to be a problem, I ask whether this protocol can operate properly?

MY User APM Copter 3.3.3 version.

https://youtu.be/dHrTgQsGQwk
Could you capture frames into a file? I would analyze what happens...

I tested the protocol with data provided by Guillesan and it worked well, but the frames were produced with MyflyDream autopilot.

rortega
16/03/2016, 15:50
Great!!! Could you explain a bit what we see? I see a gap between both, is it caused by the firmware or is a bad synchronization cause by the edition of the video?

macgver
16/03/2016, 15:50
Could you capture frames into a file? I would analyze what happens...

I tested the protocol with data provided by Guillesan and it worked well, but the frames were produced with MyflyDream autopilot.

Hi Rortega


How to capture frames into a file? I try 8 bit there will be errors.

macgver
16/03/2016, 15:53
Great!!! Could you explain a bit what we see? I see a gap between both, is it caused by the firmware or is a bad synchronization cause by the edition of the video?


I found 8 & 32 Tilt have not synchronized.

My use GPS simulator (5HZ).

8Bit FW Version=0.9
32 Bit FW Version=4.05.

rortega
16/03/2016, 16:03
Could you provide your config.h forma de 8bits and the configuration params of the 32bits?

macgver
16/03/2016, 16:11
Could you provide your config.h forma de 8bits and the configuration params of the 32bits?

file is: https://drive.google.com/file/d/0BxodPu6xkBd_ck9BeW1qanVLbWs/view?usp=sharing

rortega
16/03/2016, 16:23
El vídeo de macgver muestra como hay un comportamiento diferente entre el tilt de 8bits y el de 32, pero he visto que en la configuración hay valores distintos en los parámetros de easing.

Seguramente influye, pero aunque fuesen iguales, dudo que el comportamiento sea exactamente igual.

rortega
16/03/2016, 17:25
file is: https://drive.google.com/file/d/0BxodPu6xkBd_ck9BeW1qanVLbWs/view?usp=sharing
There are some differences in the values of easing parameters between 8bits and 32bits. It could cause a differnt behaivor.

In 32 bits you have 60 steps, and each one takes 15 ms.

In 8 bits you have only 10 steps.

Also you have min angle set to 4 in 32bits, but 2 in 8bits.

Nevertherless, there are differences in the implementation that could cause differents behaivors between both versions.

macgver
16/03/2016, 17:28
Nevertherless, there are differences in the implementation that could cause differents behaivors between both versions.[/QUOTE]

OK, I understand. Thanks for the explanation.

other issue. How to capture frames into a file?

rortega
16/03/2016, 17:30
Nevertherless, there are differences in the implementation that could cause differents behaivors between both versions.

OK, I understand. Thanks for the explanation.

other issue. How to capture frames into a file?[/QUOTE]
You can use Hércules for that purpose.

Simba
16/03/2016, 22:16
Hola, Guillesan ¿como fueron las pruebas ?

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
16/03/2016, 22:55
Parece por lo que nos cuenta macgver que mavlink no va muy bien, yo hice pruebas en us día con la telemetría de guillesan y funcionaba, pero es cierto que en algunos momentos, al principio de pasarle el archivo a través de hércules, se veía algun dato mal, pero va tan rápido que es imposible... Intentaré revisar la parte de mavlink por si detecto algo.

Hoy aún no he tenido oportunidad de ponerme con el tema del home, pero le voy a dedicar al menos una hora al asunto, y si no ya mañana con más profundidad.

Simba
16/03/2016, 23:00
OK, pero Guillesan iba a probar ¿ MAVLINK o GPS-Telemetry ?

Es por salir de duda si en vuelo real, ha tenido algún problema con GPS-Telemetry.

rortega
16/03/2016, 23:12
OK, pero Guillesan iba a probar ¿ MAVLINK o GPS-Telemetry ?

Es por salir de duda si en vuelo real, ha tenido algún problema con GPS-Telemetry.

La verdad es que ahora mismo no sé en qué protocolo lo iba a probar...

Yo debería estar probando el FrSky en el campo, pero desde que aquí se hacía de noche antes de las 5 de la tarde (afortunadamente ya alargan los días) y que hasta anoche mismo estaba nevando, y todas las modificaciones que hago, no hay quien se ponga a reparar el ZMR para hacer pruebas reales.

Simba
16/03/2016, 23:34
Yo no he podido, hacer pruebas reales en condiciones, el Ala no he podido volar, por haberme dejado la batería de vídeo en casa :icon_twisted::icon_twisted:, y el Micro 250 no lo tengo bien configurado, desde el aporrizaje del otro día, y no me fio de que la Telemetria, este funcionando bien.

No obstante, he estado dando vueltas por el campo, con el Dron en la mano, y el resultado ha sido un poco desalentador, ya que unas veces la dirección del Traker era correcta y otras bastante mala, en distancias de entre 80m a 150m.

Sospecho que el enlace de Telemetria con el Dron, no esta muy fino, ya que con el simulador, funcionaba perfecto.
En fin quiero pensar, que sea la Telemetria y no el Traker, por eso de mi interés, en saber los resultados de Guillesan.

macgver
17/03/2016, 06:21
OK, I understand. Thanks for the explanation.

other issue. How to capture frames into a file?
You can use Hércules for that purpose.[/QUOTE]



My MAVLINK File in :https://drive.google.com/file/d/0BxodPu6xkBd_Q2w3RWdwNlBadkU/view?usp=sharing

rortega
17/03/2016, 09:37
My MAVLINK File in :https://drive.google.com/file/d/0BxodPu6xkBd_Q2w3RWdwNlBadkU/view?usp=sharing

I've got the file, this afternoong I'll try it...

Guillesan
17/03/2016, 09:38
Buenos dias, ayer estuve ocupado y no puede entrar al foro a poner resultados, hoy lo hare. Raul llego ya lo enviado?

rortega
17/03/2016, 09:47
Buenos dias, ayer estuve ocupado y no puede entrar al foro a poner resultados, hoy lo hare. Raul llego ya lo enviado?

Tengo el aviso del servicio postal :)

Guillesan
17/03/2016, 09:49
A OK, Me alegro, luego expongo las pruebas, con sus claros y oscuros.

Guillesan
17/03/2016, 13:25
Vale como dije aqui pongo algunas consideraciones de las pruebas hechas ayer, no pude hacer algunas mas que hubiera querido por que llovia y me jorobo el tema.

AMV360 version 4.0.5
Inicio seguimiento a 5 metros
gps local minimo 6 satelites
GPS_TELEMETRY
Prueba realizada con un multi.
Velocidad 4800 bau 2Hz
Openlrs

He realizado dos pruebas:
1ª Sin gps local , si bien la antena sigue al multi no lo hace con la velocidad deseada, hay veces que parece hacerlo bien aunque en movimientos rápidos la antena no reacciona con la ligereza esperada, lo que mas resalta es el tilt que no va coordinado con la altura real.
2ª Con gps local, adolece de los mismos problemas pero puede que por apreciación mía un poco mas que sin gps local.
Por pruebas posteriores y viendo la diferencia que hay entre los dos gpss puede que también este afectado el dato de altura por lo que tilt no trabaja correcto.
Pongo dos videos realizados con el multi no son muy esclarecedores por que estaba solo y se hace difícil grabar y pilotar pero se puede ver la lentitud que expongo.

https://www.youtube.com/watch?v=8ySeSV1LJgU

https://www.youtube.com/watch?v=sBg5as1GWDQ


Mavlink

Sin gps local y myflydream, no se puede hacer home por que no envía numero gpss

Estando en Mavlink y haber desabilitado el gps local, ver que no funciona, quieres habilitarlo el gps local y no funciona.
Apagando antena y volviendo a conectar si funciona el habilitar gps local.

Iniciados los dos gpss (avion-antena) y con 8 satélites en cada uno fijados, la distancia que marca entre ellos es de 90 metros o mas, creo es una distancia demasiado grande dada la exactitud de las posiciones.

Vale seguimos con las pruebas.

Guillesan
17/03/2016, 15:16
Nueva prueba con el multi, eso si en tierra por que el tiempo no acompaña.
GPS_Telemetry
4800 baud ojo 4Hz refresco
No gps local

La prueba a cambiado a mucho mejor, el seguimiento es mas real, el tilt por circunstancias obvias no he podido probarlo pero se le antoja mas fiel.
parece que el refresco de 4 Hz antes 2 ha influido a mejor .
Con gps local me da a mi en la raiz que hay algun problema , deberia sert mas fiel pero posicionados los dos como antes he dicho marca unas distancia entre equipos desmesuradas.
Sigo con el tema.

Simba
17/03/2016, 16:52
Yo no he podido, hacer pruebas reales en condiciones, el Ala no he podido volar, por haberme dejado la batería de vídeo en casa :icon_twisted::icon_twisted:, y el Micro 250 no lo tengo bien configurado, desde el aporrizaje del otro día, y no me fio de que la Telemetria, este funcionando bien.

No obstante, he estado dando vueltas por el campo, con el Dron en la mano, y el resultado ha sido un poco desalentador, ya que unas veces la dirección del Traker era correcta y otras bastante mala, en distancias de entre 80m a 150m.

Sospecho que el enlace de Telemetria con el Dron, no esta muy fino, ya que con el simulador, funcionaba perfecto.
En fin quiero pensar, que sea la Telemetria y no el Traker, por eso de mi interés, en saber los resultados de Guillesan.


Bueno chicos, me cito a mi mismo para recordar lo que puse ayer.
Pues resulta que mis pruebas, en las cuales y debido a lo mal que funcionaba, le echaba la culpa a algún fallo de la telemetria, por que no entendía que fuera tan mal como lo hacia.

El Micro250, lo volé en 3 ocasiones, hasta que lo deje por lo mal que seguía el Traker, luego me puse a dar vueltas con el coche, con el Quad en la mano, sacado por la ventanilla, en nuestro campo que es bastante grade, esto se puede hacer, y estando Turruk junto al Traker, haciendo de testigo.
Bueno pues lo comentado, un puro desastre de seguimiento.
Tanto es el caso, que desde ayer estoy verificando el funcionamiento de la Telemetria y el mando del Orange LRS, pues estaba muy mosqueado.

Ahora que a Guillesan le pasa lo mismo, no es que me alegre, entenderme que no es así, pero por lo menos se que mi Orange LRS esta bien, que si no todo son sospechas y dar palos de ciego.

Ya con lo visto, llego a la conclusión siguiente, algo pasa cuando se recibe telemetria vía radio, que no pasa cuando se hace simulación en casa.

Yo tengo configurado en Orange LRS, 4800 bauds y 4 Hz, y en simulador igual, pero se parecen en la realidad, como un huevo a una castaña.

En fin no lo entiendo, pero no va bastante mal por decir algo.

Es lo que hay.

Guillesan
17/03/2016, 17:00
Hola Simba parece que estamos llegando a las mismas conclusiones. Yo percibo un gran retraso en el seguimiento, el caso es que algunas veces se posiciona pero de seguir el movimiento del (avion_multi) se queda parado como si no recibiera telemetria, el caso es que si lo hace de eso ya me he asegurado , existe unos retrasos no continuados, no se si me explico. En fin seguiremos con el tema.

Guillesan
17/03/2016, 17:02
Ampliando sobre el tema, parece que cuanto mas cerca estan uno del otro la cosa va a peor, si el seguimiento se hace de un objeto lejano, es decir mas o menos 150 o 200 metros en adelante la cosa cambia, tambien puede ser por que el espacio a mover sea menor .

Guillesan
17/03/2016, 17:03
Habras leido tambien que usando gps local en oled me sale una distancia muy grande entre los dos(antena_avion) y que no es asumible. Te pasa a ti tambien ?

rortega
17/03/2016, 17:47
Se podrían estar perdiendo tramas o no interpretando bien las que entran. Por qué? Ni idea.

El aumento en la velocidad del seguimiento entre 2hz y 4hz ya sabemos que tiene su lógica, pero si se están perdiendo tramas o no procesándose correctamente, al tener más tramas habrá más probabilidad de que entren buenas.

rortega
17/03/2016, 17:48
La enigma a resolver es: Por qué con el simulador va bien y en el campo no?

Imagino que habréis calibrado estando allí, no?

Guillesan
17/03/2016, 17:50
Siempre Raúl, es casi una liturgia.

rortega
17/03/2016, 17:52
Unas capturas de datos no vendrían mal para descartar errores en las tramas, y errores en la parte del firm que las procesa.

rortega
17/03/2016, 17:56
Hoy voy a descansar de tocar el código fuente. Me voy a dedicar a reparar el ZMR para poder hacer pruebas en el campo este finde.

Guillesan
17/03/2016, 17:57
Te puedo decir que yo ya he probado lo siguiente.
En consola, he visto lo que recibe el módulo bluetooh de la antena, recibiendo del tx . La carencia y los datos no tienen diferencia apreciable a una conexión directa. Pienso que y no sé cómo hacerlo una vez entrando en placa ver el producto después de procesarlo . Es decir poder ver en gráfica lo que se manda a servos

Guillesan
17/03/2016, 17:57
Me parece bien , que puedas probar en campo, ok

Simba
17/03/2016, 17:58
Habras leido tambien que usando gps local en oled me sale una distancia muy grande entre los dos(antena_avion) y que no es asumible. Te pasa a ti tambien ?
La verdad es que no podia ver al Quad y el Oled al mismo tiempo, pero si tu lo has visto, ya lo tenemos.

Lo que comentas Raul de la perdida de Tramas, puede pero lo veo dificil, yo no llego a comprender, cual es la diferencia en que las tramas le lleguen, o por bluetooht desde el simulador, o por el puerto del OpenLRSng, que esta bastante cerca, o como mucho a 150m, que es nada para el Orange, ademas no da ni un solo pitido de falta de paquetes, (el orange Tx), o sea que es perfecto.
Ademas ya estamos curtidos, con esto de la Telemetria del Orange, y lo que pilla el GPS lo manda perfecto, estoy seguro que no pierde ni una sola Trama.
Y por otro lado tenemos la comparación (toda comparación resulta odiosa), del hermano de 8 bits, que como ya sabemos, funciona a nivel de 1ª división, en la liga de los Trakers a nivel Mundial :biggrin2:.

Bueno pues eso, faena tenemos.

Guillesan
17/03/2016, 17:59
Pienso que el problema está en el proceso después de entrar telemetria.

rortega
17/03/2016, 18:02
Te puedo decir que yo ya he probado lo siguiente.
En consola, he visto lo que recibe el módulo bluetooh de la antena, recibiendo del tx . La carencia y los datos no tienen diferencia apreciable a una conexión directa. Pienso que y no sé cómo hacerlo una vez entrando en placa ver el producto después de procesarlo . Es decir poder ver en gráfica lo que se manda a servos
Es que lo que se manda a servos nos va a decir poco.

Lo suyo es sacar los datos de coordenadas y altitud una vez el tracker los tiene procesados, para ver si coinciden con la realidad o no.

Quizás podría haber errores de truncamiento de datos que sean los que hagan que haya diferencia entre lo que el tracker recibe y lo que el interpreta.

rortega
17/03/2016, 18:03
Pienso que el problema está en el proceso después de entrar telemetria.
Pues eso, que estamos pensando en lo mismo, que los datos se pueden estar traduciendo mal.

Guillesan
17/03/2016, 18:05
Ok, habrá tiempo, arregla tu parato y vuela así tendrás más apreciación de lo que hablamos.

rortega
17/03/2016, 18:09
La verdad es que no podia ver al Quad y el Oled al mismo tiempo, pero si tu lo has visto, ya lo tenemos.

Lo que comentas Raul de la perdida de Tramas, puede pero lo veo dificil, yo no llego a comprender, cual es la diferencia en que las tramas le lleguen, o por bluetooht desde el simulador, o por el puerto del OpenLRSng, que esta bastante cerca, o como mucho a 150m, que es nada para el Orange, ademas no da ni un solo pitido de falta de paquetes, (el orange Tx), o sea que es perfecto.
Ademas ya estamos curtidos, con esto de la Telemetria del Orange, y lo que pilla el GPS lo manda perfecto, estoy seguro que no pierde ni una sola Trama.
Y por otro lado tenemos la comparación (toda comparación resulta odiosa), del hermano de 8 bits, que como ya sabemos, funciona a nivel de 1ª división, en la liga de los Trakers a nivel Mundial :biggrin2:.

Bueno pues eso, faena tenemos.
Sí Simba, yo creo que tenemos todos en la mente lo mismo. Puede que no se estén interpretando bien los datos.

Tenéis que hacerme capturas de datos, de lo que llegue al orange, para que yo se las pueda meter al programa y ver que hace con ellos.

Simba
17/03/2016, 18:15
Estoy pensando en un procedimiento para comprobar que manda el Orange.

Seria algo así como meter en el Rx Orange, las tramas del simulador, tal como lo haria un GPS, solo GPGGA y 4 hz.
Luego del Tx sacamos las tramas, y se las metemos al Traker.

¿Puede ser util para algo?

Guillesan
17/03/2016, 18:16
A suplir el avión por el simulador pasando por el Orange

Simba
17/03/2016, 18:27
A suplir el avión por el simulador pasando por el Orange
OK eso es.

Guillesan
17/03/2016, 18:47
Pues no esta mal pensado

Simba
17/03/2016, 19:31
Chicos ya lo he probado, y funciona igual de mal, se vuelve loco sobre todo en distancias cortas, que casi me desmonta el Tripode.
Cuando se aleja parece ir mejor, se relaja bastante pero no deja de oscilar.

Creo que es exactamente lo que hace en el campo.

Lo que hago como dijo Guillesan, es sustituir el avión por el simulador, total que las tramas de GPS del simulador, ahora pasan por el Orange, solo eso.

Por cierto y aunque no venga a cuento, si no le mando PPM al modulo Tx Orange, no transmite y no funciona la telemetria, luego una vez que ya está lanzado, puedo apagar los PPM y sigue mandando Telemetria, no creo que esto tenga nada que ver, pero lo comento como curiosidad.

Simba
17/03/2016, 19:32
Guillesan podrías probar tu también y comparar.

Guillesan
17/03/2016, 19:33
Lo pruebo en un rato si

Simba
17/03/2016, 19:35
Otra cosa importante, el Orux funciona igual de BIEN, y los datos salen de la Flip 32, es decir que si el Orux ve exactamente donde está el avión, el Traker debería hacer lo mismo.

Guillesan
17/03/2016, 19:38
Está en la "traducción" a los servos y es solo una intuición . Yo tengo dos protocolos trabajando gps y mavlink , pero no puedo comparar por qué el avión enseguida toma distancia y el multi todo lo contrario.

Guillesan
17/03/2016, 19:50
Una sola cosa Raul, te acuerdas que rectificaste el tema mavlink pata el MyFlyDream que no enviaba numero satelites, pues en la version 4.0.5 no lo hace por lo que sea, y no puedo probar ese protocolo sin gps local por que al no recibir los 6 satelites minimos no deja hacer home. Acuerdate de rectificarlo. Gracias.

Simba
17/03/2016, 19:56
Gullesan, a ser posible no empecemos a mezclar las cosas, centrémonos en el protocolo GPS Telemetry.

Hay una cosa que me llama la atención, estoy recibiendo en el OruxMap (móvil) las 2 tramas GPGGA y GPRMC, y no lo entiendo, por que yo solo le estoy mandando la GPGGA.

Guillesan
17/03/2016, 19:58
Gullesan, a ser posible no empecemos a mezclar las cosas, centrémonos en el protocolo GPS Telemetry.

Hay una cosa que me llama la atención, estoy recibiendo en el OruxMap (móvil) las 2 tramas GPGGA y GPRMC, y no lo entiendo, por que yo solo le estoy mandando la GPGGA.

Por que si no lo entiendo mal no es una salida transparente sino que la crea la flip, de ahi que pueda traducir lo que entra a cualquier protocolo.
Y no mezclo es por comparar si con diferente protocolo me hace lo mismo, puede ser que este el problema solo en GPS_telemetry

Simba
17/03/2016, 20:06
Vale, pero centremonos en el GPS Telemetrty, a ver si le encontramos algo, que al pasar por el Orange se introduce algo que el Traker no entiende.

Yo no se como sacar las tramas que llegan al traker, tengo los Bluetooht todos ocupados, y el FTDI tambien lo utilizo, para mandar la Trama al Bluetooht desde el simulador.

Seria cuestión de ver que sale directamente del puerto del orange, y grabarlo para mandarselo a Raul, pero yo no puedo, no se me ocurre nada.

Guillesan
17/03/2016, 20:09
En eso estoy, en montar todo el tinglao.
simulador-rx-tx-bluetooh-bluetooh-pc(otra vez) para capturar

Simba
17/03/2016, 20:30
Venga que a mi ya no me quedan balas :laugh:, lo he intentado con otro fdti que tengo, pero no me sale nada en la consola de Arduino.

rortega
17/03/2016, 20:41
La idea es que pinchéis aunque sea un FTDI en el puerto serie del orange y lo capturéis con el hércules o similar.

Lo único que necesito son tramas reales del GPS, sin que hayan pasado por el tracker. Así que no es necesario que tengáis el tracker funcionando ni conectado.

Por otro lado, si el tracker interpreta mal la telemetría, lo que salga hacia orux u otra aplicación, estaría igual de mal interpretado. No es que lo que entre salga igual como si hicieras un puenete, no, lo que entra se desempaqueta, se saca latitud, longitud y altitud y luego se empaqueta y se saca por otro puerto.

No sé si entendéis lo que yo creo que puede estar pasando. Imagináos que me llega este número:

40.72061738049473

Es una latitud y tiene un montón de precisión, pero me sobran muchos decimales y me tengo que quedar con menos.

40.72061798049473

Pues bien, por lo que sea, en alguna operación, o en una conversión de tipos de datos, podría estar truncando en lugar de redondear.

Truncar es exactamente lo que se ve en verde, simpelemente desechamos los decimales de la derecha que están en rojo.

Pero si redondeara, por el peso que tienen los dos decimales primeros decimales rojos "98", el resultado debería ser:

40.720618

Eso, que a simple vista parece insignificante, puede dar lugar a que distintas posiciones que varían decenas de metros, devuelvan el mismo valor, y la antena no se desplace hasta que no varíe el resultado.

Ojo, no digo que eso esté pasando, lo mismo es otra cosa, pero como con el simulador aparentemente va bien, pues lo único que me cabe pensar es que hay errores en los datos que maneja el tracker, y hasta que no estás en el campo delante de la antena no lo puedes apreciar, cuando el avión está en un lado y el tracker apunta bastante más atrás o se queda medio parado.

rortega
17/03/2016, 20:42
Venga que a mi ya no me quedan balas :laugh:, lo he intentado con otro fdti que tengo, pero no me sale nada en la consola de Arduino.

Quizás lo suyo sea capturar las tramas con ucenter, no lo sé. Yo lo voy a intentar también con el gps que uso como gps local en el tracker, que me da tramas NMEA y creo que no voy a necesitar configurar nada.

Guillesan
17/03/2016, 20:44
Raul aqui tienes, captura real sacada del bluetooh, antes de entrar en la flip.
https://www.dropbox.com/s/1210568x41z0kex/Gps_directo_bluettoh.log?dl=0

rortega
17/03/2016, 20:45
Ahhh, Guillesan, me ha llegado eso, voy a tener que hacer un cursillo para poder montarlo... un millón de gracias.

Guillesan
17/03/2016, 20:46
Ahhh, Guillesan, me ha llegado eso, voy a tener que hacer un cursillo para poder montarlo... un millón de gracias.
Aqui estamos para lo que haga falta , solo faltaba, con eso puedes dejarte una tracker fina fina.

rortega
17/03/2016, 20:48
Raul aqui tienes, captura real sacada del bluetooh, antes de entrar en la flip.
https://www.dropbox.com/s/1210568x41z0kex/Gps_directo_bluettoh.log?dl=0

Vale, estupendo, esos datos me sirven.

Ahora voy a pasárselos al tracker y hacer debug por consola a ver si una vez que haya extraído los datos coinciden.

Guillesan
17/03/2016, 20:50
Vale, estupendo, esos datos me sirven.

Ahora voy a pasárselos al tracker y hacer debug por consola a ver si una vez que haya extraído los datos coinciden.

OK, las tramas veras que hay movimiento es con el multi en mano moviendome un poco por fuera, que sepas que aqui tambien hace frio..... jajajaja

Simba
17/03/2016, 20:51
OK, entiendo lo que dices, pero entonces ¿por que esta sacando tramas buenas para el OruxMap ? yo lo veo en el OruxMaps con una precisión muy buena y con una trayectoria perfecta.
Si los datos los interpretara mal, la salida del OruxMap, el serial 30, estaría sacando datos malos, pero no es así.

rortega
17/03/2016, 21:11
OK, entiendo lo que dices, pero entonces ¿por que esta sacando tramas buenas para el OruxMap ? yo lo veo en el OruxMaps con una precisión muy buena y con una trayectoria perfecta.
Si los datos los interpretara mal, la salida del OruxMap, el serial 30, estaría sacando datos malos, pero no es así.

Quizás porque el dato que le mando a oruxmaps aunque se almacenan en las mismas variables, no pasan por determinado código que hace operaciones concretas.

Mirad, nada más que con la primera trama ya he encontrado algo:

$GPGGA,183626.250,4134.3424,N,00158.4206,E,1,7,1.46,303.3,M,51.3,M,,*5C

Así es como llegan la latitud y la longitud, una en verde y la otra en azul. Eso llega en grados y minutos decimales, y hay que convertirlo todo a grados.

La conversión correcta es ésta:

41.572373
1.973677

Pero ésto es lo que hace el tracker:

41.57237
1.97367

Se ha comido el último decimal, y creo que tengo una idea de por qué...

Guillesan
17/03/2016, 21:13
Viva tus ideas, por que despreciar ese dato , no lo soporta el micro?

Guillesan
17/03/2016, 21:15
Y la altura, veo que va de decimales +- 0,x no será que también lo trunca o como se diga y solo mueve cuando hay mucha diferencia?

rortega
17/03/2016, 21:15
Viva tus ideas, por que despreciar ese dato , no lo soporta el micro?

No, puede ser que se deba a una operación de asignación entre variables de distinto tipo, o que en alguna operación de división se haya perdido el último dígito. Tengo que verlo y solucionarlo.

Yo he leído ya a Simba en varias ocasiones decir "va un poco retrasado"...y es muy posible que se deba a eso, porque esos decimales suponen metros, y si no probad en google earth a meter ambas coordenadas y ver donde queda una y donde queda otra.

Guillesan
17/03/2016, 21:16
Seguro que es así, en tus manos está, si lo soporta el micro no sé yo no despreciaría "nada" no sé si me explico

Guillesan
17/03/2016, 21:31
Quizás porque el dato que le mando a oruxmaps aunque se almacenan en las mismas variables, no pasan por determinado código que hace operaciones concretas.

Mirad, nada más que con la primera trama ya he encontrado algo:

$GPGGA,183626.250,4134.3424,N,00158.4206,E,1,7,1.46,303.3,M,51.3,M,,*5C

Así es como llegan la latitud y la longitud, una en verde y la otra en azul. Eso llega en grados y minutos decimales, y hay que convertirlo todo a grados.

La conversión correcta es ésta:

41.572373
1.973677

Pero ésto es lo que hace el tracker:

41.57237
1.97367

Se ha comido el último decimal, y creo que tengo una idea de por qué...


A groso modo hay metros de distancia, como minimo 3.
Eso en un seguimiento cercano es muchisimo., como para decir lo que estamos observando de que no apunta donde debe.

rortega
17/03/2016, 21:33
Pues no lo tengo claro, estoy comprobando que el dato que se le pasa a oruxmaps es el mismo. Y eestoy viendo el código del tracker 8 bits y lo hace exactamente igual, se come el último dígito también.

Así que el problema de precisión es el mismo en ambas versiones del tracker.

Guillesan
17/03/2016, 21:34
Pero la apreciación en el mapa no es la misma que una antena apuntando. Igual el 8 bits tampoco tenía la justeza debida.

Guillesan
17/03/2016, 21:37
Lo que si es de sentido comun es que si la primera posicion la buena que manda el gps y que luego conversiona y desprecia el ultimo numero, la que interesa es la primera es la verdadera, donde realmente esta el movil, por que viendolo en el mapa como tu dices y he hecho hay una diferencia grande a poca distancia, evidentemente a 200 o 300 metros se minimiza pero cerca es brutal .

rortega
17/03/2016, 21:37
Pero la apreciación en el mapa no es la misma que una antena apuntando. Igual el 8 bits tampoco tenía la justeza debida.

No sé lo que has querido decir...

Creo que son muy pocos metros y que son asumibles, no es ese el problema pues, debe ser otra cosa.

rortega
17/03/2016, 21:38
Lo que si es de sentido comun es que si la primera posicion la buena que manda el gps y que luego conversiona y desprecia el ultimo numero, la que interesa es la primera es la verdadera, donde realmente esta el movil, por que viendolo en el mapa como tu dices y he hecho hay una diferencia grande a poca distancia, evidentemente a 200 o 300 metros se minimiza pero cerca es brutal .

¿Seguimos hablando de GPS Telemetry?

Guillesan
17/03/2016, 21:39
No sé lo que has querido decir...

Creo que son muy pocos metros y que son asumibles, no es ese el problema pues, debe ser otra cosa.

Hombre tres metros son muchos metros a 15 metros de distancia, el seguimiento muy cercano que seria por ejemplo con un multi, a distancias mayores como decia pues no pero tres metros a lo sumo de diferencia entre la posicion "buena" y la que el tracker extrae pues es mucho no te parece.

Guillesan
17/03/2016, 21:40
¿Seguimos hablando de GPS Telemetry?

Si claro , pero a fin de cuentas todos los protocolos terminan enviando lat y long y si lo conversiona "mal" pues ahi esta la cosa no se digo yo.

rortega
17/03/2016, 21:41
Hombre tres metros son muchos metros a 15 metros de distancia, el seguimiento muy cercano que seria por ejemplo con un multi, a distancias mayores como decia pues no pero tres metros a lo sumo de diferencia entre la posicion "buena" y la que el tracker extrae pues es mucho no te parece.

No, no me parece mucho, de verdad, es que a 15, ni a 20, ni a 100, ni a 200 necesitamos tracker, por eso digo que es asumible.

rortega
17/03/2016, 21:41
Si claro , pero a fin de cuentas todos los protocolos terminan enviando lat y long y si lo conversiona "mal" pues ahi esta la cosa no se digo yo.

No, no todos los protocolos nos entregan los datos en las mismas unidades.

Guillesan
17/03/2016, 21:43
No, no me parece mucho, de verdad, es que a 15, ni a 20, ni a 100, ni a 200 necesitamos tracker, por eso digo que es asumible.

Perdona Raul pero no estoy de acuerdo, para el seguimiento de un multi y ademas con video 5.8 es imprescindible que la antena helical este lo mas ajustada al tarjet posible, por que es muy pero que muy direccional.
Te dire que este fin de semana vi trabajar un pequeño tracker que usaba la telemetria Eagletree sacada de un Vector con una muy pequeña patch de 5.8 y el movimiento era muy cercano a lo exacto.

Simba
17/03/2016, 21:55
No Guillesan, el 8 bits tiene una precisión muy aceptable, siempre en vuelo cerca, se aprecia el desfase pero es totalmente predecible, cosa que en el 32, es totalmente aleatoria a distancias de 40m.

Guillesan
17/03/2016, 21:59
No Guillesan, el 8 bits tiene una precisión muy aceptable, siempre en vuelo cerca, se aprecia el desfase pero es totalmente predecible, cosa que en el 32, es totalmente aleatoria a distancias de 40m.
Bueno pero segun dice Raul la conversion es la misma, quien sabe si ajustando esa conversion ganan los dos 8 y 32 , no se algo debe estar mal no se como explicarme.

Simba
17/03/2016, 22:01
Yo sigo pensando que las dos tramas, la del simulador y la del GPS/ Orange, tienen que tener algo de diferencia, aparte de los decimales.
Los decimales pueden dar precisión, pero no movimientos aleatorios.

No podría ser que tuviéramos, algún dato en la trama que no estuviera, exactamente igual en el protocolo NMEA.
Raul tu siempre probaste con simulador (en 32 bits), y esa trama la tienes perfecta, pero el GPS/ Orange, tiene que ser por bolones, algo diferente.

TURRUK
17/03/2016, 22:01
Perdona Raul pero no estoy de acuerdo, para el seguimiento de un multi y ademas con video 5.8 es imprescindible que la antena helical este lo mas ajustada al tarjet posible, por que es muy pero que muy direccional.
Te dire que este fin de semana vi trabajar un pequeño tracker que usaba la telemetria Eagletree sacada de un Vector con una muy pequeña patch de 5.8 y el movimiento era muy cercano a lo exacto.

Yo estoy acuerdo con que dice Guillesan, hay antenas que falta esta precesion.

Simba
17/03/2016, 22:05
2+2=4 así de simple, el Traker va bien en simulación, y hace todos los cálculos bien, repito ¿por que con la Trama del GPS no se la traga y se atraganta, pues por que tiene algo diferente, SI o SI.

Guillesan
17/03/2016, 22:08
2+2=4 así de simple, el Traker va bien en simulación, y hace todos los cálculos bien, repito ¿por que con la Trama del GPS no se la traga y se atraganta, pues por que tiene algo diferente, SI o SI.

Entiendo pero en simulacion tu no tienes la prespectiva de un avion real , tu no ves ese avion por lo cual no sabes a ciencia cierta si la antena esta bien dirigida, es cuando en la realidad de un avion volando que puedes discriminar si esta o no apuntando.
Mas en un multi que su vuelo es muy aleatorio , me explico sube ,baja, hacia delante, atras inmediato .

Guillesan
17/03/2016, 22:11
La reaccion de la antena ante este movimiento a mi entender es poco justa, lo que se pretende es que esa antena este en todo momento apuntando ese multi y por ende al avion, en estas ultimas pruebas, lastima no pude grabar video como hubiera querido, cuando desplazaba el multi hacia digamos la izquierda de mi vision incluso manteniendo una altura igual la antena tardaba a reaccionar y seguirlo era cuando lo paraba estatico que terminaba apuntando, me explico.

Simba
17/03/2016, 22:11
Bueno pero segun dice Raul la conversion es la misma, quien sabe si ajustando esa conversion ganan los dos 8 y 32 , no se algo debe estar mal no se como explicarme.

Si Guillesan, creo que te entiendo, pero no se las diferencias que pueda haber en el calculo de 8 y 32, pero creo que estás pensando algo que yo también pienso, y es que en la migración puede haber algún factor desconocido, no se me ocurre otra cosa, estamos dando palos de ciego.
Y para colmo resulta que el calculo o conversión o lo que sea para el OruxMaps, va sencillamente genial.

En fin esto es cuestión de que Raul nos dirija a nosotros, y no nosotros a Raul, ya que nada podemos aportar en cuanto a codigo.

Guillesan
17/03/2016, 22:15
Si Guillesan, creo que te entiendo, pero no se las diferencias que pueda haber en el calculo de 8 y 32, pero creo que estás pensando algo que yo también pienso, y es que en la migración puede haber algún factor desconocido, no se me ocurre otra cosa, estamos dando palos de ciego.
Y para colmo resulta que el calculo o conversión o lo que sea para el OruxMaps, va sencillamente genial.

En fin esto es cuestión de que Raul nos dirija a nosotros, y no nosotros a Raul, ya que nada podemos aportar en cuanto a codigo.
Efectivamente y de ahi viene el que quiera yo hacer lo mismo con otro protocolo para confirmar que en los dos modos adolece de lo mismo igual esto le aclara a Raul el tema, decia hoy que usando gps local y esperando ver 8 satelites en cada uno de ellos en oled me daba una diferencia de 90 y mas metros , no asumible, no puede ser, usando los gpss que tenemos deberia ser pocos metros es cuando no usas gps local y la natena asume la misma posicion que el tarjet que parece que trabaja mejor , no se si esto esta relacionado con el problema que tenemos.

JuanTrillo
17/03/2016, 22:20
Si os puede servir la maquina de estados NMEA de ikarus esta publicada y soporta DD.MM.MMMM y DD.DDDDDD. La he probado durante años con todo tipo de gps sin problemas.

Enviado desde mi X16 mediante Tapatalk

Simba
17/03/2016, 22:21
Entiendo pero en simulacion tu no tienes la prespectiva de un avion real , tu no ves ese avion por lo cual no sabes a ciencia cierta si la antena esta bien dirigida, es cuando en la realidad de un avion volando que puedes discriminar si esta o no apuntando.
Mas en un multi que su vuelo es muy aleatorio , me explico sube ,baja, hacia delante, atras inmediato .

No se si te lo creeras, pero llevo unas cuantas horas bastantes, simulando vuelo cercano alrededor de mi casa, con diferentes radios, y con la ayuda del OruxMap que en el plano se puede apreciar muy bien por donde va y cuando tiene que apuntar, girar, subir y bajar, lo que sea y estoy saturado de probar tanto el 8 bits como el 32, y la conclusión que saco la definitiva, es que a nivel de simulador las 2 versiones van exactamente igual, con la solo y unica diferencia de los servos que utilicemos y el ajuste de rapidez que tengamos, pero a nivel de funcionamiento, son prácticamente iguales.

Bien pues dicho esto, la diferencia abismal entre los dos sistemas, es en el vuelo real no simulado, cuando la trama es la NMEA del GPS pura y dura, o sea no simulada.

Guillesan
17/03/2016, 22:23
Si os puede servir la maquina de estados NMEA de ikarus esta publicada y soporta DD.MM.MMMM y DD.DDDDDD. La he probado durante años con todo tipo de gps sin problemas.

Enviado desde mi X16 mediante Tapatalk
Hola Juan , que maquina es esa .

JuanTrillo
17/03/2016, 22:24
Código c para sacar los datos ASCII nmea.

Enviado desde mi X16 mediante Tapatalk

rortega
17/03/2016, 22:29
2+2=4 así de simple, el Traker va bien en simulación, y hace todos los cálculos bien, repito ¿por que con la Trama del GPS no se la traga y se atraganta, pues por que tiene algo diferente, SI o SI.

Yo ahora mismo tengo la cabeza echa un bombo, je je. Para saber que pasa con esas tramas necesito verlas, de otra forma no hay tu tía. Voy a ver también si con el dato altitud tenemos alguna historia, pero no creo...

Y luego miraré si en las operaciones con las que se calcula heading y tilt hay algún error que pueda provocar valores dispares.

Lo que sí os puedo decir es que con un gps local con errores de varios metros, y otro gps en el avión al que le metemos también errores por truncamiento cuando llega al tracker, lo normal es que no apunte el tracker de forma exacta cuando estamos en corta distancia.

No sé Guillesan si con el multi habías volado antes el tracker de 8 bits, y ahora al volarlo por primera vez te has percatado de esta inexactitud. Tampoco sé si Simba está teniendo otros problemas técnicos, a parte de los que pudiera tener el tracker con la versión de 32 bits. Quizás el tema de los ajustes de pid hace que no responda con la suficiente soltura y fluidez, quizás probando como se comporta con el sistema nopid hay un comportamiento distinto algo más exacto, tampoco lo sé...

Son muchas cosas las que entran en juego y por supuesto que enl firmware puede haber bugs...

Voy a ver si ceno algo, hablo con la que manda, y luego miramos estas cosas a ver ...

Guillesan
17/03/2016, 22:32
Coño que aproveche, a y saludos a tu señora aunque no no me conozco aunque sea uno de lis tíos que le tiene secuestrado a su marido jajaja

rortega
17/03/2016, 22:32
Código c para sacar los datos ASCII nmea.

Enviado desde mi X16 mediante Tapatalk

Juan, no sé que quieres decir ... Bueno lo de C y ASCII sé que es, pero no entiendo lo que nos quieres decir con esa frase...

rortega
17/03/2016, 22:37
Juan, no sé que quieres decir ... Bueno lo de C y ASCII sé que es, pero no entiendo lo que nos quieres decir con esa frase...

Me cito a mi mismo, no había leído tu mensaje anterior.

Gracias por el ofrecimiento JuanTrillo, pero no hay ningún problema en el análisis de datos NEMA, máquinas de estado para decodificarlas las tengo ya implementada en C, tanto en el tracker como en mi ordenador. Y ello con que me pasen las tramas hay de sobra.

El problema no lo tenemos por ahí, el problema debe andar por otro sitio, eso lo hace bien, con errores, que asumimos, pero tiene que ser otro el problema.

Gracias.

JuanTrillo
17/03/2016, 22:44
Me cito a mi mismo, no había leído tu mensaje anterior.

Gracias por el ofrecimiento JuanTrillo, pero no hay ningún problema en el análisis de datos NEMA, máquinas de estado para decodificarlas las tengo ya implementada en C, tanto en el tracker como en mi ordenador. Y ello con que me pasen las tramas hay de sobra.

El problema no lo tenemos por ahí, el problema debe andar por otro sitio, eso lo hace bien, con errores, que asumimos, pero tiene que ser otro el problema.

Gracias.

Ok. Pensé que podia ser eso porque al principio nos paso algo parecido cuando pasabamos de tramas simuladas a gps reales, que hay muchos y muy variopintos. No todos sacan una trama normalizada.

Saludos
JuanTrillo

rortega
17/03/2016, 23:00
Ok. Pensé que podia ser eso porque al principio nos paso algo parecido cuando pasabamos de tramas simuladas a gps reales, que hay muchos y muy variopintos. No todos sacan una trama normalizada.

Saludos
JuanTrillo

Eso en principio puede descartarse, pues se supone que están usando los mismos dispositivos que usan cuando vuelan con 8 bits (o eso espero)...

Pero sí, también lo he visto, tramas NMEA que no cumplen con el número de decimales, o relleno de ceros por la izquierda.

Lo mismo hasta nos estamos haciendo otra vez la p... un lío como hace varios días...son muchos días y muchas horas, y muchas vuelta al tracker...

Yo, al menos, no he notado diferencia en las mismas condiciones de uso entre uno y otro, salvo en el ajuste de los puntos centrales de los servos y los PID. Por lo demás las respuestas me parecen parecidas.

Hasta que no me vaya al campo y lo compruebe no puedo dar por cierto ni lo uno ni lo contrario.

rortega
17/03/2016, 23:04
Los que tenéis la librería TinyGPS 1.2 ¿Alguno me la puede pasar? Necesito comparar la función que calcula el heading, a ver si ha cambiado algo entre una versión y otro.

Guillesan
17/03/2016, 23:09
No la tengo no

carabin
17/03/2016, 23:48
Raúl yo no sé muy bien la que tengo porque no pone nada la carpeta de versión , pero creo que aquí la puedes descargar .

https://www.pjrc.com/teensy/td_libs_TinyGPS.html

rortega
17/03/2016, 23:52
Raúl yo no sé muy bien la que tengo porque no pone nada la carpeta de versión , pero creo que aquí la puedes descargar .

https://www.pjrc.com/teensy/td_libs_TinyGPS.html

Gracias, esa es...

Simba
17/03/2016, 23:54
Por si sirve de ayuda, he tomado la posición con el mismo GPS, situado en el mismo sitio exacto, o sea en la ventana donde me encuentro, con una diferencia de minutos entre una toma y la otra.

En una captura se ven los datos pasados por el Orange y sacados del Tx.

En la otra captura son los datos directos tomados del GPS.

rortega
18/03/2016, 00:11
Por si sirve de ayuda, he tomado la posición con el mismo GPS, situado en el mismo sitio exacto, o sea en la ventana donde me encuentro, con una diferencia de minutos entre una toma y la otra.

En una captura se ven los datos pasados por el Orange y sacados del Tx.

En la otra captura son los datos directos tomados del GPS.

Y no podías copiar y pegar, o exportar las tramas para analizarlas???

rortega
18/03/2016, 00:13
Por si sirve de ayuda, he tomado la posición con el mismo GPS, situado en el mismo sitio exacto, o sea en la ventana donde me encuentro, con una diferencia de minutos entre una toma y la otra.

En una captura se ven los datos pasados por el Orange y sacados del Tx.

En la otra captura son los datos directos tomados del GPS.

En la altitud hay unos poquitos de metros de diferencia, del horde de ciento y pico.

Simba
18/03/2016, 00:13
No se como se maneja el U-Center para guardar tramas, si no ya las hubiara mandado via Dropvox

Simba
18/03/2016, 00:16
Estaba intentando generar tramas con el simulador en un PC, y recibirlas en el U-Center en otro PC, para ver como son realmente las Tramas del Simulador.

Pero es un cacao maravillao, estoy en ello.

rortega
18/03/2016, 00:17
Cuá de las dos capturas es con el orange, la de las 21:36 o la de las 21:45?

Simba
18/03/2016, 00:22
Lo pone en la parte de abajo a la izquierda de la captura.

Simba
18/03/2016, 00:30
Estaba intentando generar tramas con el simulador en un PC, y recibirlas en el U-Center en otro PC, para ver como son realmente las Tramas del Simulador.

Pero es un cacao maravillao, estoy en ello.

Nada no puedo, me falta un fdti, a ver si alguno puede hacerlo.

rortega
18/03/2016, 00:31
He metido a mano la primera de la captura con orange no da error.

El orange ahí no hace nada, es completamente transparente, es un mero medio físico por el que circula la información, no hace ninguna modificación en los datos.

Lo mismo hoy no era un buen día para andar haciendo pruebas con señal de satélites...

rortega
18/03/2016, 00:32
He metido a mano la primera de la captura con orange no da error.

El orange ahí no hace nada, es completamente transparente, es un mero medio físico por el que circula la información, no hace ninguna modificación en los datos.

Lo mismo hoy no era un buen día para andar haciendo pruebas con señal de satélites...

Yo he tenido aquí días nefastos en los que era imposible conseguir una señal estable... Me venía del campo amargado por no haber podido hacer ni gps hold con el ZMR.

Guillesan
18/03/2016, 00:38
Mañana voy a hacer una captura real tambien pero de esta forma:
pondre la antena en el centro de un circulo imaginario y me desplazare alrededor de ella con una camara grabando hacia ella asi podremos tener captura real, y la confirmacion del posible retraso, ire ampliando la distancia de giro con respecto a ella para ver como se comporta realmente, que os parece.

rortega
18/03/2016, 00:41
Mañana voy a hacer una captura real tambien pero de esta forma:
pondre la antena en el centro de un circulo imaginario y me desplazare alrededor de ella con una camara grabando hacia ella asi podremos tener captura real, y la confirmacion del posible retraso, ire ampliando la distancia de giro con respecto a ella para ver como se comporta realmente, que os parece.

¿Y si pones en el tracker la cámara? Así hice yo la prueba en su día...

Guillesan
18/03/2016, 00:43
También , una cámara subjetiva. Me será más difícil mecánicamente pero lo intentare

Simba
18/03/2016, 00:48
Raul estoy tomando Tramas igual que antes pero guardando en un fichero que pondré en mi Dropvox.

rortega
18/03/2016, 01:00
Raul estoy tomando Tramas igual que antes pero guardando en un fichero que pondré en mi Dropvox.

Perfecto

Simba
18/03/2016, 01:09
https://www.dropbox.com/s/4w5gyy4ntvpqp76/Orange%20Tx.ubx?dl=0

https://www.dropbox.com/s/9lgb4qwpqnfwmja/GPS%20DIRECTO.ubx?dl=0

Simba
18/03/2016, 01:10
No se como las vas a manejar, pero con el U-Center se abren y se ven tal cual las tome.

rortega
18/03/2016, 01:12
Lo abro como archivo de texto sin problema.

rortega
18/03/2016, 01:16
No se como las vas a manejar, pero con el U-Center se abren y se ven tal cual las tome.

Tú estabas en el Oeste ¿No?

Guillesan
18/03/2016, 01:17
Simba en esos dos ficheros hay momentos en el que las tramas estan mal, no se la razon pero se ven corrompidas.

rortega
18/03/2016, 01:20
Efectivamente, hay muchas tramas malas.

rortega
18/03/2016, 01:21
Bueno, no sé si son tramas malas, el caso es que entre tramas y tramas hay informaicón que no es NMEA.

Guillesan
18/03/2016, 01:21
Simba la captura es con el gps estatico?

Simba
18/03/2016, 01:24
Si estoy al oeste.
Si el gps esta estático.

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
18/03/2016, 01:25
pues hay momentos como decia que las tramas estan corrompidas el por que no lo se.

Simba
18/03/2016, 01:26
Es lo que sale uno es directo y el otro pasa por el Orange.

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
18/03/2016, 01:27
Vale

rortega
18/03/2016, 01:31
No son errores, es información que añade el u-center, pues el archivo es un archivo en formato u-center.

Lo que si veo es tramas sin datos, imagino que por pérdida de fix, o algún reinicio del receptor, etc...

rortega
18/03/2016, 01:35
Simba has estado siemrpe en el mismo punto o te has movido durante la captura?

Simba
18/03/2016, 01:40
En el mismo punto.
Pero ten en cuenta que es una ventana de mi casa y las 2 tomas están en el mismo sitio

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
18/03/2016, 01:48
En el mismo punto.
Pero ten en cuenta que es una ventana de mi casa y las 2 tomas están en el mismo sitio

Enviado desde mi GT-I9505 mediante Tapatalk

Bueno, las tramas son buenas, unas veces con más satélites, otras con menos, hay pérdida de fix a veces ...

Tomando como home la primera trama que de fix, se producen oscilaciones de entre 2 a 10 metros, e alguna vez incluso a 20 y pico metros de distancia...

Yo lo veo normal, en el sentido de que no estás en un espacio completamente abierto. Más o menos el mismo comportamiento que en mis multis en mi casa de España, cuando hago pruebas junto a una ventana, veo como oscilan a veces entre 20 pico metros. Aquí en Zurich me pasa igual, pegado a la ventana, unas veces tengo 5 sats, otras 6, otras 8 ... y la posición oscila...

Si esa oscilación sucede un día de mala recepción en el campo, y además añadimos el error por comernos un decimal, pues es normal que no haya mucha precisión en las cercanías.

Podríamos jugar con lo de la precisión, pero tengo mis dudas de que

rortega
18/03/2016, 01:51
Podríamos jugar con lo de la precisión, pero tengo mis dudas de que

...eso supongam un gran problema.

Yo creo que si hoy salis al campo con el de 8 bits experimentáis la misma sensación de comportamiento lento o herrático...

rortega
18/03/2016, 01:55
Tomé como home una de las primeras tramas que tenían fix en uno de los archivos, y he ido tomando al azar tramas de un archivo primero, y del otro después, sin importarme si era directo o ornage. Y ahí está el cálculo de heading y distancia que hace el tracker entre trama y trama...

(el heading hay que dividirlo por 10, ejemplo 2751 son 275 grados).

Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22890
heading: 2751 dis: 7
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22890
heading: 2751 dis: 7
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22890
heading: 2751 dis: 7
Tr lat: 3966894 lon: -22881
Av lat: 3966897 lon: -22891
heading: 2867 dis: 9
Tr lat: 3966894 lon: -22881
Av lat: 3966899 lon: -22895
heading: 2938 dis: 13
Tr lat: 3966894 lon: -22881
Av lat: 3966901 lon: -22873
heading: 420 dis: 10
Tr lat: 3966894 lon: -22881
Av lat: 3966902 lon: -22854
heading: 694 dis: 24
Tr lat: 3966894 lon: -22881
Av lat: 3966893 lon: -22887
heading: 2525 dis: 5
Tr lat: 3966894 lon: -22881
Av lat: 3966894 lon: -22881
heading: 0 dis: 5
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22886
heading: 2791 dis: 4
Tr lat: 3966894 lon: -22881
Av lat: 3966896 lon: -22886
heading: 2943 dis: 4
Tr lat: 3966894 lon: -22881
Av lat: 3966890 lon: -22886
heading: 2207 dis: 6
Tr lat: 3966894 lon: -22881
Av lat: 3966890 lon: -22887
heading: 2259 dis: 7
Tr lat: 3966894 lon: -22881
Av lat: 3966892 lon: -22887
heading: 2425 dis: 5
Tr lat: 3966894 lon: -22881
Av lat: 3966893 lon: -22888
heading: 2549 dis: 6
Tr lat: 3966894 lon: -22881
Av lat: 3966894 lon: -22889
heading: 2704 dis: 6
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22890
heading: 2751 dis: 7
Tr lat: 3966894 lon: -22881
Av lat: 3966896 lon: -22890
heading: 2840 dis: 8
Tr lat: 3966894 lon: -22881
Av lat: 3966896 lon: -22890
heading: 2840 dis: 8
Tr lat: 3966894 lon: -22881
Av lat: 3966896 lon: -22891
heading: 2827 dis: 8
Tr lat: 3966894 lon: -22881
Av lat: 3966897 lon: -22891
heading: 2867 dis: 9
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22884
heading: 2850 dis: 2
Tr lat: 3966894 lon: -22881
Av lat: 3966899 lon: -22881
heading: 0 dis: 5

rortega
18/03/2016, 01:56
Tr lat: 3966894 lon: -22881
Av lat: 3966895 lon: -22890
heading: 2751 dis: 7

equivale a

Tracker lat: 39.66894 lon: -0.22881
Avión lat: 39.66895 lon: -0.22890
heading: 275 distancia: 7

Guillesan
18/03/2016, 01:57
Y como lo ves

rortega
18/03/2016, 02:05
Y como lo ves

Eso es una salida por consola que le he metido al firmware para comprobar las tramas.

Lo he preparado de modo que cargo el firm, sin meter paráemtro alguno hago un feature debug y feature -gps (para evitar el gps local) y salvo.

Le meto con la ayuda del monitor serie de Arduino una primera trama y acto seguido pulso el botón home, y luego voy metiendo tramas una a una para que me vaya sacando heading y distancia.

rortega
18/03/2016, 02:08
En la imagen que he puesto antes se ve como una posición está en un edificio y la otra al otro lado del de enfrente, la de 24 metros de distancia.

Ya esta noche no porque estoy muerto, pero mañana haré una comparación entre la direrencia que hay quitando el decimal o dejándolo tal cual, usando para ello esas tramas que me ha pasado Simba.

Así tendremos una idea de cuanto error estamos asumiendo...

Guillesan
18/03/2016, 02:10
Yo también empiezo a tener la cabeza como tú dices un bombo.
Mañana pretendo racionalizar las pruebas,con el máximo sentido que sea capaz jajaja. Con el 8 bits no volé nunca un multi y ahora con este 32 no sé si estamos centrados o no.
Insisto y perdona con mavlink no puedo hacer home sin GPS local la ñapa para el MyFlyDream que me hiciste no funciona,no manda número satélites y era por hacer la prueba también con otro protocolo y ver si se comporta igual o no

Guillesan
18/03/2016, 02:11
Ya mañana veremos de solucionar

Simba
18/03/2016, 02:13
De lo que estoy seguro y no es por contradecir, es que no funcionan ni parecido, el 8 bits con el 32 bits.
Lo hemos comentado hasta la saciedad Turruk y yo.

Guillesan yo he volado un monto de veces el Micro250, a toda leche y corre mas que muchos aviones, pasando muy cerca del traker y moviendome relativamente cerca, y el Traker lo sigue bastante bien.
Y si el vuelo es tipo parote, (libélula) como los Quads +- grandes, a 20m si pongo un fusil en el Traker me lo cargo, otra cosa es que valla a todo leche.

Con esto quiero decir, que estando acostumbrado al 8 bits, este no es ya digo ni parecido, y será por alguna causa que desconocemos, pero hoy por hoy no son comparables.

rortega
18/03/2016, 02:15
Insisto y perdona con mavlink no puedo hacer home sin GPS local la ñapa para el MyFlyDream que me hiciste no funciona,no manda número satélites y era por hacer la prueba también con otro protocolo y ver si se comporta igual o no

Esa ñapa la hice para la telemetría de salida, para visualizar la información en Droidplanner y Mission planer.

Si las tramas mavlink no mandan satélites, para el seguimiento mal vamos. Lo único que se me ocure es meter un parámetro de configuración para que se superponga ese valor al del número de satélites y así la aplicación pueda iniciar el seguimiento con lo que le llegue.

Guillesan
18/03/2016, 02:15
Pues di Simba algo debe haber, veremos cómo solucionamos entre todos

Guillesan
18/03/2016, 02:16
Esa ñapa la hice para la telemetría de salida, para visualizar la información en Droidplanner y Mission planer.

Si las tramas mavlink no mandan satélites, para el seguimiento mal vamos. Lo único que se me ocure es meter un parámetro de configuración para que se superponga ese valor al del número de satélites y así la aplicación pueda iniciar el seguimiento con lo que le llegue.


A cierto era para la salida, no me acordaba, pues nada tranquilo déjalo estar.

rortega
18/03/2016, 02:18
De lo que estoy seguro y no es por contradecir, es que no funcionan ni parecido, el 8 bits con el 32 bits.
Lo hemos comentado hasta la saciedad Turruk y yo.

Guillesan yo he volado un monto de veces el Micro250, a toda leche y corre mas que muchos aviones, pasando muy cerca del traker y moviendome relativamente cerca, y el Traker lo sigue bastante bien.
Y si el vuelo es tipo parote, (libélula) como los Quads +- grandes, a 20m si pongo un fusil en el Traker me lo cargo, otra cosa es que valla a todo leche.

Con esto quiero decir, que estando acostumbrado al 8 bits, este no es ya digo ni parecido, y será por alguna causa que desconocemos, pero hoy por hoy no son comparables.

Yo sólo sé que le entra por telemetría lo interpreta.
Una prueba que haré mañana, o este finde, es meterle a la crius la telemetría directa gps, las mismas tramas que me estás pasando, y sacar los valores de heading y distancia para ver si coinciden.

Si en eso están igual 8bits y 32bits, entonces buscaremos el problema por otro sitio.

Guillesan
18/03/2016, 02:18
Bien

Simba
18/03/2016, 02:21
OK, venga que menuda tarde llevamos.
Buenas noches.

Guillesan
18/03/2016, 02:22
Ok buenas noches a todos

rortega
18/03/2016, 02:25
Buenas noches...

rortega
18/03/2016, 02:41
Desactivad para las pruebas la telemetría de salida:

feature -telemetry

y

feature -softserial

Para descartar que esté consumiendo demasiado tiempo.

Guillesan
18/03/2016, 02:42
Vale

macgver
18/03/2016, 03:54
Los que tenéis la librería TinyGPS 1.2 ¿Alguno me la puede pasar? Necesito comparar la función que calcula el heading, a ver si ha cambiado algo entre una versión y otro.

need arduino GPS 1.2 library ?

file in :https://drive.google.com/file/d/0BxodPu6xkBd_RGlBcGJNNFVEOUE/view?usp=sharing

rortega
18/03/2016, 08:36
need arduino GPS 1.2 library ?

file in :https://drive.google.com/file/d/0BxodPu6xkBd_RGlBcGJNNFVEOUE/view?usp=sharing
Thanks macgver.

rortega
18/03/2016, 08:46
Chicos, sobre el tema de las pruebas, sería interesante si no es mucho lío, pruebas con protocolo MFD.

Con MFD los datos de distancia, ángulo y altitud nos llegan calculados, y las tramas son súper cortas. Ésto nos podría ayudar a descartar si es un bug en el código, o si son errores de precisión truncamiento, y poner el foco en otras posibles fuentes del problema.

La idea sería hacer una prueba GPS Telemetry y otra MFD con el mismo avión o multi. Lo único que cambiaría es el protocolo de telemetría, pero el resto sería lo mismo todo.

Simba
18/03/2016, 08:49
Hola hay una cosa que ayer no pude hacer, por no disponer de 2 ftdi, y es el ver realmente que es lo que le metemos, con el simulador.
Ver y comparar la trama que le llega del simulador, con la que le llega del gps o y del gps a través del Orange, que a falta de más análisis, a priori parece que son realmente iguales.
No sabemos que narices le manda el simulador.


Enviado desde mi GT-I9505 mediante Tapatalk

rortega
18/03/2016, 08:49
Si en ambos casos se comportase igual, entonces nos dedicaríamos a investigar en la parte del código que envía las órdenes al servo.

rortega
18/03/2016, 08:53
Si en ambos casos se comportase igual, entonces nos dedicaríamos a investigar en la parte del código que envía las órdenes al servo.
Me refería a lo de los protocolos y no a tú respuesta Simba.

Yo creo que las tramas NMEA no son problema, lo que pasa con el simulador es que no vemos al aparato volando y no apreciamos por tanto un desfase o retraso.

rortega
18/03/2016, 08:55
Hola hay una cosa que ayer no pude hacer, por no disponer de 2 ftdi, y es el ver realmente que es lo que le metemos, con el simulador.
Ver y comparar la trama que le llega del simulador, con la que le llega del gps o y del gps a través del Orange, que a falta de más análisis, a priori parece que son realmente iguales.
No sabemos que narices le manda el simulador.


Enviado desde mi GT-I9505 mediante Tapatalk
Esto se puede hacer con el blueterm en el móvil, se captura un log y luego se pasa al ordenador.

Yo lo puedo hacer hoy en el curro en un momento.

rortega
18/03/2016, 09:34
Ahí tenéis la captura del simulador:

https://github.com/raul-ortega/amv-open360tracker-32bits/blob/master/docs/NMEA-GGA-RMC.log

rortega
18/03/2016, 09:38
Y aquí se pueden verificar las tramas:

http://rl.se/gprmc

Existe una pequeña diferecia con respecto a las tramas que pasaste ayer, y es el penúltimo campo. Pero nosotros no hacemos nada con ese dato, lo único que hacemos es calcular el CRC (la suma para control de errores) y verificar que la trama es correcta y no contiene errores debido a las comunicaciones.

Simba
18/03/2016, 17:11
Y aquí se pueden verificar las tramas:

http://rl.se/gprmc

Existe una pequeña diferecia con respecto a las tramas que pasaste ayer, y es el penúltimo campo. Pero nosotros no hacemos nada con ese dato, lo único que hacemos es calcular el CRC (la suma para control de errores) y verificar que la trama es correcta y no contiene errores debido a las comunicaciones.

Y digo yo desde mi total ignorancia, no sera por eso que se hace, con las tramas del GPS/Orange, que no se hace por que no está, en la trama del simulador.
Entiendo que en la Trama del simulador, no esta ese dato y por lo tanto no lo puede tratar, y en cambio cuando le llega en el caso del vuelo real, si que lo trata., y el resultado sea la gran diferencia entre simulador y vuelo real.

Solo son conjeturas de neofito.

P.D. : Este finde estera un poco mas calladito que tenemos Fallas por Valencia.

sl2

Guillesan
18/03/2016, 17:58
Houy dia de pruebas, estoy recopilando la informacion.
Vaya por delante una captura de gps-telemetry directa desde la recepcion.

GPS-multi-campo
https://www.dropbox.com/sh/uh3mt60fxmpnjmo/AACg0SnJha4YE_JLOLf3KlkKa?dl=0

rortega
18/03/2016, 17:59
Y digo yo desde mi total ignorancia, no sera por eso que se hace, con las tramas del GPS/Orange, que no se hace por que no está, en la trama del simulador.
Entiendo que en la Trama del simulador, no esta ese dato y por lo tanto no lo puede tratar, y en cambio cuando le llega en el caso del vuelo real, si que lo trata., y el resultado sea la gran diferencia entre simulador y vuelo real.

Solo son conjeturas de neofito.

P.D. : Este finde estera un poco mas calladito que tenemos Fallas por Valencia.

sl2

No Simba, eso no es problema, de hecho ya viste ayer que te puse los valores que devuelve el tracker de posición y cálculo de distancia tras haber recibido tus tramas. Si hubiese problemas con esas tramas no habría devuelto nada ni habría hecho cálculos. Sólo influye el campo en el cálculo del CRC, pero está bien calculado en todas, las que tienen el dato y las que no lo tienen. Puedes probar las tramas en esa página que puse para que veas que no da errores.

Qué disfrutes las fiestas, buen finde!!!

rortega
18/03/2016, 18:06
Houy dia de pruebas, estoy recopilando la informacion.
Vaya por delante una captura de gps-telemetry directa desde la recepcion.

GPS-multi-campo
https://www.dropbox.com/sh/uh3mt60fxmpnjmo/AACg0SnJha4YE_JLOLf3KlkKa?dl=0
Ya los tengo, entre esta tarde y esta noche los miro.

A la espera de que nos comentes tus impresiones ...

Guillesan
18/03/2016, 18:13
Hola en terminos generales dire que la antena se comporta de muy diferente manera segun el protocolo usado.
Tengo 5 videos con su explicacion y procedimiento para que podais tomar conciencia.
Pero adelanto que como mejor se comporta es con telemetria por video MFD y aventuro que igual es asi por que en dicha telemetria no se envian datos gps por lo que no tiene que decodificar, es una teoria.
Tambien decir que en distancia corta y gps-telemety el tilt ni actua , no se por que no le pillo el tranquillo eso sera el maestro Raul quien debe decir.
Pongo aqui los links y vamos comentando, estan sin editar por aligerar, perdonar si en algun momento se hace pesado verlos.

https://www.youtube.com/watch?v=MQmbOO2Yuu4
https://www.youtube.com/watch?v=vnOi2zFAiHY
https://www.youtube.com/watch?v=b2TTi9-MHF0
https://www.youtube.com/watch?v=WbhiG9EyS8M
https://www.youtube.com/watch?v=Voxw8pxIpow

rortega
18/03/2016, 18:48
Sólo he visto de momento el primero. Ahí tenemos posiblemente errores por truncamiento, y posiblemente se sume el error de +- x grados del heading tras aplicar PIDs.

Muy ilustrativo, sí señor.

rortega
18/03/2016, 18:52
Está claro que la suma de errores de un gps en el multi y otro en el tracker haga que se vea peor resultado en el segundo vídeo.

Guillesan
18/03/2016, 18:55
Y sobre todo el tilt Raúl, te diré que en todas las pruebas con multi y gpstelemetry no sé a movido y eso que he subido de tirón ponle 40-50 metros

rortega
18/03/2016, 18:58
Ostia que mal el tercero ... Ahí hay algo, se tiene que estar perdiendo datos o metiendo errores...

Guillesan
18/03/2016, 18:59
Como os decia con MFD-video la cosa cambia sustancialmente.

rortega
18/03/2016, 19:00
El primero con el multi, no veo el multi, es lógico no verlo después de saber que tenemos unos errores grandes en las cercanías

Guillesan
18/03/2016, 19:00
Como vrreis hay momentos que la antena se queda quieta, como pensando.......no se sabe si por que nole llega o por que hay un tapon en algun sitio, a y es una mera apreciacion no se si bien fundada por que la cosa a izquierdas va mejor que a derechas, me explico

Guillesan
18/03/2016, 19:01
El primero con el multi, no veo el multi, es lógico no verlo después de saber que tenemos unos errores grandes en las cercanías
No lo ves por que por poco o mucho que suba el tilt ni se inmuta.

rortega
18/03/2016, 19:11
Bueno, ante todo gracias por la paciencia y el esfuerzo. Muy ilustrativo, está claro que en MFD va mejor, y tiene su lógica, pero posiblemente haya algo más que se nos escapa... Habrá que echarle paciencia y meter horas para averiguar por qué no se comporta como el de 8 bits.

Guillesan, sería bueno que me pasases la configuración de los parámetros para ver como los llevabas y así tener más datos con los que trabajar.

Guillesan
18/03/2016, 19:12
Tú quieres el "set"

rortega
18/03/2016, 19:13
Tú quieres el "set"
set y feature

Guillesan
18/03/2016, 19:15
A si te lo paso en un ratito, por cierto tal como pedías le desebilitado softserial y telemetry

rortega
18/03/2016, 19:20
Como vrreis hay momentos que la antena se queda quieta, como pensando.......no se sabe si por que nole llega o por que hay un tapon en algun sitio, a y es una mera apreciacion no se si bien fundada por que la cosa a izquierdas va mejor que a derechas, me explico
Eso podría ser por la suma de errores de los dos GPS. Varias posiciones al truncarse los decimales se pueden quedar en la misma posición.

El ir retrasado también puede deberse en parte a eso, pero sólo en parte. Habrá un poco de pids, y quizás algo más.

Los movimientos erráticos que comenta el compañero podría estar relacionados con perdida de datos, bien tramas que no se terminan de recibir completas y provoquen un dato erróneo.

La situación perfecta de funcionamiento la tenemos con el simulador, sabemos que funcionar funciona y bien en esas condiciones perfectas, ahora toca averiguar por qué en situación real comete esos errores.

Guillesan
18/03/2016, 19:23
Siendo otra telemetria te digo que con mavlink la cosa cambia. El seguimiento es más consistente y digo por que , mejor velocidad 57600, mejor refresco , no lo sé pero fijo que es más de 4hz .

rortega
18/03/2016, 19:26
Siendo otra telemetria te digo que con mavlink la cosa cambia. El seguimiento es más consistente y digo por que , mejor velocidad 57600, mejor refresco , no lo sé pero fijo que es más de 4hz .
Hombre, todo influye.

A ver cómo ideo la forma de grabar un log con toda la Info que maneja y calcula el tracker en situación real, para poder sacar algo en claro de los datos.

Es la única forma de ver la diferencia entre lo que ordena a los servos y lo que debería ser.

Guillesan
18/03/2016, 19:27
Ok yo estoy aquí para las pruebas de campo, y digo yo , un debug hacia el pc saliendo por bluetooh?

rortega
18/03/2016, 19:34
Hay algo que se me viene a la mente después del comentario de los 57600, y es que en el código fuente de cleanflight, para no me acuerdo que asunto, la opción de 4800 baudios no estaba dentro de los valores posibles, y yo tuve que añadirlo. No había información alguna de por qué se omitía, si era un simple error del programador que se olvidó, o si respondía a que con las longitudes de trama que manejaban no aguantaba esos baudios. No quiero decir nada con ésto, pero no estaría mal probar la telemetría a 9600 por si acaso.

Sé que Simba va a decir que no, pero es sólo con el fin de descartar cosas.

Guillesan
18/03/2016, 19:37
Sí señor lo que usted diga paso a 9600 pero hay que curárselo ,cambiar un montón de configuraciones o,,,,,,,
En mi caso el ,,Crossfire permite telemetria ,(bridge) a 57600 ósea transparente así que con tiempo cambio a eso y pruebo

rortega
18/03/2016, 19:37
Ok yo estoy aquí para las pruebas de campo, y digo yo , un debug hacia el pc saliendo por bluetooh?
Sí, a algo así, combinado. Y a la vez una captura de lo que entra antes de que el tracker lo procese.

Para todo eso necesito yo también hacer las pruebas pertinentes.

Guillesan
18/03/2016, 19:40
OK pues ya diras.

rortega
18/03/2016, 19:40
No he visto aún la captura nmea que has hecho. Sabrías decirme de memoria que números de satélites manejabas, RS sólo por hacerme una idea de como de buena era la señal.

Guillesan
18/03/2016, 19:41
No he visto aún la captura nmea que has hecho. Sabrías decirme de memoria que números de satélites manejabas, RS sólo por hacerme una idea de como de buena era la señal.
8 satelites minimo

rortega
18/03/2016, 20:17
Una prueba que sería interesante hacer:



Desactivar GPS
Desactivar Display
Desactivar Telemetría de salida
Desactivar Softserial
Desactivar Easing
Usar GPS_Telemetry y MFD
Baudios: 4800 y 9600

La idea es quitar todo aquello que consuma tiempo de ejecución, para centrar la prueba únicamente en la lectura de la telemetría y en las órdenes.

Voy a preparar un modo debug (feature debug), que haga lo siguiente:


contar las tramas que llegan
contar los errores de CRC (tramas erróneas)
contar las tramas procesadas como buenas
anotar latitud, longitud y altitud de la trama buenas
anotar latitud, longitud y altitud tras truncamiento
anotar heading y distancia calculados
anotar heading alcanzado.
anotar ángulo de tilt calculado.
anotar pulso de pan y pulso de tilt calculados
milisegundos transcurridos desde que se recibe la trama hasta que se envía el pulso para el movimiento.

Todo ésto lo sacaremos por la uart2 a 57600 baudios, en lugar de por un softserial, pues consume mucho tiempo de proceso.


El tema pendiente que tengo del botón home lo voy a posponer, interesa hacer primero que el tracker haga bien su principal función, y las pijadas las arreglaremos después.

Guillesan
18/03/2016, 20:18
Sí señor venga , a tu aire prepara que yo le doy caña

Simba
18/03/2016, 20:56
Hay algo que se me viene a la mente después del comentario de los 57600, y es que en el código fuente de cleanflight, para no me acuerdo que asunto, la opción de 4800 baudios no estaba dentro de los valores posibles, y yo tuve que añadirlo. No había información alguna de por qué se omitía, si era un simple error del programador que se olvidó, o si respondía a que con las longitudes de trama que manejaban no aguantaba esos baudios. No quiero decir nada con ésto, pero no estaría mal probar la telemetría a 9600 por si acaso.

Sé que Simba va a decir que no, pero es sólo con el fin de descartar cosas.
No, no voy a decir que no, si no todo lo contrario, no me extrañaría nada que ese fuera el principal problema.

Lo malo es que el Orange no puede con el 9600.

De todas formas esto es muyyy extraño, el tema de que no pueda el 32 bits, procesar tramas lentas del tipo 4800, quiero pensar que habrá otro modo de procesarlas, y si una a una le resultan lentas, se podrá programar para que lea varias tramas al mismo tiempo.

Pero si que puede que si no se ha tenido en cuanta, se produzca perdida de datos por falta de sincronismo, y por esa razón el 8 bits no tiene problemas.

Pero me queda una ultima duda, que no le veo explicación razonable, y es el porque las tramas del simulador, que son exactamente igual menos el dato de cheksum, y según tu no tiene importancia, por que el simulador siendo las mismas tramas, funciona perfecto.

Simba
18/03/2016, 21:06
Guillesan, es interesante ver si cuando se tiene el Traker, retrasado xxº de angulo, en el Oled el error es 0 o tiene un angulo de error xxº.

En caso de que el error exista, y el traker no mueve para corregir, lo mas probable es que te falte ajustar, con algo de mas ganancia el PID, o concretamente aumentar un poco la I, para que aumente en el entorno de 0 error la ganancia y corrija, y también es importante ademas aumentar en lo posible pero muy poco a poco el min_pan_speed.

Sl2.

rortega
18/03/2016, 21:07
No, no voy a decir que no, si no todo lo contrario, no me extrañaría nada que ese fuera el principal problema.

Lo malo es que el Orange no puede con el 9600.

De todas formas esto es muyyy extraño, el tema de que no pueda el 32 bits, procesar tramas lentas del tipo 4800, quiero pensar que habrá otro modo de procesarlas, y si una a una le resultan lentas, se podrá programar para que lea varias tramas al mismo tiempo.

Pero si que puede que si no se ha tenido en cuanta, se produzca perdida de datos por falta de sincronismo, y por esa razón el 8 bits no tiene problemas.

Pero me queda una ultima duda, que no le veo explicación razonable, y es el porque las tramas del simulador, que son exactamente igual menos el dato de cheksum, y según tu no tiene importancia, por que el simulador siendo las mismas tramas, funciona perfecto.

Simba, lo del dato ese no es el CRC.

El CRC es el que está justo al final, después del asterisco. Eso es una suma de comprobación, en la que se suma el valor ascii de todos los simbolos entre la $ y el * (la $ y el * no se contabilizan). Pues bien, lo que yo quería decir, es que aunque en las tramas faltaba un campo (se ve que hay dos comas seguidas sin dato entre ellas), la suma total, el CRC, es correcto. Y como ese dato que falta no lo usamos para nada, pues no no pasa nada, porque lo importante es que todos los demás datos que usamos sean buenos. Sabemos que son bueno si cuando calculamos el CRC en el tracker, el valor coincide con el CRC que se envía en la trama.

No le des más vuelta a ese tema que no van los tiros por ahí.

E insisto, si en el simulador va bien, quiere decir que el tracker hace bien las cuentas. Otra cosa distinta es que las haga lento, o le entren tramas con mal resultado al calcular el CRC (bien por errores en las comunicaciones o yo que sé) y por tanto no haga cuentas suficiente, o que al procesar los datos de latitud y longitud, por truncarlos, estemos teniendo muchos errores, o una suma de todas esas cosas a la vez.

No podemos decir que con el simulador lo hace perfecto, porque no tenemos una cámara apuntando al objeto virtual que vuela como ha hecho Guillesan hoy...

Guillesan
18/03/2016, 21:07
Pues será a revisar pero en casa eso si no me equivoco ya está casi todo revisado

Guillesan
18/03/2016, 21:09
Voy a ir concretando todos los pasos, pruebas y más pruebas jajaja como me divierto joer

rortega
18/03/2016, 21:25
Simba, lo del dato ese no es el CRC.

El CRC es el que está justo al final, después del asterisco. Eso es una suma de comprobación, en la que se suma el valor ascii de todos los simbolos entre la $ y el * (la $ y el * no se contabilizan). Pues bien, lo que yo quería decir, es que aunque en las tramas faltaba un campo (se ve que hay dos comas seguidas sin dato entre ellas), la suma total, el CRC, es correcto. Y como ese dato que falta no lo usamos para nada, pues no no pasa nada, porque lo importante es que todos los demás datos que usamos sean buenos. Sabemos que son bueno si cuando calculamos el CRC en el tracker, el valor coincide con el CRC que se envía en la trama.

No le des más vuelta a ese tema que no van los tiros por ahí.

E insisto, si en el simulador va bien, quiere decir que el tracker hace bien las cuentas. Otra cosa distinta es que las haga lento, o le entren tramas con mal resultado al calcular el CRC (bien por errores en las comunicaciones o yo que sé) y por tanto no haga cuentas suficiente, o que al procesar los datos de latitud y longitud, por truncarlos, estemos teniendo muchos errores, o una suma de todas esas cosas a la vez.

No podemos decir que con el simulador lo hace perfecto, porque no tenemos una cámara apuntando al objeto virtual que vuela como ha hecho Guillesan hoy...

A mí me gustaría ver esa misma prueba que ha hecho Guillesan, realizada por tí, porque sé que Guillesan no es tan misquindiquis como tú con el tema de los PIDs, y no me extrañaría que cuando se pasa de largo se deba a un valor de PIDs no muy bueno.

A ver si preparo el tema del log y veo con las tramas que me ha pasado si a 4800 las lee o no y si los cálculos los hace bien o no.

rortega
18/03/2016, 21:32
Simba a ver si le echas un ojo a los vídeos de Guillesan (cuando puedas claro está, que con las fiestas estará complicado) y nos das tu impresión...

rortega
18/03/2016, 21:35
Guillesan, métete en esta página y pásale el archivo de la captura NMEA directa, la de tu casa. Verás que cosa más bestia de paseo que se ha pegado el gps estando quieto en un lugar...

http://www.h-schmidt.net/NMEA/

rortega
18/03/2016, 21:36
Guillesan, métete en esta página y pásale el archivo de la captura NMEA directa, la de tu casa. Verás que cosa más bestia de paseo que se ha pegado el gps estando quieto en un lugar...

http://www.h-schmidt.net/NMEA/


Yo he puesto en las opciones 1 metro y 1 segundo, porque menos no se puede poner.

Guillesan
18/03/2016, 21:36
Si lo haré pero esa es nuestra guerra los GPSs se mueven estando quietos.

rortega
18/03/2016, 21:44
Por curiosidad, mirad las estadísticas de la captura del vuelo:

Result of your upload: Your data could be converted



331 NMEA-records could be converted
100.00 % had a GPS fix and contained usable data
1 record(s) could not be converted because the format didn't match NMEA standard
544 record(s) could not be converted because the checksum was invalid (transmission error)

Guillesan
18/03/2016, 21:44
Ahí le duele

rortega
18/03/2016, 21:45
Sin embargo, en la captura directa bluetooth:

Result of your upload: Your data could be converted



818 NMEA-records could be converted
100.00 % had a GPS fix and contained usable data
1 record(s) could not be converted because the format didn't match NMEA standard

Guillesan
18/03/2016, 21:48
Sin embargo, en la captura directa bluetooth:

Result of your upload: Your data could be converted



818 NMEA-records could be converted
100.00 % had a GPS fix and contained usable data
1 record(s) could not be converted because the format didn't match NMEA standard



La unica diferencia esta en que una era en mi casa y la otra en el campo aunque el multi que enviaba las tramas no ha estado a mas de 50 metros de distancia el openlrs no a pitado ninguna vez es decir la telemetria era buena. Solo puedo pensar que en la conexion bluetooh se joroba algo.Lo unico diferente entre las dos capturas es la distancia entre modulos bluetooh

rortega
18/03/2016, 21:52
La unica diferencia esta en que una era en mi casa y la otra en el campo aunque el multi que enviaba las tramas no ha estado a mas de 50 metros de distancia el openlrs no a pitado ninguna vez es decir la telemetria era buena. Solo puedo pensar que en la conexion bluetooh se joroba algo.Lo unico diferente entre las dos capturas es la distancia entre modulos bluetooh

¿Podría ser que cuando tu compañer se ponía delante/cerca del tracker fallase el bluetooth por hacerle sombra?

rortega
18/03/2016, 22:00
Éstas las estadísticas de mi captura con el simulador NMEA, la que subí esta mañana :

Result of your upload: Your data could be converted



80 NMEA-records could be converted
100.00 % had a GPS fix and contained usable data

No hay tramas erróneas, es la situación ideal (115200 baudios).

Simba
18/03/2016, 22:03
Si lo haré pero esa es nuestra guerra los GPSs se mueven estando quietos.
Si y por eso ya que se mueven los dos, mejor que uno se quede quieto.
No lo había dicho antes, pero no veo la necesidad de que el GPS del Traker, esté continuamente tomando datos, que es como si lo estuviéramos moviendo.
Unas vez se tiene tomado el Fix, lo mejor es que lo memorice y no lo cambie, por que eso esta introduciendo variables incontroladas.
Lejos apenas tendrá influencia, pero cerca la tiene y mucha, y la prueba de ello la tenemos clara desde el principio, y es por eso que cuando estamos a unos 15 o 20m, con el avión en el suelo y parado, el Traker no para de moverse, el que se mueve es el punto de Fix, y no uno, si no dos puntos de Fix, el del Traker y el del Avión.

Todo esto esta claro que es así desde siempre, y lo tengo asumido, pero estas son las limitaciones del sistema GPS, y no estamos hablando de estos problemas, los problemas son otros.
De todas formas lo comento, por que me da la impresión, de que estamos esperando que el Traker nos siga perfecto como un tiro, a 20m de distancia y eso es totalmente imposible, ademas que no sirve para gran cosa, aparte de quedar muy bien con la parroquia que nos sigue.

Lo importante es que el Traker mantenga, a partir de 150m un margen de angulo de error que mantenga las antenas con el lóbulo de radiación, dentro de una ganancia aceptable.

Guillesan
18/03/2016, 22:05
Éstas las estadísticas de mi captura con el simulador NMEA, la que subí esta mañana :

Result of your upload: Your data could be converted



80 NMEA-records could be converted
100.00 % had a GPS fix and contained usable data

No hay tramas erróneas, es la situación ideal (115200 baudios).

vamos cercando el tema, La distancia en casa es minima claro esta, en el campo bastante mas, pero se une que el bluetooh para openlrs son dos modulos HC-05-06 y en Mavlink el bluetooh en la emisora esta embebido en la antena sigue siendo un HC-05
Es mas esos modulos van a 2.4 ghz , pregunta Simba en tu campo habian emisores de RC a 2.4 ,
dandole al tarro , se podria probar de hacer prueba y unir TX con antena por cable pa probar !!!

Simba
18/03/2016, 22:09
La unica diferencia esta en que una era en mi casa y la otra en el campo aunque el multi que enviaba las tramas no ha estado a mas de 50 metros de distancia el openlrs no a pitado ninguna vez es decir la telemetria era buena. Solo puedo pensar que en la conexion bluetooh se joroba algo.Lo unico diferente entre las dos capturas es la distancia entre modulos bluetooh
Siento deciros que en mi caso, en mi Traker no utilizo Bluetooht, ya que el Tx Orange, está en el propio Traker y le paso directo los datos, del Tx a la entrada de la Flip32.

Guillesan
18/03/2016, 22:10
Siento deciros que en mi caso, en mi Traker no utilizo Bluetooht, ya que el Tx Orange, está en el propio Traker y le paso directo los datos, del Tx a la entrada de la Flip32.

Joder Simba coño no dejas ni un minuto de felicidad ostia, bueno miraremos otra cosa,...... JAJAJA

Simba
18/03/2016, 22:11
Es lo que hay, lo siento.

Guillesan
18/03/2016, 22:11
Aunque pienso que podemos tener varios problemas concurrentes que se hacen presentes segun y como.

TURRUK
18/03/2016, 22:17
Hola MFD de GPS trabaja a 5ghz con la velocidad de 38400 .

Guillesan
18/03/2016, 22:18
La salida del driver es a 19200

Simba
18/03/2016, 22:22
Joer es que en cuanto se encanta uno tiene que tirar para tras y releer,:biggrin2:.

Raul una cosa quería comentar, y es algo referente a como trata la Flip32 las salidas de los servos.
Resulta que en una ocasión, monte una Flip32 en un Tricoptero, y es la única ocasión, que la he podido ver moviendo un servo, en este caso el servo de control de Yaw que dirigía el motor de cola.
Bien pues me resulto chocante, la aparente mala respuesta del servo, era como si le faltara data-rate, como si lo hiciera a saltitos, y no muy lineales.

Solo fue una impresión pero me llamo la atención.

En fin solo son alucinaciones mías.

rortega
18/03/2016, 22:28
Simba, tus capturas del otro día con ublox:

DIRECTA:

Result of your upload: Your data could be converted

2494 NMEA-records could be converted
55.77 % had a GPS fix and contained usable data
2 record(s) could not be converted because the checksum was invalid (transmission error)

ORANGE

Result of your upload: Your data could be converted

2970 NMEA-records could be converted
62.79 % had a GPS fix and contained usable data
2 record(s) could not be converted because the checksum was invalid (transmission error)

Los porcentajes de tramas con Fix son bajos, pero como vés sólo hay un par de tramas con error de CRC.

TURRUK
18/03/2016, 22:30
La salida del driver es a 19200

Si el dreiver si ,pero GPS 38400.

rortega
18/03/2016, 22:32
Siento deciros que en mi caso, en mi Traker no utilizo Bluetooht, ya que el Tx Orange, está en el propio Traker y le paso directo los datos, del Tx a la entrada de la Flip32.

Simba hace falta una captura de vuelo real, o con el avión en la mano dando vueltas a cierta distancia. Sólo por ver si hay muchos errores de tramas, o lo de Guillesan es una simple excepción y debe solucionar lo de las comunicaciones tal y como lo tienes tú.

rortega
18/03/2016, 22:38
Joer es que en cuanto se encanta uno tiene que tirar para tras y releer,:biggrin2:.

Raul una cosa quería comentar, y es algo referente a como trata la Flip32 las salidas de los servos.
Resulta que en una ocasión, monte una Flip32 en un Tricoptero, y es la única ocasión, que la he podido ver moviendo un servo, en este caso el servo de control de Yaw que dirigía el motor de cola.
Bien pues me resulto chocante, la aparente mala respuesta del servo, era como si le faltara data-rate, como si lo hiciera a saltitos, y no muy lineales.

Solo fue una impresión pero me llamo la atención.

En fin solo son alucinaciones mías.

Yo eso de los saltitos no lo aprecio en mis servos, o al menos como no se envían pulsos con tanta asiduidad lo mismo no se nota. No lo sé.

¿Simba, cuando tu has hecho las pruebas los problemas son parecidos a los de Guillesan a la hora de hacer el seguimiento?

Simba
18/03/2016, 22:50
Yo eso de los saltitos no lo aprecio en mis servos, o al menos como no se envían pulsos con tanta asiduidad lo mismo no se nota. No lo sé.

¿Simba, cuando tu has hecho las pruebas los problemas son parecidos a los de Guillesan a la hora de hacer el seguimiento?

Lo de los servos no me hagas mucho caso, solo era un comentario un poco irracional.

Las pruebas nuestras de vuelo, tanto las misa como las de Turruk, son similares e incluso peores.
Podríamos decir que incluso en versiones mas recientes, el comportamiento ha sido a peor.
Si volamos un avión, como estamos a mas distancia, se aprecia menos errores, pero cuando nos acercamos hacia el Traker, y estamos próximos a la vertical el problema se agudiza mucho, y al pasar y alejarse se aprecia mucho desfase.

En el caso de un multi en vuelo cercano, es de locos, y no solo a 20m si no a 60 y 80m la antena parece que le ha entrado una pajara, los movimientos la mas de las veces es totalmente aleatorio.
Por esto comentaba y lo vuelvo a comentar, que por comparación con el Simulador, por muy mal que fuera, es totalmente diferente por ser en el caso del vuelo real, totalmente impredecible en el entorno de los 50m.

Simba
18/03/2016, 22:54
Simba hace falta una captura de vuelo real, o con el avión en la mano dando vueltas a cierta distancia. Sólo por ver si hay muchos errores de tramas, o lo de Guillesan es una simple excepción y debe solucionar lo de las comunicaciones tal y como lo tienes tú.
¿Como saco las tramas con el Traker en marcha?

rortega
18/03/2016, 23:06
Podríamos decir que incluso en versiones mas recientes, el comportamiento ha sido a peor.


Sería bueno si recordárais a partir de qué versión notáis que los problemas han crecido.


Si volamos un avión, como estamos a mas distancia, se aprecia menos errores, pero cuando nos acercamos hacia el Traker, y estamos próximos a la vertical el problema se agudiza mucho, y al pasar y alejarse se aprecia mucho desfase.

¿En el pan, en el tilt o en ambos?


Por esto comentaba y lo vuelvo a comentar, que por comparación con el Simulador, por muy mal que fuera, es totalmente diferente por ser en el caso del vuelo real, totalmente impredecible en el entorno de los 50m.

Pues si en el simulador va perfecto y en el campo no, algo pasa con las comunicaciones...

Simba
18/03/2016, 23:16
Sería bueno si recordárais a partir de qué versión notáis que los problemas han crecido.



¿En el pan, en el tilt o en ambos?



Pues si en el simulador va perfecto y en el campo no, algo pasa con las comunicaciones...

Muy dificil determinar que versión fue a peor, no se si Turruk puede decir algo.

En el pan y el el tilt todo va mal.

Pues lo de las comunicaciones va a ser que no, Turruk va en 868 Mhz y yo en 433 Mhz, y hace lo mismo, yo sin bluetooht y Turruk con modulo en emisora y bluetooht.

Simba
18/03/2016, 23:22
Yo estere unos días, que no voy a poder hacer pruebas, por lo menos hasta la semana que viene.

TURRUK
19/03/2016, 00:26
Hola solo quiero comentar que la mayoria los equipos de segimeinto en general funciona por video o mejor comunicaciones mas limpio. Personal mente yo tenia Egle Tree i va muy bien , lo tengo MFD igual o mejor , puede ser que falla la comunicacion.:rolleyes:

rortega
19/03/2016, 00:35
Muy dificil determinar que versión fue a peor, no se si Turruk puede decir algo.

En el pan y el el tilt todo va mal.

Pues lo de las comunicaciones va a ser que no, Turruk va en 868 Mhz y yo en 433 Mhz, y hace lo mismo, yo sin bluetooht y Turruk con modulo en emisora y bluetooht.

A raiz de la frase " incluso en versiones mas recientes, el comportamiento ha sido a peor", junto a otros comentarios que habéis hecho recientemente, así como esos vídeos en los que veo que el tracker literalmente se para, tengo puesto el foco en partes del código que he modificado como mejoras que he añadido, que no intervienen para nada en en la decodificación de tramas ni en cálculos de heading, tilt o distancia pero que, sin embargo, podrían estar metiendo algún retraso en el comportamiento del tracker.

Hay algo que hice hará de 10 días a dos semanas, y que no recuerdo si he comentado, pero que está implementado desde la versión 4 al menos.

Se trata de un bloque de código que detecta si deja de llegar telemetría, y al cabo de dos segundos sin recibir nada, hace que se detenga el servo pan con idea de que no se quede en movimiento por culpa del último pulso recibido. Lo hice porque esa situación de quedarse girando se da cuando estamos usando el protocol MFD y literalmente cierro el puerto serie del ordenador, y aunque en GPS Telemetry u otros protocolos no llegué a observar el problema decidí que afectara a todos los protocolos para asegurar que no sucediera más.

Lo estoy revisando y podría haber un pequeño bug que puede estar provocando que el tracker detenga el servo sin darse esa condición de pérdida de telemetría, a tal punto que sea como pequeños paroncitos entre trama y trama. Y ahora que lo estoy viendo creo que eso puede tener algo que ver.

Resulta que si nos llegan 2 tramas por segundo (2 herzios), la consumir los datos de una trama, en el intervalo que se espera la siguiente el contador de esos 2 segundos se pone en marcha, y al cabo de esos dos segundo manda el stop, que dura hasta que entra la siguiente trama.

Ésto puede estar explicando que a 4Hz el comportamiento haya mejorado, pues el intervalo que permanece parado entre trama y trama es más pequeño...

Me da a mí que va a ser por eso lo del retraso ...

Guillesan
19/03/2016, 00:37
Muy interesante Raúl, suena muy razonable. Esperamos tu resultado y probamos.

Simba
19/03/2016, 01:11
Muy interesante Raúl, suena muy razonable. Esperamos tu resultado y probamos.
Opino igual, y ademas quiero comentar lo que decía Turruk, de que por vídeo puede ser mas limpia la comunicación, pues opino que puede ser mas limpia y también mas sucia, depende del vídeo que llegue, todo según y como puede ser mejor o peor todo es relativo.

Lo de que con las versiones recientes va peor, a mi es la impresión que me da, pero con la voragine de pruebas y mas pruebas, al final perdemos el norte.

Raul, puede que esas modificaciones que hiciste, sea la causa y por lo que comentas puede también que se dispare el problema de retrasos, en el momento que se detecta alguna trama, digamos no pura en todos los aspectos.
Creo posible una teoría, vamos a ver si tenemos suerte:
Tenemos el Traker funcionando bien, y le llega una Trama corrupta, se lia con el calculo y le mete un retraso X, luego le llegan tramas buenas, pero el Traker ya no está en su sitio, y ve que tiene un error del copón, el PID reacciona y le pega un latigazo al Traker y crea a su vez una fuerte perturbación, esta en el calculo de corregir la perturbación, mas el desfase por desplazamiento, y le llega en ese momento otra trama corrupta, lo vuelve a paralizar y vuelve a repetirse la maniobra.

Es el tipico problema, de un sistema de control con múltiples perturbaciones, que a su vez generan perturbaciones, es decir el control entra en caos, por culpa del ruido que el propio control crea, y que se realimenta.

Solución, eliminar el ruido si es posible, y bajar ganancia si lo permite el sistema.

Nada solo son conjeturas varias.

Sl2.

Simba
19/03/2016, 11:55
Este es un video que puse el dia 5/3/16, y que es bastante significativo de lo que adolece el Traker, básicamente es un retardo considerable, que aunque hay momentos en los que +- va bien, es mas por suerte que por realidad.
Y también es significativo, y se nota como es natural mas en cercanía, que el TILT siempre va por debajo de la realidad.

No se si en estas fechas ya se habían realizado, los cambios en el programa.
Nosotros en principio se lo achacábamos a falta de ajuste o afino de los PIDs, pero visto lo visto creo que aunque han mejorado, esa no es la causa.

Posteriormente en otros idas de vuelo, empeoro bastante, pero siempre le echamos la culpa a los ajustes, y los servos, sin ser esa la causa principal.

En los minutos 1,12---3,12---y 3,50 se aprecia especialmente todo esto.

https://youtu.be/wApitBB224E

rortega
19/03/2016, 12:40
Está implementado desde hace exactamente 14 días (entre vesrión 3.3.4 y versión 3.4).

Voy a subir en un rato una nueva versión del firm (4.0.7) con esta función desactivada (la de parar el servo cada vez que no detecta teleemtría).

En esta versión el trimado sigue funcionando, pero no se puede desactivar manualmente.

El establecer y resetear el home funciona hasta que empieza el seguimiento. Una vez que empieza no es posible desactivar ni el trimado ni resetear el home ni entrar en el menú. Lo comento para que lo tengáis en cuenta y os centréis únicamente en que el seguimiento lo haga bien, así que:



No toquéis los botones una vez iniciado el seguimiendo, salvo que queráis trimar.
Haced las pruebas pertinentes SIN gps local, recordad desactivarlo desde el menú o con feature -gps.
Usad únicamente HOME de la telemetría del avión.


No hace falta que hagáis un millón de pruebas, ya sabemos los problemas que tenemos. Mejor haced la prueba a 4800 y 4hz siempre que se pueda. Si podéis colgar una camarita en el tracker como hizo Guillesan para que se vea bien el comportamiento (es que con una cámara en la mano y en movimiento yo me vuelvo loco, no atino a ver el avión Simba en tu vídeo, únicamente cuando está muy cerca, tengo un hojo hinchado, he amanecido así esta mañana, y hoy hay un cielo tan espléndido que tengo que bajar las persianas o ponerme gafs, son ya muchos meses seguidos sin luz solar con cielo azul y tengo que mirar la pantalla con los ojos casi cerrados).

El tema del debug no lo he implementado porque he estado toda lamañana haciendo pruebas con lo de la función de parada del servo. Como no consigo dejar fina esa función, he optado finalmente por eliminarla del código para que no meta ruido...

He añadido un parámetro en el cli que ya existía pero no lo puse operativo: set looptime

Voy a explicar que es y para que sirve, pero no lo trasteéis para la prueba. Ésto dejadlo para después para poder comparar si hay alguna mejora (aunque lo dudo).

Simplemente establece en microsegundos la frecuencia con la que se entra al blucle principal del programa que ejecuta toda las funciones del tracker (desde leer el puerto serie, decodificar tramas, calcular tilt y headint, etc., etc....todo).

Por defecto está a 3500, lo que quiere decir que al blucle principal se repite cada 3.5 milisegundos.

La idea sería bajarlo a 2500 o 2000 para ver si ser observa alguna mejora.

El valor de min_logic_level se ve afectado al bajar el valor del looptime, así que habrá que subirlo para que las pulsaciones de los botones se estabilicen.

Ya digo, no lo toquéis de momento, es solo para "curiosear" cuando hayáis hecho la prueba de campo.

Guillesan
19/03/2016, 12:43
Joder, parecen las instrucciones para un vuelo a la luna, ok, pruebo.
Raúl cuídate chico, esto es solo un hobby.

Simba
19/03/2016, 12:54
OK, tomo nota.
Lo del set looptime lo recuerdo del Cleanfliht CLI, que para el Micro250 se recomendaban ponerlo a 2500 o 2000, y creo recordar que era para agilizar los movimientos del Micro, para tener mas rapidez en las maniobras.
Supongo que lo estas teniendo en cuanta por este motivo.

Y una cosa chico, si estas con el ojo como dices, ¿no sera mejor que dejes el ordenador?.
Venga que te mejores.

rortega
19/03/2016, 13:16
OK, tomo nota.
Lo del set looptime lo recuerdo del Cleanfliht CLI, que para el Micro250 se recomendaban ponerlo a 2500 o 2000, y creo recordar que era para agilizar los movimientos del Micro, para tener mas rapidez en las maniobras.
Supongo que lo estas teniendo en cuanta por este motivo.

Y una cosa chico, si estas con el ojo como dices, ¿no sera mejor que dejes el ordenador?.
Venga que te mejores.

Sí sería lo suyo, ya esta mañana lo dejo, queya está bien (creo que me ha picado un mosquito u otro insecto en el párpado superior, no es grave).

Simba
19/03/2016, 13:37
Te has tomado algo, me refiero a algún Antihestaminico, por si es alguna alergia que te ha dado.
En todo caso y si no se te baja la inflamación, te tendrías que poner un Urbasón.
Que te mejores.

rortega
19/03/2016, 14:21
Te has tomado algo, me refiero a algún Antihestaminico, por si es alguna alergia que te ha dado.
En todo caso y si no se te baja la inflamación, te tendrías que poner un Urbasón.
Que te mejores.

Sí un antihistamínico sí he tomado, pero si no baja tomaré un corticoide que tengo, gracias.

He subido un vídeo en el que comparo como se comporta el tracker con MFD cuando tiene todas las features activadas o desactivadas:

https://www.youtube.com/watch?v=QwL6G9UdR_E

Con ésto sólo quería descartar que haya un problema de sobre carga, pero se aprecia que no.

Al principio hay un pequeño desfase porque el heading parte de posiciones diferentes (no me dí cuenta al empezar a grabar y ya lo dejé así).

La oscilación es porque le he metido un poco de min_pan_speed, para que haya el menor error posible (un grado como mucho es el error que obtengo).

En fin, que esas cosas de telemetría de salida, easing y tal que he estado metiendo últimamente no afectan como se puede observar.

Guillesan
19/03/2016, 14:56
Pregunta Raul, la version 4.0.7 en github es la que no lleva numero hay 4.0.5 y la otra sin numeracion supongo la nueva es esta.

carabin
19/03/2016, 15:51
Raúl, parece Harry Potter con la varita mágica.

Enviado desde mi GT-I9301I mediante Tapatalk

rortega
19/03/2016, 16:03
Pregunta Raul, la version 4.0.7 en github es la que no lleva numero hay 4.0.5 y la otra sin numeracion supongo la nueva es esta.

La nueva es la que no lleva número en el nombre del archivo.

He dejado la anterior por si era necesario volver a ella para comparar entre dos versiones.

rortega
19/03/2016, 16:03
Raúl, parece Harry Potter con la varita mágica.

Enviado desde mi GT-I9301I mediante Tapatalk

:laugh:

rortega
19/03/2016, 16:04
Cuando tengáis dudas con los nombres de los archivos, podéis comprobar que versión es una vez cargada con el comando version.

Simba
19/03/2016, 16:12
Ya la he probado a nivel simulador, y no he podido resistir y he bajado el looptime a 3000.
He tenido que subir lo de los botones a 25 por que si no no funcionan.
La impresión es muy buena pero no quiero decir nada hasta no volar en vivo.
No se si será sugestión pero lo veo más fluido.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
19/03/2016, 16:33
Ya la he probado a nivel simulador, y no he podido resistir y he bajado el looptime a 3000.
He tenido que subir lo de los botones a 25 por que si no no funcionan.
La impresión es muy buena pero no quiero decir nada hasta no volar en vivo.
No se si será sugestión pero lo veo más fluido.

Enviado desde mi GT-I9505 mediante Tapatalk

En algo tiene que variar porque el servo hacía paradas por culpa de ese sistema de control de perdida de telemetría.

Simba
19/03/2016, 16:44
¿Como podríamos simular perdida de tramas con el simulador?

Se me ocurre alejarme al limite de alcance del Bluetooht.

Simba
19/03/2016, 20:26
¿Como podríamos simular perdida de tramas con el simulador?

Se me ocurre alejarme al limite de alcance del Bluetooht.

Bueno pues el método me vale, al alejarme dentro de casa, encuentro situaciones no ideales y de perdida de datos, desde la perdida total de Telemetria a perdida intermitente.

Experimentando todas las posibles, variaciones de calidad de Telemetria, llego a algunas conclusiones interesantes.

Sin perdida de datos en las proximidades y con 4 hz y 4800 bauds, el movimiento es totalmente fluido tanto en Pan como en Tilt.

Al tener perdida de datos intermitentes, esto se traduce inmediatamente, en un retraso cada vez mayor, cuanto mas aumenta la perdida de datos.

Si pierde totalmente la Telemetria durante unos segundos, el tiempo que dure se para, y al recuperar datos, vuelve a coger rápidamente la posición.

Resumiendo, la perdida parcial de datos de forma continua, produce un error en forma de retraso, luego el retraso que experimentamos, en vuelo real, se puede deber a esta perdida de datos, o a que los datos no se procesan debidamente.

Dado que ya se ha solucionado el retraso, por el tema del calculo de errores, creo que si la comunicación es buena, el Traker ira bien.

Por otro lado, creo que podemos tener otro problema, y es la velocidad de refresco del GPS.

Experimento un mayor angulo de error de retraso, cuanto menor es la velocidad de refresco, ya lo sabíamos pero es bastante significativo.

A 4hz y a 100m de distancia y 20 de altura, se puede decir que puede darse por buena, pero lo mismo en 2hz el error se aprecia el doble, y lo mismo pasa en Tilt.

He ido subiendo el nº de hz de la simulación, y observo que no hay diferencia apreciable entre 4hz y 10hz (la hay pero no se nota).

No se si es posible Raul, pero se debería optimizar la captura de tramas, en el entorno de los 4hz a 10hz, para que resulte mas eficiente, y se pierdan menos datos.

A la espera de pruebas de campo, me da la impresión y hay que se cautos, que vamos por buen camino.

sl2.

Simba
19/03/2016, 20:48
Raul, hay un detalle que no he comentado, y que me parece muy interesante, voy a ver si me explico.

Las pruebas la hago con la ayuda del OruxMap, y cogiendo como referencia, el punto donde esta el Traker (punto central).
Gracias a esta herramienta, se por donde esta situado el avión, y observo el retraso de error, entre el avión simulado y el angulo del traker.

Me imagino que lo que lee el OruxMaps, sale por el serial 30, de forma transparente, o casi transparente, y que estos tatos que recibe, son los que directamente le llegan al Traker.
Pues bien lo curioso del tema, es que mientras en el Mapa, el Oruxmap representa el avión sin retraso , el angulo de error que se experimenta físicamente, en el Traker de forma real, es el comentado y proporcional a la perdida de datos.
Dicho de otra manera, el Oruxmap es mucho mas inmune, a la perdida de tramas, y por eso experimento y puedo ver el retraso.
¿A que es curioso. ?
En parte supongo que se debe, a que el Oruxmap, dispone de un sistema de simulación de trayectoria, que no se para y sigue marcando posición, por predicción calculada en función de los últimos datos recibidos.

En fin sea por lo que sea, es un método que me sirve para sacar conclusiones, y que quizás seria bueno de que lo analizaras, por si puede ser interesante implementarlo en un futuro, en el Traker.

Sl2.

rortega
19/03/2016, 21:33
Raul, hay un detalle que no he comentado, y que me parece muy interesante, voy a ver si me explico.

Las pruebas la hago con la ayuda del OruxMap, y cogiendo como referencia, el punto donde esta el Traker (punto central).
Gracias a esta herramienta, se por donde esta situado el avión, y observo el retraso de error, entre el avión simulado y el angulo del traker.

Me imagino que lo que lee el OruxMaps, sale por el serial 30, de forma transparente, o casi transparente, y que estos tatos que recibe, son los que directamente le llegan al Traker.
Pues bien lo curioso del tema, es que mientras en el Mapa, el Oruxmap representa el avión sin retraso , el angulo de error que se experimenta físicamente, en el Traker de forma real, es el comentado y proporcional a la perdida de datos.
Dicho de otra manera, el Oruxmap es mucho mas inmune, a la perdida de tramas, y por eso experimento y puedo ver el retraso.
¿A que es curioso. ?
En parte supongo que se debe, a que el Oruxmap, dispone de un sistema de simulación de trayectoria, que no se para y sigue marcando posición, por predicción calculada en función de los últimos datos recibidos.

En fin sea por lo que sea, es un método que me sirve para sacar conclusiones, y que quizás seria bueno de que lo analizaras, por si puede ser interesante implementarlo en un futuro, en el Traker.

Sl2.


Lamento decirte que lo que sale por el puerto para el oruxmaps no es lo que entra exactamente, no se hace un "puente".

Lo que hago es que leo la telemetría y almaceno la latitud, la longitud y la latura, habiéndolos truncado, es decir, se alamcenan esos datos asumiendo ya el error, pero lo que se almacena son datos de tramas buenas, las tramas malas se desechan.

La trama de salida que se envía al orux no tiene por qué ser enviada inmediatamente después de haber decodificado la de entrada, sino que se envían a intervalos de 150 milisegundos, pero alternándose tramas GGA con tramas MRC, para que orux pueda orientar bien el triangulito, es decir, que se envía una trama GGA a orux cada 300 milisegundos.

Lo que se envía a orux son los datos en curso cuando el tic tac del reloj alcanza los 300 milisegundos, es decir, no almacenamos en un buffer las tramas que entran y luego las vamos enviando orux, porque si lo hiciéramos se nos llenaría al enviarlas de 300 en 300 ms (piensa que tu envías por telemetría a 4hz 1 trama cada 250 milisegundos). Lo que enviamos por tanto es el valor de latitud, longitud y altitud que en el momento de tener que enviar a orux tengamos disponible, y puede que haya entrado al principio de ese intervalo de 250 milisegundos, en mitad, o al final... El resultado es que si contásemos las tramas que entran buenas y procesamos para calcular heading y tilt, y contásemos las que enviamos a orux, orux sale perdiendo.

En cualquier caso, el retraso entre una trama de entrada GGA y su correspondiente de salida, variaría entre los 0 milisegundos a los 300 milisegundos (casi una tercera parte de un segundo).

Simba
19/03/2016, 21:41
Bien ok pero aun así y todo, el Orux va por delante.
¿ como te lo esplicar?

Enviado desde mi GT-I9505 mediante Tapatalk

Guillesan
19/03/2016, 21:41
Hola, ahora que leo el tema, veo que estamos ya otra vez en la cresta de la ola o lo que es lo mismo Raul lo ha arreglado.
Bueno se me antoja que la una firma de darle más suavidad a el movimiento sería... darle predicción. Me explicó si seguimos un móvil que va a x velocidad hacia la izquierda y mientras no baje esa velocidad en una cantidad cierta predigo que seguirá hacia esa dirección, pero si baja de velocidad puede que sea posible predecir que va s cambiar o se va s parar y me preparo para parar de seguir. Vaya tocho pero no sé si me explico

rortega
19/03/2016, 21:43
Dado que ya se ha solucionado el retraso, por el tema del calculo de errores, creo que si la comunicación es buena, el Traker ira bien.

Aquí no sé que has querido decir, no he solucionado ningún retraso por cálculo de errores. Lo que he solucionado ha sido quitar un sistema de parada del servo en caso de perdida de telemetría que tenía un bug.


No se si es posible Raul, pero se debería optimizar la captura de tramas, en el entorno de los 4hz a 10hz, para que resulte mas eficiente, y se pierdan menos datos.

¿Quieres decir que si nos entran tramas a 10hz que no las decodifiquemos todas y nos quedemos con x tramas por minuto?

Es complejo, pero se poría haer. No obstante como los GPS son configurable en hz, no haría falta emplear tiempo de proceso en esa tarea.

Lo estudiaremos más adelante ...

La idea que me gusta, que has comentado en otro mensaje posterior a éste, que llevo dándole vueltas al tema en mi cabeza desde hace ya semanas, es la de estimar la siguiente posición, anticipa al tracker. Es posible implementarl algo así, pues en cada posición que recibimos sabemos la distancia y el ángulo, y podríamos estimar una velocidad angular con los últimos datos procesados.

No es lo mismo, pero digamos que es muy parecido a lo que hacemos con los PIDs... Creo que a día de hoy es la única forma de hacer que el tracker no se retrase.

Simba
19/03/2016, 21:44
Eso es lo que yo dije que hacía el Orux y que Raúl lo mirase.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
19/03/2016, 21:46
Pues eso que el reultado son errores

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
19/03/2016, 21:47
Bien ok pero aun así y todo, el Orux va por delante.
¿ como te lo esplicar?

Enviado desde mi GT-I9505 mediante Tapatalk

Pues porque el pan no lo movemos en 300 milisegundos, sino que lo movemos conforme al algoritmo PIDs, y en ocasiones puede necesitar algo más de un segundo en llegar a su destino, así que es normal que el orux lo pinte antes.

Simba
19/03/2016, 21:49
Y también que tenga una predicción

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
19/03/2016, 21:58
Perdonar pero me he cruzado en varias ocasiones con Raul y con Guillesan, no de puede ir con el móvil y paseando al perro, querer contestar y seguir el hilo. jajaja jiji.

JuanTrillo
19/03/2016, 21:58
¿prediccion? Al final mas que un tracker va a ser un antiaéreo.
Buen trabajo. Os estáis pegando una paliza y os va a quedar espectacular.

Enviado desde mi X16 mediante Tapatalk

rortega
19/03/2016, 22:00
Hola, ahora que leo el tema, veo que estamos ya otra vez en la cresta de la ola o lo que es lo mismo Raul lo ha arreglado.
Bueno se me antoja que la una firma de darle más suavidad a el movimiento sería... darle predicción. Me explicó si seguimos un móvil que va a x velocidad hacia la izquierda y mientras no baje esa velocidad en una cantidad cierta predigo que seguirá hacia esa dirección, pero si baja de velocidad puede que sea posible predecir que va s cambiar o se va s parar y me preparo para parar de seguir. Vaya tocho pero no sé si me explico

Tiene que ser un sistema sencillo, que consista en darle un nuevo heading al algoritmo de PIDs para que corrija un error mayor del real, y si luego tiene que seguir corrigiendo que lo haga, algo que sea función de los últimos erroes corregidos. Si nos metemos en temas de cálculos con coordenadas y velocidades, lo podemos hacer, pero va aser complejo y creo que el resultado no tiene pro qué ser mucho mejor que lo que comento.

Lo voy a investigar e idear algo ...

Simba
19/03/2016, 22:00
¿prediccion? Al final mas que un tracker va a ser un antiaéreo.
Buen trabajo. Os estáis pegando una paliza y os va a quedar espectacular.

Enviado desde mi X16 mediante Tapatalk
En ello estamos, un poco locos pero contentos, al final igual funciona y todo.

Sl2

Simba
19/03/2016, 22:04
Lo de la predicción es algo que seguro está implementado, en mas de un sistema de seguimiento, sea GPS tipo TOM TOM o cualquier tipo de seguidor de un movil. La cuestión es como implementarlo, y pasa como dice raul y Guillesan, por ser la única forma de hacer que el sistema funcione fluido y de forma continua sin dar saltos.

Simba
19/03/2016, 22:06
Para mi que es el pequeño y gran secreto, que tienen algunos de los mejores Trakers comerciales.
¿A que sí? Turruk.

TURRUK
19/03/2016, 22:14
Para mi que es el pequeño y gran secreto, que tienen algunos de los mejores Trakers comerciales.
¿A que sí? Turruk.

:biggrin2::biggrin2::plane:

Guillesan
19/03/2016, 22:17
Gracias Juan yo personalmente estoy disfrutando como un cer....
En lo navegadores de coche se usa algo parecido cuando la carretera entra en un túnel sigue el movimiento del coche en base a la velocidad que llevaba y claro está de la dirección así es capaz de darte la salida de la carretera dentro del túnel donde claro está no hay señal gps,

Guillesan
19/03/2016, 22:18
Coño estaba escribiendo y vosotros decíais lo mismo

carabin
20/03/2016, 01:13
Yo creo que esa parte en los GPS de coche los cálculos los hace el acelerómetro , que aún perdiendo la señal de GPS sigue con sus valores y sus cálculos .

Simba
21/03/2016, 00:39
Que tal fieras, estáis muy callados pero seguro que estáis.

Yo no he podido hacer ninguna prueba de campo ni de nada, a ver si esta semana, pruebo algo la ultima versión y reporto algo.

Ale buenas noches.

rortega
21/03/2016, 08:22
Buenos días! Yo ayer escribiendo algo de código para predecir la siguiente posición GPS, algo muy simple, que esta tarde espero tener depurado y realizando las primeras pruebas ya con el tracker.

Simba
21/03/2016, 09:48
Buenas noticias, ya me imaginaba yo, que algo estabas cociendo.
Yo si puedo ésta tarde quería probar la 4.0.7.


Enviado desde mi GT-I9505 mediante Tapatalk

Simba
21/03/2016, 09:54
No se lo que estas pensando de la predicción pero sabemos que en la Fip32 tenemos 3 acelerometros, y creo que lo que miden es la velocidad angular.
Quizás ese dato seria el necesario para el cálculo.
Yo no se exactamente en que se fundamenta y poco puedo ayudar.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
22/03/2016, 08:06
Ya tengo lista la 5.0 pero anoche no la pude subir porque falló la conexión a internet. Estaba previsto un cambio de velocidad de la conexión y se ve que lo ejecutaron anoche.

La forma de estimar la próxima posición es un poco rudimentaria, pero podría servir... He realizado pruebas, siempre sobre la mesa, y es difícil determinar si se anticipa, habría que probarlo en vivo.

La idea ed sencilla. Cuanto el avión vuela, se desplaza del punto A al punto B, con un ángulo con respecto al norte, recorriendo por ejemplo una distancia de 8 metros, y que vamos a estimar las coordenadas del punto C.

Supongamos que vuela a una velocidad constante, o si acelera o desacelera, damos por hecho que al recibir 4 (o 2) posiciones por segundo, en 250 milisegundos (o 500 como mucho) poca variación habrá de cambio de velocidad, por lo que asumimos que la distancia que va a recorrer para llegar al punto C será aproximadamente la misma que la anterior, otros 8 metros.

Con esa asunciones, y sabiendo la dirección que lleva, se estima las coordenadas del punto C, con las que el tracker calcula un nuevo heading que debería ser ligeramente mayor que el real, así que adelanta su movimiento de giro de servo pan los grados necesarios.

Luego, al cabo de 250 milisegundos (o 500 si vamos a 2hz), recibe los datos de la posición real, con la distancia real recorrida y el ángulo real que llevaba el avión, con lo que vuelve a estimar una nueva posición. Si la distancia real recorrida ha sido de 7 metros, por ejemplo, pues asumimos que ahora para llegar al cuarto punto D, recorrerá 7 metros y con un nuevo ángulo. De esta forma, si hay acelaración o desaceleración, aunque no es demasiado exacta, también la tenemos en cuenta.

Esa es la idea.

Para ajustar ese comportamiento, he metido un parámetro, gps_gain, que admite valores de 0 a 100, con valor por defecto a 25, que indica que la distancia que recorrerá de B a C será la misma que de A a B.

Sin ponemos el parámetro a 50, será el doble, a 75 el triple y a 100 el cuádruple.

El meter el parámetro es porque vamos a recorrer tan poca distancia en 250 milisegundos, que lo mismo con los errores de truncamiento el resultado sea que la posición C estimada tenga las mismas coordenadas que la posición B, y al final se comporte igual o peor por perder tiempo en cálculos con coma flotante.

Desayuno y lo subo ...

Guillesan
22/03/2016, 20:11
cargada la 5.0 , mañana pruebas, veremos esa prediccion . Gracias Raul

Simba
22/03/2016, 21:09
Hola a todos, esta tarde hemos estado de pruebas, de la 5.0.0.

Estoy subiendo video, lo siento por el tostón pero no me apaño para montar algo decente, he utilizado una Mobius en la antena, y el formato Avi, como que no lo traga bien el Camtasia y me da error.

Bueno a lo que vamos, la predicción no se que decir, mi impresión mas con las pruebas con simulador, que con vuelo real, son que al faltar Tramas por defecto de transmisión / telemetria, ( lo he forzado apantallando el Bluetooht), mi inpresión es que l sistema se comporta como mas robusto, con menos paradas por falta de datos, es mi impresión un tanto subjetiva, pero parece real el que predice y ase nota.

En vuelo esta versión funciona bastante bien, por no decir que va francamente bien.
Tiene sus cosas, y en los videos lo apreciareis, pero ya adelanto que el problema de retraso, es debido a un cierto desajuste del Pan 0.
El motivo puede ser y es algo que Raul tiene que explicar, que al cambiar a esta versión, se necesita un cierto ajuste, de algunos parámetros de control.
Nada mas empezar a probar en casa, al hacer un heading notaba que en el desplazamiento a la derecha, la precisión era mucho mejor, que haciendo un desplazamiento a la izquierda.
En ese momento no pensé en ajustar, el Pan 0, que por defecto esta en 1500, y que en las otras versiones, me clavaba siempre bien el Pan, pero en esta esta un poco desplazado, y es origen del desfase en el seguimiento a izquierda.

Pongo video y luego continuo.

https://youtu.be/xm3SIZlgNRQ



Al final del video se puede aptreciar, que el Traker empieza a girar el el solo, lentamente hacia la derecha por lo comentado de un pequeño desajuste del Pan 0, que estando por defecto a 1500, en esta versión necesita 1510, para quedar centrado.
Esto lo he corregido y analizado en casa, ya a la vuelta de los vuelos.

Simba
22/03/2016, 21:57
En este otro video se aprecia que tiene mas desfase cuando el vuelo es hacia la izquierda, que cuando vuela Hacia la derecha.

https://youtu.be/g7NtsqcFhLo

rortega
22/03/2016, 22:08
Estaba escribiendo un mensaje para explicar un poco a Guillesan como funciona el sistema de ajuste, además de unas imágenes para ilustrar un poco lo que se espera que haga el tracker, cuando he visto el vídeo de Simba, no me esperaba que lo probara tan pronto, que callado estaba, y y yo pensando que estaba paseando santos...

Ahí dejo las imágenes ya la explicación del parámetro, y luego ya comentaremos el vídeo. Decía así:

Recuerda lo que hace el parámetro:

set gps_bain=25



25 quiere decir que prevee que el avión recorrerá los mismos metros que entre los dos últimas posiciones reales.
50 el doble
75 el triple
100 es 4 veces la distancia


Puedes poner cualquier valor entre 0 y 100, y no admite decimales.

Si pone sun valor entre 0 y 24, entonces le estamos diciendo que recorrerá una distancia menor. Digamos que la mitad de la distancia estará en:

set gps_bain=12 (no admite decimales)

Por encima de 25 lo más probable es que se adelante más de la cuenta, la ventaja que puede tener subirlo un por encima es que en caso de pérdida de tramas quizás se consiga más avance que antes de tener este sistema de predicción.

Pero si nos pasamos mucho, lo más probable es que termine el tracker corrigiendo hacia detrás y hacia delante como cuando no ajustamos bien los PIDs (no nos pongamos a toquetear los PIDs si los teníamos bien antes, porque no va a servir de mucho, lo suyo es bajar el valor de gps_gain hasta un punto en el que no haya oscilaciones, o sean de poca importancia).

Veamos las imágnes:

El avión ha volado de A a B, recorriendo una distancia de 140 metros con un ángulo de 225º, y nuestro tarcker ha realizado el giro, y se ecuentra apuntando a B, o a puntito de llegar.

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64530&stc=1&d=1458676636

El firmware utiliza esa información para estimar que va a llegar a C, recorriendo otros 140 metros y con el mismo ángulo, así que da la orden al servo para girar la antena los grados necesarios.


http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64531&stc=1&d=1458676636

Suponiendo que el punto final no sea el estimado, pues el avión podría haber empezando a girar guscando el Oeste, llega al punto D, del cual nos devuelve sus coordenadas reales, con lo que volvemos a hacer una estimación empleando el mismo método, y así sucesivamente...

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64532&stc=1&d=1458676636

Nota, en el ejemplo las distancias son exageradas, nuestros aviones no van a recorrer tanta distancia entre trama y trama recibida.

Como bien comenta Simba, no se ha contemplado el que se pierdan tramas, y el tracker podría adelantarse demasiado y quedarse esperando hasta que recibe la siguiente trama buena y vuelve a realizar estimación. En este caso habría que considerar utilizar el tiempo transcurrido entre tramas buenas para obtener una mejor estimación, creo...

rortega
22/03/2016, 22:11
Al final del video se puede aptreciar, que el Traker empieza a girar el el solo, lentamente hacia la derecha por lo comentado de un pequeño desajuste del Pan 0, que estando por defecto a 1500, en esta versión necesita 1510, para quedar centrado.
Esto lo he corregido y analizado en casa, ya a la vuelta de los vuelos.


Antes de nada Simba, muchísimas gracais por tan estupenda prueba, más un día perro como el que hace.

En cuanto a los 1500 que comentas del pan0, yo pensaba que siempre has ajustado ese valor, yo al menos lo ajusto siempre que cargo una versión nueva poniendo el valor 1528, que es el que me jor me va.

El valor 1500 viene por defecto desde hace ya muchas versiones atrás.

Guillesan
22/03/2016, 22:15
Buena tecnica a probar, mañana hago la mia.
Pero tal como hablabamos de pder hacer un debug de lo que llega a la antena y ver los parametros reales que maneja para pode r llegar a posicionar, seria creo interesante para ajustarse mas a la realidad de los datos a manejar, no creeis.
Un saludo

Guillesan
22/03/2016, 22:19
Entiendo que esta tecnica de prediccion es efectiva con todos los protocolos que a su manera mandan posiciones nmea, pero no para MFD por video que no lo hace es asi no

rortega
22/03/2016, 22:27
Buena tecnica a probar, mañana hago la mia.
Pero tal como hablabamos de pder hacer un debug de lo que llega a la antena y ver los parametros reales que maneja para pode r llegar a posicionar, seria creo interesante para ajustarse mas a la realidad de los datos a manejar, no creeis.
Un saludo

Sí, es cierto, el problema es que me lleva un poco de tiempo hacerlo, tengo que preparar como si fuese un protocolo más de telemetría, para configurar el serial y que vaya soltanto los datos de posición real, estimada, heading real y heading estimado, tiempo transcurrido entre trama y trama buena, ditancia recorrida, velocidad (esta última es redundante).

Una vez tengamos eso, puedo hacer gráficas y analizar para sacar algunas conclusiones e intentar afinar.

Por otro lado, comentar el segundo víde de Simba. Qué vaya más rápido en un sentido que en otro no creo que sea por el algoritmo, los cálculos son los mismos en un sentido que en otro. Quizás el tema del desajuste del pan0 tenga algo que ver.

También, si se prevee volar rapidito, quizás meterle un poco más al valor gps_gain ayude a seguir mejor al avión.

Guillesan
22/03/2016, 22:29
También, si se prevee volar rapidito, quizás meterle un poco más al valor gps_gain ayude a seguir mejor al avión.
Ese valor se podria integrar en el menu del oled?

Simba
22/03/2016, 22:30
Bueno resumiendo podríamos decir, que el resultado es bastante bueno, creo que en próximos días de vuelo, despues de ajustar lo comentado del Pan 0=1510 en mi caso, y reajustar los PIDs, puede ir aun mejor.

Creo Raul que los cambios realizador en esta versión, necesitas reajustar perametros, pongo a continuación como los tenia en la anterior versión, y como he tenido que dejarlos, para contrarrestar los cambios introducidos por el control predictivo.

V 5.0.5
looptime = 3000

p = 8000
i = 200
d = 1000
max_pid_error = 1
max_pid_accumulator = 8000
max_pid_gain = 500
pid_divider = 15
pan0 = 1510
pan0_calibrated = 1
min_pan_speed = 20

min_logic_level = 25


V 4.0.7
looptime = 3000

p = 7000
i = 60
d = 300
max_pid_error = 1
max_pid_accumulator = 5000
max_pid_gain = 500
pid_divider = 15
pan0 = 1500
pan0_calibrated = 1
min_pan_speed = 12


De momento es todo, mañana veremos si Guillesan hace pruebas, y podremos comparar resultados.

min_logic_level = 25

Simba
22/03/2016, 22:48
No se el porque Raul, pero quiero insistir en un detalle, lo de los ajustes de PIDs, los hice antes de ir a volar, no así el Pan 0 que quedo como estaba por defecto.
Repito que nada mas probar en casa, al meter heading no me llegaba a centrar bien, y quedaba un error de unos 10º a 12º que no era capaz de ajustar.
Procedí a ir cambiando y ajustando los PIDs, con el resultado de dejar el los heading, un error +- de 1º a 2º, y así es como me fui a volar.

Supongo que los cambios de versión si que le afecta en algo.
Por cierto que la anterior versión no la llegue a probar en vuelo, y no me extrañaría que también funcionara bastante bien.

Lo que no llego a entender, es en el caso de no tener perdida de tramas, como es el comportamiento. ¿hace algo ahora, que en la versión anterior no hacia? suponiendo que no tengamos perdida de Tramas.

Eso es algo que me pregunto.

rortega
22/03/2016, 23:16
Entiendo que esta tecnica de prediccion es efectiva con todos los protocolos que a su manera mandan posiciones nmea, pero no para MFD por video que no lo hace es asi no

Para MFD efectivamente aún no está operativo, pero se hará, si funciona bien en los demás protocolo que manejan posiciones GPS, lo trasladaremos a MFD, no es complicado.

rortega
22/03/2016, 23:18
También, si se prevee volar rapidito, quizás meterle un poco más al valor gps_gain ayude a seguir mejor al avión.
Ese valor se podria integrar en el menu del oled?

Poderse se puede, pero es lo de siempre, necesito tiempo... Al final una aplicación para el smartphone sería lo suyo, facilitaría mucho las cosas.

rortega
22/03/2016, 23:33
Creo Raul que los cambios realizador en esta versión, necesitas reajustar perametros, pongo a continuación como los tenia en la anterior versión, y como he tenido que dejarlos, para contrarrestar los cambios introducidos por el control predictivo.

Ok Simba, ahora ya entiendo lo que quisiste decir con lo de que necesitabas ajustar parámetros.

Entiendo al ver que has subido todos esos valores, que para alcanzar la nueva posición,que está más lejo, se necesita una corrección mayor, más chicha (subir P), y al mismo tiempo aumentar la velocidad de respuesta con I y contrarestar el exceso con D (corrígeme si meto la pata), para lo que se necesita también que el servo tenga menos freno (subir min_pan_speed), y todo eso implica tener un acumulador más amplio porque todos esos aumentos implica un incremento mayor del resultado en las operaciones aritméticas realizadas.

Tiene lógica, pero yo sólo no habría llegado a pensar que se necesitaría tanto ajuste para dejarlo fino.

Simba
22/03/2016, 23:44
Ok Raúl eso es.
Y otra cosa, si te das cuenta en los videos, el Tilt siempre o casi siempre está por encima del objetivo.
Yo lo tengo bien ajustado entre 0° y 90°, pero luego los resultados del cálculo siempre lo sitúa por encima.
Al estar cerca no es importante, pero lejos se aprecia desfase hacia arriba.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
22/03/2016, 23:58
No se el porque Raul, pero quiero insistir en un detalle, lo de los ajustes de PIDs, los hice antes de ir a volar, no así el Pan 0 que quedo como estaba por defecto.
Repito que nada mas probar en casa, al meter heading no me llegaba a centrar bien, y quedaba un error de unos 10º a 12º que no era capaz de ajustar.
Procedí a ir cambiando y ajustando los PIDs, con el resultado de dejar el los heading, un error +- de 1º a 2º, y así es como me fui a volar.

Supongo que los cambios de versión si que le afecta en algo.


Simba estoy revisando los cambios que he realizado con el paso del tiempo y no hay nada significativo en ese sentido. Los únicos cambios que podrían afectar a algo así son el introducir el parámetro de configuración servo_pwm_rate (que por defecto debe ser 50hz, y aunque no lo teníamos antes visible, siempre ha estado ahí trabajando a esos herzios) y el looptime que por defecto era 3500, y tú lo tienes a 3000.

Quité la parada del servo por pérdida de telemetría, que lo he hacía precisamente es enviar el valor pwm de pan0 al servo. Y he realizado una reorganización del código en la pargte de los condicionales que inician el comienzo del seguimiento, pero eso no afecta para nada.

Yo lo cierto es que mis priebas han sido con los mismos parámetros que siempre he usado, pero como no puedo hacer aún prueba de campo, no puedo saber a ciencia cierta si necesitan una mejora.



Por cierto que la anterior versión no la llegue a probar en vuelo, y no me extrañaría que también funcionara bastante bien.

Lo que no llego a entender, es en el caso de no tener perdida de tramas, como es el comportamiento. ¿hace algo ahora, que en la versión anterior no hacia? suponiendo que no tengamos perdida de Tramas.

Eso es algo que me pregunto.

No, no hace nada nuevo, lo único que se hace es recalcular la posición por el método explicado, cálculos trigonométricos, y pasar la nueva coordenada para calcular el nuevo valor HEADING de destino.

Quizás en los ajustes que has tenido que hacer a los PIDs tenga bastante que ver el hecho haber deajdo 1500 por defecto en pan0 ¿Tú siempre lo has tenido a 1500? Yo entiendo que nó, que eso es una situación ideal...

rortega
23/03/2016, 00:00
Ok Raúl eso es.
Y otra cosa, si te das cuenta en los videos, el Tilt siempre o casi siempre está por encima del objetivo.
Yo lo tengo bien ajustado entre 0° y 90°, pero luego los resultados del cálculo siempre lo sitúa por encima.
Al estar cerca no es importante, pero lejos se aprecia desfase hacia arriba.

Enviado desde mi GT-I9505 mediante Tapatalk

Ese es un tema que habrá que investigar, porque sobre el mantel y con el simulador, yo lo veo correcto...

Por cierto, no me has dicho nada de si te pega o no trancazo el tilt al iniciar el seguimiento...

Simba
23/03/2016, 00:06
No, no hace nada raro, es más si tengo que decir algo, es que incluso en la proximidad del Traker, los movimientos por efecto del posicionamientos erráticos del gps, son más dulces.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
23/03/2016, 00:12
Necesitaría saber si el tilt tiene el mismo problema cuando no usamos easing

Simba
23/03/2016, 00:14
Pues es algo que Guillesan podía probar mañana.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
23/03/2016, 01:24
Hay una cosa que todavía la tenemos en el tintero.

Me refiero al GPS Local, lo tenemos desactivado y estamos con GPS Aircraft.

Tenemos que tener en cuenta, que también éste era un factor perturbador.

Al final si se decide activarlo, se debería hacer Fix, memorizar y que no se actualice, a no ser que inventemos algo, ese era un factor mu malo OK.

rortega
23/03/2016, 09:22
Hay una cosa que todavía la tenemos en el tintero.

Me refiero al GPS Local, lo tenemos desactivado y estamos con GPS Aircraft.

Tenemos que tener en cuenta, que también éste era un factor perturbador.

Al final si se decide activarlo, se debería hacer Fix, memorizar y que no se actualice, a no ser que inventemos algo, ese era un factor mu malo OK.

Lo veré también, aunque ya después de semana santa, porque salgo mañana para España.

Estoy ahora mismo revisando el tema del desfase del heading en esta versión 5.0, de momento estoy haciendo pruebas en modo cli y no tengo desfase mirando al norte, salvo el que provoca los +- 2 grados de esa perturbación de la brújua que siempre he tenido y que se observa en el display cambiando constantemente. Mí móvil con el tracker están casi perfectamente alineados al norte.

He bajado el looptime a conciencia a 3000 (es el único parámetro que he cambiado, el resto está como siempre lo he tenido), a excepción de min_pan_speed que en otras versiones lo tenía a 0 para evitar las oscilaciones, pero me provocaba un error de 2 a 4 grados por la rigidez que provoca en el servo pan. Aqui lo pongo a 8 u 10 y el error es de 1 grado. No se debe a ningún error de la nueva versión, lo hacía antes porque no me gustaba ver una pequeña corrección, yo asumía el error y punto.

Pero para probar la nueva versión y evitar que ese error inducico por tener el servo "amarrado" se solapara con el error por truncamiento de las posiciones GPS (es que de 250 en 250 hay tan poca distancia recorrida que debía asegurarme que el error del heading es el menor posible).

Total, todo ésto para decir que yo no noto desfase estando en modo CLI. Esta tarde haré pruebas ya con telemetría para asegurarme que va bien.

rortega
23/03/2016, 09:28
Me ha dado tiempo probar, y lo mismo, no noto desfase, es el mismo comportamiento en CLI que enviando telemetría. Me apunta al notre 2 o 3 grados a la izquiera o a la derecha dependiendo de desde donde venga y lo fuerte que venga...

Simba
23/03/2016, 09:28
Esa oscilación de +-2° en el dispar por perturbación de la brújula yo también la tengo desde siempre en la Flip32.
Turruk también la tiene.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
23/03/2016, 09:31
Eso último que dices es el motivo por el cual yo reajuste los PID para bajar el error final al mínimo, pero a mi me daba más error del o den de +- 10°

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
23/03/2016, 11:07
Estoy pensando en la idea de rellenar los huecos de las tramas erróneas con posiciones estimadas. Eso evitaría algunas pausas y retrasos

Guillesan
23/03/2016, 11:12
Buenos dias, tienes cuantificado la cantidad de erroreres ? . Pienso que es mas importante saber cuantos errores hay para atajar a posteriori esos errores. Realmente hay muchos errores ? no lo se.

rortega
23/03/2016, 12:24
Buenos dias, tienes cuantificado la cantidad de erroreres ? . Pienso que es mas importante saber cuantos errores hay para atajar a posteriori esos errores. Realmente hay muchos errores ? no lo se.
En uno de los archivos que me pasaste el 50% de tramas eran erróneas.

Trabajaré en hacer ese log cuando vuelva de semana santa

Simba
23/03/2016, 12:34
Buenos dias, tienes cuantificado la cantidad de erroreres ? . Pienso que es mas importante saber cuantos errores hay para atajar a posteriori esos errores. Realmente hay muchos errores ? no lo se.
Yo tampoco lo se pero creo o sospecho que son mas bien pocos, sobre todo en las inmediaciones del Traker.
No se cual es la efectividad de la alarma del Orange, me refiero al Buzzer que pita, cuando hay perdida de paquetes de Telemetria, y en nuestro caso estamos volando, sin ni siquiera un solo pitido en distancias de 5 Km, y cerca con mas razón, el enlace no pita na de na.

Otra cosa que tenemos observado, es que en presencia de algún compañero, en mi caso TURRUK, que vuela algunas veces con Dragonlink, me interfiere el Orange, y aunque el mando sigue funcionando bien, la Telemetria la deja prácticamente anulada, con lo cual PITA y no para, y ademas el Traker se queda mas parao que una estatua.

Comento todo esto, para que seamos conscientes de como va la cosa.

Con el Orange al menos en GPS-Telemetry, si no pita no notamos perdida de paquetes, y por lo tanto se supone que no tenemos perdida de Tramas GPS, aunque es mucho suponer.

Guillesan a ver si eres capaz, de tomar datos de las Tramas en vuelo, y salimos de dudas.

rortega
23/03/2016, 14:56
Yo tampoco lo se pero creo o sospecho que son mas bien pocos, sobre todo en las inmediaciones del Traker.
No se cual es la efectividad de la alarma del Orange, me refiero al Buzzer que pita, cuando hay perdida de paquetes de Telemetria, y en nuestro caso estamos volando, sin ni siquiera un solo pitido en distancias de 5 Km, y cerca con mas razón, el enlace no pita na de na.

Otra cosa que tenemos observado, es que en presencia de algún compañero, en mi caso TURRUK, que vuela algunas veces con Dragonlink, me interfiere el Orange, y aunque el mando sigue funcionando bien, la Telemetria la deja prácticamente anulada, con lo cual PITA y no para, y ademas el Traker se queda mas parao que una estatua.

Comento todo esto, para que seamos conscientes de como va la cosa.

Con el Orange al menos en GPS-Telemetry, si no pita no notamos perdida de paquetes, y por lo tanto se supone que no tenemos perdida de Tramas GPS, aunque es mucho suponer.

Guillesan a ver si eres capaz, de tomar datos de las Tramas en vuelo, y salimos de dudas.
No se trata sólo de perder tramas, sino de que lleguen incompletas o corruptas.

Simba
23/03/2016, 16:24
En uno de los archivos que me pasaste el 50% de tramas eran erróneas.

Trabajaré en hacer ese log cuando vuelva de semana santa

A pues, con un 50% de corruptas, eso ya es otra cosa.
Si Guillesan te mando un log normal y bien tomado, de un GPS- Telemetry del Orange, la cosa pinta de un modo muy diferente al que yo pensaba.

En este caso, del sistema predictivo tomo mucha importancia.

rortega
23/03/2016, 16:58
El parece que tenía problemas con el bluetooth.

Simba
23/03/2016, 21:17
Hola, reporto resultado de vuelo de esta tarde.
La nave de esta tarde ha sido el Ala, y el resultado de seguimiento francamente muy bueno.
Después de haber corregido el Pan 0 a 1510, ya no se nota diferencia de seguimiento en los dos sentidos.

Resumiendo que según Turruk, ya se le puede dar al Traker 32 bits, el certificado aeronáutico, con eso lo digo todo.

Ale ya esta.

rortega
23/03/2016, 21:25
Hola, reporto resultado de vuelo de esta tarde.
La nave de esta tarde ha sido el Ala, y el resultado de seguimiento francamente muy bueno.
Después de haber corregido el Pan 0 a 1510, ya no se nota diferencia de seguimiento en los dos sentidos.

Resumiendo que según Turruk, ya se le puede dar al Traker 32 bits, el certificado aeronáutico, con eso lo digo todo.

Ale ya esta.

!Joder, qué buena noticia!!!!

¿No hay vídeo?

Yo compilando el código para sacar log de datos por puerto serial como telemetría de salida.

Ya no me va a dar tiempo probarlo hoy, pero está casi listo para cuando vuelva el martes por la tarde ver si funciona.

Simba
23/03/2016, 21:36
No vídeo no hay, me he olvidado de coger la Mobius, así no pego la paliza con el vídeo, pero vamos seria igual al de ayer, pero con el Ala y con el mismo +- desplazamiento a los 2 lados.
En tierra en la misma prueba que ayer, se nota mucho el ajuste de Pan 0, y prácticamente es un tiro, luego en vuelo pues igual, con un poco de retraso natural por la velocidad, en las cercanías que mas depende de la velocidad del servo, que de la respuesta del soft.

En Tilt le veo que después de todo, le hace falta un servo un poco mas enérgico, pero de momento se queda como está, que esta suficientemente bien.

carabin
24/03/2016, 00:00
Simba eres un máquina probando , enhorabuena a todos por el exito

Simba
24/03/2016, 00:34
Hola Carabin, aquí el éxito o el fracaso, es de todos.
A ver si en tu próxima visita lo vemos funcionando.
Sl2

JuanTrillo
24/03/2016, 00:49
un pequeño offtopic. ¿Alguno de los que lo teneis terminado ireis a Daimiel?

Enviado desde mi X16 mediante Tapatalk

carabin
24/03/2016, 00:50
Estoy en pruebas , le he metido un servo digital bueno a la de 8 bits y ayer cuando dijo Raúl que el llevaba el pan0 a 1528 lo fui subiendo y ajustando con el potenciómetro lo he dejado en 1525 ya que yo lo tenía ajustado a 1500 y no era capaz de que fuera medianamente bien en los 4 puntos , ahora se puede decir que obedece bastante bien , seguiré probando con la de 32 bits, pero esto ya tiene otra pinta.:wink2:

rortega
24/03/2016, 07:30
Estoy en pruebas , le he metido un servo digital bueno a la de 8 bits y ayer cuando dijo Raúl que el llevaba el pan0 a 1528 lo fui subiendo y ajustando con el potenciómetro lo he dejado en 1525 ya que yo lo tenía ajustado a 1500 y no era capaz de que fuera medianamente bien en los 4 puntos , ahora se puede decir que obedece bastante bien , seguiré probando con la de 32 bits, pero esto ya tiene otra pinta.:wink2:
Hace tiempo comenté lo del valor 1528 con mi servo, y el motivo por el cual esa cifra era distinta en el firm de 8 bits tratándose del mismo servo. Y es que en el firm de 8bits los PIDs están actuando cuando estamos ajustando ese valor. En 32bits no actúan durante el ajuste, y el valor que se consigue es más exacto.

El problema que tiene el ajustar ese valor es que como no lo ajustes bien, después necesita en términos relativos un incremento de pulso mayor hacia un sentido que hacia el otro, con todas las consecuencias que tiene luego en el comportamiento del tracker.

rortega
24/03/2016, 07:39
Simba, yo supongo que se te habrá pasado por la cabeza, pero no te ha dado por probar ésto de la predicción con el sistema NOPID? tiene que ser mucho más rápido ajustando el valor de nopid_max_speed, lo único es que puede que vaya todo el tiempo por delante del avión. En ese caso bajando el valor de gps_gain se podría i tentar conseguir que no se adelante demasiado.

Simba
24/03/2016, 16:16
Simba, yo supongo que se te habrá pasado por la cabeza, pero no te ha dado por probar ésto de la predicción con el sistema NOPID? tiene que ser mucho más rápido ajustando el valor de nopid_max_speed, lo único es que puede que vaya todo el tiempo por delante del avión. En ese caso bajando el valor de gps_gain se podría i tentar conseguir que no se adelante demasiado.
Bueno a mi la verdad es que no, por que como estaba probando con PIDs, no era cuestión de ir mezclando cosas, pero el inquieto de Turruk si que lo ha probado, a nivel simulador por no disponer en estos momentos de medios, y me comento que le funciona muy bien.

Sera cuestión de probar el NOPID.

¿No sabemos nada de Guillesan? lo mismo estará de capuchino.

rortega
24/03/2016, 17:14
Pues me he traído conmigo varios Papers (artículos científicos) sobre modelos/sistemas de predicción, corrección de errores, etc, para posicionamiento GPS, para ir entretenido en el avión ... Y entre ellos he encontrado algo interesante que podría aplicarlo y ayudar a mejorar el seguimiento.

Partimos de la base de que el sistema que he ideado no intenta minimizar errores. No obstante parece ir bien porque en parte ese trabajo lo hace el sistema PID.

Entre los posibles sistemas está el filtro Kalman, pero necesitaríamos tener datos de la IMU del avión, y no todos los protocolos implementados los suministran. Además el coste en tiempo de ejecución es grande.

Seguiré estudiando este tema, pero para ello tengo que subir la versión que permite envía todos los datos por telemetría de salida, para que me hagáis capturas con datos de vuelo real y hacer unos cuantos análisis a ver que se puede mejorar y si es o no necesario meter un sistema que tenga cuantifique y se adapte al error en tiempo real...

Simba
26/03/2016, 01:19
Raul y compañia, he estado probando a nivel simulador, el NOPID y el resultado es bueno, pero me gusta bastante mas el PID.
La razón principal es que al poner el NOPID, me aparece un desfase a izquierdas de casi 20º, solo a izquierdas con lo cual me está diciendo que debería volver a ajustar el Pan 0, al contrario de como lo tuve que ajustar, para está versión y PIDs, con local no tengo ganas de volver a ajustar mas y mas.

Con los PIDs bien ajustados y dándole una Gain de GPS de 30, el funcionamiento es sencillamente genial, rápido en las inmediaciones y sobre el Traker, y fluido en vuelo mas lejano, con cierto sentido de predicción, que se aprecia en el oled, entre el valor de H y A, siendo siempre 1º o 2º adelantado el H al A, con esto creo que nos aseguramos el seguimiento, por que ese pequeño adelanto, es el que nos ayuda a vencer las inercias.

Tan solo le he subido el Gain de GPS de 25 a 30, pero se nota bastante, y si lo subo a 40, en algún momento de gran velocidad, al sobrevolar el Traker, tiende a retroceder y genera fuertes contramarchas. Con 30 en mi caso creo que da el mejor resultado.

Yo de momento ya no lo toco.

Sl2

rortega
26/03/2016, 10:00
Raul y compañia, he estado probando a nivel simulador, el NOPID y el resultado es bueno, pero me gusta bastante mas el PID.
La razón principal es que al poner el NOPID, me aparece un desfase a izquierdas de casi 20º, solo a izquierdas con lo cual me está diciendo que debería volver a ajustar el Pan 0, al contrario de como lo tuve que ajustar, para está versión y PIDs, con local no tengo ganas de volver a ajustar mas y mas.

Con los PIDs bien ajustados y dándole una Gain de GPS de 30, el funcionamiento es sencillamente genial, rápido en las inmediaciones y sobre el Traker, y fluido en vuelo mas lejano, con cierto sentido de predicción, que se aprecia en el oled, entre el valor de H y A, siendo siempre 1º o 2º adelantado el H al A, con esto creo que nos aseguramos el seguimiento, por que ese pequeño adelanto, es el que nos ayuda a vencer las inercias.

Tan solo le he subido el Gain de GPS de 25 a 30, pero se nota bastante, y si lo subo a 40, en algún momento de gran velocidad, al sobrevolar el Traker, tiende a retroceder y genera fuertes contramarchas. Con 30 en mi caso creo que da el mejor resultado.

Yo de momento ya no lo toco.

Sl2
Pues ya tenemos otra cosa clara.

Simba
26/03/2016, 16:43
Raul estoy renderizando y subiendo el ultimo de vídeo de hoy mismo, creo que es muy ilustrativo de como funciona, con los últimos ajustes de gain gps a 30.

En la imagen se ve prácticamente siempre el avión, cosa que antes era mucho mas difícil, ahora se nota que tiene mas agilidad.

En el primer despegue estaba mal configurado el OSD, ( lo estrenaba en ese vuelo) y tenia invertido para el AP , el sentido de giro de profundidad y alabeo, ha resultado un puro chou, luego lo he corregido y ya va bien.

javiec
26/03/2016, 16:54
Visto los avances el no pasar a 32bit parece ser que es un atraso considerable pero creo que sigo con la misma licitación... Mi servo esta invertido y creo que la última vez que os pregunté aún no estaba implementado verdad?

Que tengo que hacer para invertirlo?

Gracias!

Sent from my Redmi Note 3 using Tapatalk

Simba
26/03/2016, 17:31
Visto los avances el no pasar a 32bit parece ser que es un atraso considerable pero creo que sigo con la misma licitación... Mi servo esta invertido y creo que la última vez que os pregunté aún no estaba implementado verdad?

Que tengo que hacer para invertirlo?

Gracias!

Sent from my Redmi Note 3 using Tapatalk
Hola es muy sencillo, intercambia los cables del motor, creo que ya lo hemos comentado.
No creo que a estas alturas se cambie nada en el 8 bits.

javiec
26/03/2016, 17:52
Hola es muy sencillo, intercambia los cables del motor, creo que ya lo hemos comentado.
No creo que a estas alturas se cambie nada en el 8 bits.
Con cables del motor te refieres a abrir el servo e invertir los cables no?

Sent from my Redmi Note 3 using Tapatalk

Simba
26/03/2016, 20:51
Guillesan, tenemos la posibilidad de disponer de un Firm para el Rx Orange, que es capaz de transmitir telemetria Mavlink, (solo posición GPS) por puerto serie.
Dirás ¿y eso para que?, yo ya la mando tal como sale del OSD MFD.

Pues eso que no hace falta que le mandes la telemetria Mavlink del MFD, le puedes mandar la posición GPS, de la Telemetria Mavlink, solo la GPS, el resto lo filtra y así no desbordamos el puerto serie.

Se trata de meter todo el Mavlink y el Rx Orange, la filtra y extrae solo el GPS. Latitud, Longitud y Altura, y no le falla ni una trama.

Le podemos sacar Mavlink de la Flip 32, de una placa APM o de lo que sea que saque Mavlink, y meterla literal al Orange.

¿Como lo ves?

Simba
26/03/2016, 20:52
Eliminado

Simba
27/03/2016, 16:02
Con cables del motor te refieres a abrir el servo e invertir los cables no?

Sent from my Redmi Note 3 using Tapatalk
Si claro eso solo, siempre que el servo ya este preparado para 360°.

Enviado desde mi GT-I9505 mediante Tapatalk

Simba
27/03/2016, 16:09
Hola, ¿podéis ver el vídeo que puse ayer del Tarker?.

Es que lo edite para quitarlo y puse otro que se tiene mejor resolución, pero creo que no esta bien subido.
Yo en Tapatalk no lo veo.

Simba
27/03/2016, 16:11
Por si acaso es este:

https://www.youtube.com/watch?v=2FFXlNDjZcg

rortega
29/03/2016, 22:02
Ya estoy de vuelta, ví el vídeo estando en España pero no pude dedicar tiempo a contestar, a parte lo ví desde el móvil y me era muy difícil ver el avión. Ahora ya lo he visto en el ordenador, y bueno, parece que va bien ¿No?

rortega
29/03/2016, 22:19
Mañana le daré un repaso al código que envíará el log como telemetría de saida, lo dejé casi preparado antes de irme. Me gustaría que hiciérais alguna captura una vez que actualice la versión. No hará falta cambiar ningún parámetro, tan sólo especificar el código correcto en el comando serial para que saque los datos de log en lugar de la conversión a otro protocolo.

Simba
29/03/2016, 22:20
Hola Raúl ya suponía que andabas ocupado.
Pues la verdad es que de todo lo que he probado, este setup tal como está, es lo que mejor respuesta da.
Se nota mucho el efecto predictivo, aunque no lo parezca, y pese a que aún no entiendo, que es lo que hace cuando no le faltan Tramas, lo que hace es darle esa gracia especial, para que el seguimiento parezca fácil.

Enviado desde mi GT-I9505 mediante Tapatalk

rortega
29/03/2016, 22:23
Bueno, hoy no estoy haciendo nada, con el madrugón del viaje (pesado), y recuperar horas en el trabajo esta tarde, estoy bien servido.

rortega
31/03/2016, 23:08
Ya estoy haciendo algunas pruebas de captura de los datos que se envían a modo de telemetría de salida.

En la siguiente gráfica se ve en rojo la posición estimada, y en azul la real. El punto negro es donde estaría situado el tracker.

Aún me queda por incluir algún campo más en los datos que se capturan para poder estimar cuanto error se puede estar cometiendo. Ésto que muestro es sólo preliminar, aunque ya puede ir dando una idea de como se comporta el sistema de predicción.
http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64608&stc=1&d=1459457995

rortega
02/04/2016, 19:12
Mañana tengo previsto realizar pruebas reales con protocolo FRSK-D si no hace mal tiempo. Veré con mis propios ojos como funcionan los 32bits...

rortega
02/04/2016, 19:42
No sé su lo he comentado alguna vez, pero si se usa un módulo bluetooth en el puerto de telemetría, con el blueterm en el móvil no es necesario llevarse un ordenador al campo, desde esa aplicación se puede entrar en modo Cli como lo hacemos en el ordenador. Así mañana podré ajustar el gps_gain y hacer varias capturas a ver que saca.

Guillesan
05/04/2016, 16:32
Hola a todos, he estado un poco parado por reparaciones varias, de hecho aun sigo.
Raul tengo una cosita a pedirte revises, he podido introducir tramas mavlink enteras provienen de una pixhawk , el casoes que en la antena el numero de saltelites de mavlink entrante los cuenta mal, si son menos de 10parece que funciona pero si se pasa a dos digitos marca mal numeros raros como 25 o cosas asi. podrias mirar si esta mal algo , gracias .
Ah suerte en las pruebas de campo yo en cuanto tenga algo que vuele lo seguire probando.

rortega
05/04/2016, 19:36
Pues la verdad es que las pruebas fueron nefastas. Me llevé por error al campo un módulo bluetooth configurado a 115200 y el otro a 9600, los puse así y la telemetría funcionaba, pero aquello metía muchos errores en las tramas.

Y eso no es todo, resulta que el firmware del multicóptero (cleanflight) envía una trama GPS por segundo, es decir, una .... iba a decir una palabrota. Así que ando haciendo pruebas y más pruebas, y he modificando el código de cleanflight para que no envíe ninguna trama adicional por telemetría, tan sólo las de GPS cada 200 milisegundos, con lo que el seguimiento ya ha mejorado algo.

Ahora me queda configurar el GPS para que trabaje a 5HZ, pues lo tengo a 1HZ desde los inicio.

También estoy viendo la forma de meterle a través del enlace FrSky tramas en formato LTM, que son más livianas, y además tienen control de errores, así descarto las tramas erróneas que me mete FrSky y que provoca que de vez en cuando el tracker apunte a otro lugar. Éste es un tema conocido que también me sugería Samuel implementar para evitar lo de las tramas erróneas.

Aprovechando que estoy haciendo pruebas, he estado viendo el tema de los satélites y no me parece que lo haga mal ¿Tú estás aún con alguna versión antigua?

rortega
07/04/2016, 08:42
Esta tarde toca otra vez pruebas FrDky D. Tengo configurado el gps sólo con tramas GGA a 4Hz y he modificado el firm del multi para que transmita también a 4Hz.

Así que mi receptor RX sólo va a transmitir a la estación de tierra tramas de GPS, no teniendo que transmitir ni cuna otra trama de otros sensores me aseguro de que cada 250 ms el tracker recibe una trama GGA.

Espero que así no lleguen muchas tramas corruptas, pues le da margen al enlace FrSKy.

Guillesan
07/04/2016, 10:11
Bueno espero salgan las pruebas mejor que la ultima vez, aqui espero tus resultados. Suerte

rortega
07/04/2016, 19:10
Ya he podido realizar hoy la prueba. Se trata de una prueba con el dron en la mano.

En el vídeo se aprecian algunos movimientos herráticos, se deben al problema de datos corruptos que conlleva usar FrSky D, pues no hay byte de control de errores. Es algo que ya tengo constatado, a lo que estoy tratando de ponerle solución cara al futuro.

Cuando le llegan tramas buenas el seguimiento es "normal". Debido a que la señal satélite no parece muy buena (consigo entre 5 y 8 satélites) hay errores de hasta 24 metros. Es algo que se puede comprobar dejando el dron junto al tracker, pulsar el botón HOME y ver como la distancia oscila constantemente debido a los errores de posición. De ahí que las predicciones algunas veces lo adelante más de la cuenta y otras veces se queda retrasado.

Este tema de la precisión del GPS creo que es mayor escollo con el que se encuentra cualquier tipo de desarrollo similar.

https://www.youtube.com/watch?v=TJ3ju5d05Mc

TURRUK
07/04/2016, 23:19
Hola muy buena prueba, si que se nota poco inpresesion peor no esta mal . Yo tambien queiro usar el telemetria Frsky D, falta estudiar como se ajusta todo.:plane:

rortega
07/04/2016, 23:35
La versión del firmware que estoy manejando es la 5.1, que aún no es subido al repositorio. La única diferencia que tiene con la 5.0 es el sistema de envío como telemetría de salida datos de la posición real y la estimada.

Ésto me permite hacer análisis que antes eran imposibles, como por ejemplo ver cuánto tiempo transcurre entre tramas recibidas. En mi caso es importante hacer este análisis porque el protocolo FrSky no sólo mete en el canal las tramas con los datos de GPS. Como he comentado algún mesnaje más atrás, he modificado a conciencia el firmware que controla el multi para ver si realmente enviaba tramas cada 250ms, y el resultado (que no me pilla de sorpresa) es bastante decepcionante.

Lo que se ve a continuación es un histograma de frecuencias de los tiempos transcurridos entre las 146 tramas que he guardado en el log mientras me paseaba con el dron en la mano.

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64675&stc=1&d=1460065465

La primera columna indica que hay unas 40 tramas por debajo de medio segundo (en el mejor caso 270 milisegundos), unas 50 tramas entre medio y 1 segundo, unas 10 entre 1 y 1,5 segundos, unas diez entre 1,5 y 2 segundos, etc...

Se puede observar como algunas veces transcurren varios segundos entre trama y trama, y en el mejor de los casos sólo han transcurrido 270 ms, pero hay muchos casos de más de medio segundo, incluso algunos de 4, 5, 6 y 8 segundos. Éstos son los datos de los que extraigo esa gráfica:

505 3850 1035 449 470 4397 4519 1080 459 453 505 449 5857 1088 417 7376 498 996 2786 544 2299 6505 453 449 2340 2551 4278 1035 505 453 547 488 470 625 280 3341 582 453 3358 1073 334 1814 639 842 384 1309 1308 378 1312 2284 2207 617 372 386 2376 1540 1905 783 2242 472 491 916 449 547 4071 1007 414 1716 659 1660 707 663 1825 467 1702 1130 452 1621 586 509 491 3551 449 2390 919 1000 411 3403 586 414 2836 1031 414 586 576 873 509 604 277 4481 530 410 511 449 961 625 410 548 621 375 582 515 586 3281 1491 2776 449 586 506 491 544 449 544 3982 579 495 410 537 453 561 4278 1554 414 509 8895 1544 621 2617 5576 453 505 7919 3063 501 937

Además, hay varias tramas en las que la latitud pasa a negativa de repente, y alguna en la que la longitud pasa a valores bajos, lo que provoca que el dron virtualmente esté a miles de metros, incluso miles de kilómetros.

Simplemente viendo estas dos cosas se explica el comportamiento obtenido. Creo que si envío tramas cada medio segundo los resultados van a ser aún peores, porque todas las tramas, buenas o malas, estarán muy por encima de medio segundo.

rortega
07/04/2016, 23:41
Hola muy buena prueba, si que se nota poco inpresesion peor no esta mal . Yo tambien queiro usar el telemetria Frsky D, falta estudiar como se ajusta todo.:plane:
Turruk, fíjate en el mensaje que he publicado, lo estaba escribiendo mientras tu contestabas... Creo que FrSky D no es una opción.

Yo estoy trabajando en mejorar el protocolo, pero lo único que voy a conseguir es corregir errores descartando tramas corruptas, y eso va a tener como consecuencia emplear más tiempo entre tramas buenas.

Tengo curiosidad por hacer este mismo análisis con GPS_TELEMETRY sobre ORANGE RX, estoy pensando en dejar de lado la telemetría FRSKY...

rortega
08/04/2016, 00:17
Ojo, las pruebas que yo hago es enviando únicamente lo que necesito, pero si usamos el protocolo FrSky D tal cual és, enviando datos de varios sensores, lo normal es que las tramas de datos de posición, altitud y velocidad se envíen juntas cada 1 segundo, alternándose este paquete con otros paquetes más pequeños que se mandan con mayor frecuencia.

Éste test que yo estoy haciendo es para ver si el protocolo FrSky D es capaz de enviar esos 33 bytes de golpe cada 250 milisegundos, pero a la vista de los resultados se ve que clarametne que no.

El motivo por el cual en el mejor de los casos he obtenido esos 270 milisegundos se debe a que en algún momento me ha enviado toda la trama completa sin intercalar esas tramas que desconozco lo que son.

Resulta que FrSKY D recomienda no enviar más de 120 bytes por segundo. Yo al enviar 33+33+33+33 (33 cada 250ms), supero ese límite, por lo que se produce pérdida de datos, espaciándose en el tiempo...

Mañana voy a volver a probar con 250 milisegundos, pero reduciendo el tamaño del paquete a 27 bytes, omitiendo 6 bytes de velocidad que no uso para nada. Espero que así vaya mejor, y si no lo consigo bajaré la frecuencia a 300 milisegundos. Si me llegan tres tramas buenas por segundo me doy con un anto en los dientes.

rortega
09/04/2016, 08:53
Se confirman mis sospechas, conforme disminuyo la frecuencia a la que envío tramas desde el multi (subo los milisegundos), aumenta el tiempo entre trama y trama que le llegan al tracker.

Sin embargo ya no se producen retrasos de 4, 6 y hasta 8 segundos y los datos son más fiables, hay menos tramas corruptas (antes no es que hubiese muchas, pero las pocas que había implicaba que el tracker apuntase al infinito).

Pero el tiempo medio entre trama y trama siempre muy alto, en torno al segundo.

Aquí unas muestras:

Tramas de 27 bytes a 250 milisegundos:

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64689&stc=1&d=1460184660

Tramas de 27 bytes a 300 milisegundos:

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64690&stc=1&d=1460184660

Tramas de 27 bytes a 350 milisegundos:

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64691&stc=1&d=1460184660

rortega
13/04/2016, 08:55
A raíz de las pruebas de campo con FRSKY D, estoy intentando darle una nueva vuelta de tuerca al sistema de predicción para que rellene los huecos...

Esas tramas que llegan mal o llegan más tarde de lo esperado serán "suplantadas" por datos de predicción basados en la velocidad y en el tiempo transcurrido desde la última trama buena.

Con este sistema espero que la fluidez en RL seguimiento ses mucho mejor y con menos anticipación, parada y correcciones hacia atrás.

Y os contaré si funciona o no...

Guillesan
13/04/2016, 09:06
Muy bien Raúl, en mi caso estoy un poco en dique seco, por reparaciones, pero atento a las novedades. En cuanto pueda sigo con las pruebas. Saludos

Simba
13/04/2016, 09:19
Ok Raúl yo también sigo atento a todo, pero como Guillesan estoy en reparaciones, en mi caso domesticas y he dejado los trastos por unos días.

Enviado desde mi GT-I9505 mediante Tapatalk

TURRUK
13/04/2016, 09:58
Hola , como siempre +1.:plane:

rortega
17/04/2016, 20:38
Bueno, tenemos novedades, a falta de realizar pruebas de campo reales, os muestro a continuación en un vídeo cómo se comporta el tracker con el nuevo sistema de predicción que he implementado.

Os explico lo que váis a ver en el vídeo, y al mismo tiempo voy describiendo el sistema de predicción para que se entienda lo mejor posible. Luego podéis pasar a verlo...

Supongamos que la telemetría del avión sólo nos da una trama por segundo (1hz = 1 segundo = 1000 milisegundos). Todos los que hemos trasteado con el tracker sabemos lo que este hará, se moverá haciendo pausas entre trama y trama, sin continuidad, salvo que pasemos el dron prácticamente por encima.

Con el sistema de predicción que ya habéis probado, cada vez que se recibe una posición gps válida (A), se calcula la velocidad, el rumbo, y el tiempo transcurrido con respecto a la anterior posición válida (U), y estima la siguiente posición a la que posiblemente se moverá el dron, dando por hecho que seguirá el mismo rumbo y llevando la misma velocidad, pero aplicándole un valor de ganancia. Ésto mejora considerablemente el comportamiento del tracker, pues nos permite hacer que se anticipe, de modo que ya no va todo el tiempo retrasado con respecto al avión.

http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64811&stc=1&d=1460916771

El nuevo sistema de predicción que he implementado añade a éso un proceso de muestreo y estimación cíclico, de modo que no nos quedamos esperando a recibir una nueva posición válida, ese tiempo entre posición y posición lo dividimos en intervalos y, cada 250 milisegundos, en los tiempos t1, t2 y t3, lo dedicamos a estimar las posiciones e1, e2, e3, siempre basados en los datos de velocidad y rumbo que llevábamos, calculados a partir de las dos últimas posiciones reales recibidas (U) y (A).


http://www.aeromodelismovirtual.com/attachment.php?attachmentid=64812&stc=1&d=1460916771

De esta forma, y como se puede ver en el vídeo, el movimiento del tracker es menos pausado, dando sensación de movimiento más fluído.

El vídeo muestra el seguimiento que hace el tracker a 4 frecuencias de muestreo distintas, recibiendo por telemetría una trama por segundo desde el dron.

Las pruebas se han realizado inteantando simular que estmos en el campo de vuelo y volando el avión a unos 100 metros paralelo a la pista. El piloto está mirando hacia el sur, de modo que hacemos una pasada en un sentido (de Oeste a Este) y otra pasada en sentido contrario (de Este a Oeste), a una velocidad constante (100 km/h creo recordar).

Todos los parámetros de configuración del tracker son constantes en todas las pruebas, salvo el parámetro de frecuencia de muestreo. El parámetro de ganancia está al 100%, es decir, la distancia no se amplifica ni reduce.

Para no tragarnos un tocho de grabación y poder comparar, he cortado las secuencias y he hecho el siguiente montaje.

Primero veremos como se comporta con una frecuencia de muestreo de 1 segundo (1000 milisegundos = 1 herzio), es decir, que no se van a producir estimaciones entre las posiciones válidas, tan sólo una estimación cada vez que se recibe una trama nueva, por lo que se comportará como en el sistema de predicción antiguo, haciendo pausas.

Luego veremos el comportamiento si realizamos un muestreo cada 500 milisegundos (2 herzios). Aquí ya empezamos a ver menos pausas.

Luego, en la tercera secuencia muestrea a 250 milisegundos (4 herzios), donde vermos que el movimiento es más fluído.

Y finalmente se verá el comportamiento con un muestreo de 125 milisegundos (8 herzios), que no dista mucho de lo observado a 250 milisegundos.

Posteriormente se visualizan las 4 secuencias juntas, y se repite varias veces para no tener que andar reproduciendo el vídeo una y otra vez.


https://www.youtube.com/watch?v=6ClzYx2I5gQ

Guillesan
17/04/2016, 20:47
Vaya currazo. Viendo el vídeo me da la impresión que el más acertado es 250 ms a vosotros que os parece?

rortega
17/04/2016, 20:50
Además, hay otra novedad, el error provocado por el truncamiento de un decimal en la latitud y longitud se ha eliminado no truncando ese decimal. Aunque en el display OLED aparezcan 5 decimales, todos los cálculos se hacen con 6.

Estos días andaré corrigiendo problemas que surgen a raiz de éste cambio, pues los cálculos con 5 decimales están en gran parte del código y afecta a todos los protocolos. De momento está corregido para GPS TELEMETRY de entrada y para FRSKY D, aunque este último aún no lo he probado. También afecta a la telemetría de salida.

rortega
17/04/2016, 20:52
Vaya currazo. Viendo el vídeo me da la impresión que el más acertado es 250 ms a vosotros que os parece?

Sí, esa es la impresión que me da a mí. Para que el de 125 ms se comporte mejor habría que tocar el parámetro de la ganancia.

Llevo ya unos cuantos días dándole a la perola y he realizado un millón y medio de pruebas, para al final tener estos resultados. En cuando deje de llover haré una prueba real con FRSKY D, que espero se comporte mucho mejor que lo que vimos en el vídeo de hace una semana.

Guillesan
17/04/2016, 20:58
Espero poder en poquito volver a las pruebas, ya dirás cuando liberas esa version

TURRUK
17/04/2016, 21:17
Hola eso promete ,tengo ganas de probar, esta version.:biggrin2:

TURRUK
17/04/2016, 21:27
Perdon.

TURRUK
17/04/2016, 21:45
:plane:

Simba
17/04/2016, 22:29
Hola, según entiendo yo, las 4 pruebas están realizadas con telemetria a 1 Hz, o sea que solo tenemos datos cada 1 segundos, y por lo tanto todo lo que sucede entre cada segundo, lo creas calculando a base de los datos del ultimo segundo bueno recibido.
Luego en cada prueba le metes simulación estimada, para simular como si recibieras 2hz, 4hz y 8hz, pero simulado mediante el calculo predictivo.

Esto que comento, es mas que nada para que me confirmes, que estoy en lo cierto.

Pues me parece que en funcionamiento real, va ha ser muy muy fino, y se va a notar mucho, ahora bien si volvéis atrás, y miráis el vídeo ultimo que yo puse, tendréis una idea de como funcionara, cuando se reciben datos buenos reales a 4 hz, que es o sera lo mismo o muy parecido, a la prueba de recibir datos a 1 hz y simular que se reciben 4 hz mediante predicción.

Resumiendo, que si esto funciona como creo que funciona, y partiendo de que ya estamos con telemetria a 4 hz, lo mejor y mas efectivo seria, que la secuencia de calculo predictivo, se la pongas a 8 hz.

Si todo va correcto y no tenemos perdida de datos, siempre tendremos un sistema de refresco real a 4 hz, pero realmente por predicción, estaremos funcionado como si realmente tuviéramos el GPS a 8hz.

Creo que a falta de prueba real, esto promete y mucho.

Simba
17/04/2016, 22:38
Raul, tu creo que siempre estas con el tema de predicción, en el supuesto de perdida de datos, por la causa que sea.

Bien pues a falta de que se me demuestre lo contrario, yo creo que en distancias cortas, digamos por decir algo hasta los 500m, la perdida de datos es insignificante o sea que no tenemos perdida de posición.

En cambio en mis ultimas pruebas, pese a la NO falta de datos, gracias al sistema de predicción y anticipación, supongo que por lo de la ganancia, el caso es que el funcionamiento del Traker, fue con mucho el mejor de todos los probados, y me atrevo a decir que el único que mejoro y mucho a nuestro amado sistema de 8 bits.

Bueno al final todo consiste en probar y salir de dudas.

rortega
17/04/2016, 23:20
Hola, según entiendo yo, las 4 pruebas están realizadas con telemetria a 1 Hz, o sea que solo tenemos datos cada 1 segundos, y por lo tanto todo lo que sucede entre cada segundo, lo creas calculando a base de los datos del ultimo segundo bueno recibido.
Luego en cada prueba le metes simulación estimada, para simular como si recibieras 2hz, 4hz y 8hz, pero simulado mediante el calculo predictivo.

Esto que comento, es mas que nada para que me confirmes, que estoy en lo cierto.

Pues me parece que en funcionamiento real, va ha ser muy muy fino, y se va a notar mucho, ahora bien si volvéis atrás, y miráis el vídeo ultimo que yo puse, tendréis una idea de como funcionara, cuando se reciben datos buenos reales a 4 hz, que es o sera lo mismo o muy parecido, a la prueba de recibir datos a 1 hz y simular que se reciben 4 hz mediante predicción.

Resumiendo, que si esto funciona como creo que funciona, y partiendo de que ya estamos con telemetria a 4 hz, lo mejor y mas efectivo seria, que la secuencia de calculo predictivo, se la pongas a 8 hz.

Si todo va correcto y no tenemos perdida de datos, siempre tendremos un sistema de refresco real a 4 hz, pero realmente por predicción, estaremos funcionado como si realmente tuviéramos el GPS a 8hz.

Creo que a falta de prueba real, esto promete y mucho.


Así es Simba, la telemetría llega a 1 Hz, y los muestreos/predicciones las hago a 1hz, 2hz, 4hz y 8hz.

Quizás en tu caso que recibes telemetría a 4 Hz no notes una mejora muy grando, salvo que estés perdiendo tramas por fallos de las comunicaciones, que no me extrañaría por lo que se apreciaba en tu vídeo.

Tengo una teoría, y es que el hecho de poner la frecuencia de muestreo a 8 hz no creo que vaya a dar mejor resultado que si la pones a 4 hz, a no ser que volásemos muy, pero que muy rápido, y muy pero que muy cerca. Y por supuesto, a larga distancia como que tampoco tiene muchas ventajas.

Si lo pones a 4 hz, debería funcionarte mejor que como te funciona ahora, por el hecho de que seguramente estás perdiendo tramas (Guillesan estaba perdiendo muchísimas) y este sistema sería la forma de rellenar esos huecos que te faltan.

rortega
17/04/2016, 23:30
El sistema viene a cubrir sobre todo los problemas derivados de usar telemetrías que van muy cargadas, con datos de "attitude", como es el caso de FRSKY D y Mavlink, que dependiendo del sistema de control de vuelo meten más o menos datos.

El decidirme a mejorar el sistema de predicción es por eso, porque la prueba que hice con FRSKY D del vídeo de hace una semana no fue muy buena, viendo los datos del log se veía perfectamente que no cumplía bien su cometido.

Aún me queda idear un sistema de filtrado en el que me quite de enmedio posiciones de lat/lon con errores, para que en casos comp el FRSKY no los tenga en cuenta y siga con la predicción (en aquel vídeo eran las sacudicas hacia otro lugar distinto del infinito). En caso de GPS telemetría directa no afecta porque lleva control de errores y sencillamente esas tramas son descartdas.

En fin, unas mejoras que viene a suplir carencias del sistema y a intentar ser un pocos más de precisión (con éste sistema en als distancias cortas debería haber un mejor comportamiento).

Simba
17/04/2016, 23:52
No me cave ninguna duda, seguro que funciona mejor, pero sinceramente creo que nosotros Turruk y yo, no tenemos las perdidas de datos que comentas tiene Guillesan, que no se si estaba utilizando, Orange OpenLRS a pelo, con GPS directo, o con mavlink del OSD MFD.

Puede que incluso tengas razón, y la mejora tan grande se deba sobre todo, a la predicción de la posición perdida, pero sobre todo o al menos a mi me parece, que se tiene que pensar también, como factor muy significativo, en la ganancia de posición o adelantamiento a posiciones mas adelantadas de la posición, esa creo que es la clave la gran mejora observada, y la única que a día de hoy, parece que realmente está viva en el seguimiento, y no siempre retrasada xxº de la posición real.

Ese calculo que hiciste, de adelantar xxº la posición recibida, creo que es la clave de todo, al menos en nuestro caso.

P.D.: Y claro está con un ajuste fino fino, de la respuesta de los servos.

rortega
18/04/2016, 00:04
No me cave ninguna duda, seguro que funciona mejor, pero sinceramente creo que nosotros Turruk y yo, no tenemos las perdidas de datos que comentas tiene Guillesan, que no se si estaba utilizando, Orange OpenLRS a pelo, con GPS directo, o con mavlink del OSD MFD.

Puede que incluso tengas razón, y la mejora tan grande se deba sobre todo, a la predicción de la posición perdida, pero sobre todo o al menos a mi me parece, que se tiene que pensar también, como factor muy significativo, en la ganancia de posición o adelantamiento a posiciones mas adelantadas de la posición, esa creo que es la clave la gran mejora observada, y la única que a día de hoy, parece que realmente está viva en el seguimiento, y no siempre retrasada xxº de la posición real.

Ese calculo que hiciste, de adelantar xxº la posición recibida, creo que es la clave de todo, al menos en nuestro caso.

P.D.: Y claro está con un ajuste fino fino, de la respuesta de los servos.

Sí, así es, y se mantiene el uso de esa ganancia en la predicción del sistema para todas las estimas que realiza. Ya te digo, sobre todo la mejora se va a notar cuando nos entran tramas a pocos herzios o tenemos pérdidas.

Te voy a hacer una pregunta que no tiene que ver con la discusión pero que me interesa conocer. ¿Tú al final modificaste el valor de pid_divider o lo dejaste tal cual estaba? He comprobado que subiéndolo un punto (está en 15 y lo he probado en 16) el sistema es mucho más fluído, pero sencillamente porque provoca que la respuesta del sistema pid sea más lenta. La pregunta te la hago porque tengo curiosidad por saber si metiendo una ganancia grande en el sistema de predicción compensan los efectos de subir el pid. Si fuera así sería una pasada.

En las pruebas del vídeo no he tocado ese pid_divider, lo he dejado con su valor por defecto para que no haya trampa ni cartón.

Simba
18/04/2016, 00:09
Pues me pillas, no me acuerdo y lo tendré que mirar, espera y voy a por los trastos y veo lo que tiene el Traker cargado.

rortega
18/04/2016, 00:12
Pues me pillas, no me acuerdo y lo tendré que mirar, espera y voy a por los trastos y veo lo que tiene el Traker cargado.
Tranquilo, no hace falta que sea ahora, cuando puedas.

Simba
18/04/2016, 00:14
Vale este es mi setup:

Current settings:
looptime = 3000
servo_pwm_rate = 50
gps_baud = 2
gps_provider = NMEA
gps_sbas_mode = AUTO
gps_auto_config = ON
gps_auto_baud = OFF
home_min_sats = 6
telemetry_inversion = OFF
battery_capacity = 0
vbat_scale = 110
vbat_max_cell_voltage = 43
vbat_min_cell_voltage = 33
vbat_warning_cell_voltage = 35
p = 8000
i = 200
d = 1000
max_pid_error = 1
max_pid_accumulator = 8000
max_pid_gain = 500
pid_divider = 15
pan0 = 1510
pan0_calibrated = 1
min_pan_speed = 20
offset = 270.000
offset_trim = 1
init_servos = 1
tilt0 = 2050
tilt90 = 1110
easing = 2
easing_steps = 60
easing_min_angle = 2
easing_milis = 15
telemetry_baud = 1
telemetry_protocol = 8
start_tracking_distance = 10
mag_declination = 0
min_logic_level = 25
nopid_min_delta = 0.200
nopid_map_angle = 90
nopid_max_speed = 200
gps_gain = 30

Simba
18/04/2016, 00:22
Creo recordar que en anteriores versiones, hice pruebas de subir y bajar el pid_divide, y que con 14 me respondan los PID mas energicos, si lo bajaba mas se volvia muy inestable, y subiendo a 16 y mas se amortiguaba bastante, en fin no me acuerdo si el efecto era ese o al contrario.

Cuando pusiste esa ultima versión, lo deje por defecto en 15 y como todo fue tan bien, ya ni me acorde del tema, ya sabes la de aquel, lo que funciona no lo toques, Ja ja jaja.

rortega
18/04/2016, 00:25
¿Qué rápido, gracias!

Lo tienes por defecto a 15, duda resuelta.

Ésto ya simplemente por comentar, el max_pid_gain, que por defecto está a 500, influye un montón en el comportamiento del tracker también. Si se baja, la respuesta es también más lenta. En el caso de servos muy rápidos bajarlo ayudaría también a conseguir fluidez.

En esto de la fluidez el problema principal es la frecuencia a la que nos llegan las tramas de telemetría. Pero la respuesta del servo también influye muchísimo. Un servo dando una respuesta muy rápida hace que de muchos "saltitos", incluso si metemos un sistema de muestreo/estimación como el que he implementado (es que he hecho tantísimas pruebas en estos días que he visto a fondo cada parámetro). Pausas muy cortas pero muy repetidas. Bajando ese parámetro se puede controlar la fluidez.

El problema es llevar todo ésto a la práctica al campo ...

Bueno, de cualquier forma era sólo comentar estas cosas por si a alguien en el futuro se pega una vuelta por el foro y decide montar un tracker con esta locura, je je.

macgver
22/04/2016, 10:23
Hi Rortega

I use Brushless Gimbal control , will change ftom servo to BLDC ... if the opportunity AAT direct control BLDC it?

https://www.youtube.com/watch?v=ZTC3fNf6Buo

rortega
22/04/2016, 20:21
Hi Rortega

I use Brushless Gimbal control , will change ftom servo to BLDC ... if the opportunity AAT direct control BLDC it?

https://www.youtube.com/watch?v=ZTC3fNf6Buo
Sorry, but I don't understand your question. It seems that you are using the 8 bits version, isn't it? The 8bit version works fine with telemetry from AAT driver.

macgver
23/04/2016, 03:53
Sorry, but I don't understand your question. It seems that you are using the 8 bits version, isn't it? The 8bit version works fine with telemetry from AAT driver.


Sorry, My English is not good.

This is a sample. My use 8bit version + Brushless Gimbal control.
Of course, you can also use 32bit + Brushless Gimbal control.

I wonder whether we can Brushless Gimbal control functions into to AAT Control it?
(only PAN)

rortega
23/04/2016, 19:36
Sorry, My English is not good.

This is a sample. My use 8bit version + Brushless Gimbal control.
Of course, you can also use 32bit + Brushless Gimbal control.

I wonder whether we can Brushless Gimbal control functions into to AAT Control it?
(only PAN)

Do you mean that you'd like to control the brushless motor directly, without using the gimbal controller board? The firmware can't do it.

rortega
23/04/2016, 19:41
Chicos, hay alguien usando MFD con 32 bits actualmente? Lo pregunto porque he detectado un bug usando el protocolo MFD, que no sé si es extensible también a la versión de 8 bits.

La cuestión es que enviando tramas a 4 hz (4 tramas por segundo), no hay problema, aparentemente funciona bien. Pero si pasamos a 2 hz o a 1 hz deja de funcionar correctamente.

Es algo que he detectado por pura casualidad, andaba probando el simulador MFD que me cree en su día, y por error le he pasado los datos a menos milisegundos y me he topado con ese problemilla. Supongo que a la frecuencia que el AAT driver envía las tramas no os ha dado problema nunca.

Guillesan
23/04/2016, 20:10
Raúl te refieres MFD con telemetria por vídeo? Yo lo he probado-usado si pero con las velocidades estandar. La salida del driver descodificador a la entrada serie a 19200

Guillesan
23/04/2016, 20:30
Otra cosa es que enviando mavlink entero , ya me entiendes desde una pixhawk en el oled se refleja claro el número de satélites pero.... Si son más de 9 lo lee mal es decir 10 o más salen números raros

TURRUK
23/04/2016, 20:37
Chicos, hay alguien usando MFD con 32 bits actualmente? Lo pregunto porque he detectado un bug usando el protocolo MFD, que no sé si es extensible también a la versión de 8 bits.

La cuestión es que enviando tramas a 4 hz (4 tramas por segundo), no hay problema, aparentemente funciona bien. Pero si pasamos a 2 hz o a 1 hz deja de funcionar correctamente.

Es algo que he detectado por pura casualidad, andaba probando el simulador MFD que me cree en su día, y por error le he pasado los datos a menos milisegundos y me he topado con ese problemilla. Supongo que a la frecuencia que el AAT driver envía las tramas no os ha dado problema nunca.


Hola, como me recuerdo probamos con Simba, funciono bien de 8 bit claro el GPS de MFD trabaja 5hz, y nada mas.