Buenas!

Y sobre todo, seguirás necesitando un encóder no? Porque sólo el acelerómetro con giro... no veo cómo vas a detectar el trazado en su longitud, quiero decir, podrás detectar rectas y curvas, pero no la longitud de las rectas...

Hombre... técnicamente puedes calcular la longitud de las rectas sólo con inerciales pero está claro que si tienes encoders, ayudan...

En todo caso, pienso que a lo que se refiere JMN con simplificar la programación es que te "da más juego" el hecho de llevar inerciales para llevar a cabo las ideas que se te vayan ocurriendo. Por experiencia diré que la programación de Silvestre es bastante compleja (o al menos, tiene muchas líneas!) aunque gran parte se debe a que es capaz de aprenderse cualquier circuito y no necesita horas de trabajo sobre una pista determinada. Esto quizá no sea una gran ventaja pues creo que sólo en Robolid (único concurso donde no publican la psita) ha podido sacar provecho real de ello... pero bueno, ha sido un paso más y creo que al final es útil.

Pelopinxo, eres un crack 🙂 Lo que haces, sólo con encoders, tiene mucho mérito 🙂

Un saludo!
mindless

Buenas!

Y sobre todo, seguirás necesitando un encóder no? Porque sólo el acelerómetro con giro... no veo cómo vas a detectar el trazado en su longitud, quiero decir, podrás detectar rectas y curvas, pero no la longitud de las rectas...

Hombre... técnicamente puedes calcular la longitud de las rectas sólo con inerciales pero está claro que si tienes encoders, ayudan...

En todo caso, pienso que a lo que se refiere JMN con simplificar la programación es que te "da más juego" el hecho de llevar inerciales para llevar a cabo las ideas que se te vayan ocurriendo. Por experiencia diré que la programación de Silvestre es bastante compleja (o al menos, tiene muchas líneas!) aunque gran parte se debe a que es capaz de aprenderse cualquier circuito y no necesita horas de trabajo sobre una pista determinada. Esto quizá no sea una gran ventaja pues creo que sólo en Robolid (único concurso donde no publican la psita) ha podido sacar provecho real de ello... pero bueno, ha sido un paso más y creo que al final es útil.

Pelopinxo, eres un crack 🙂 Lo que haces, sólo con encoders, tiene mucho mérito 🙂

Un saludo!
mindless
Técnicamente... pero una cosa es la técnica, y otra la realidad. Los acelerómetros meten una auténtica burrada de basura, para medir distancias, con precisión de milímetros, personalmente los veo completamente inservibles.

El giroscopio es el único que realmente te daría la curva, de nuevo el acelerómetro, con su ruido, y el propio robot corrigiendo...
El acelerómetro sería útil pero para otros propósitos, los cuales dudo que se estén planteando ahora mismo.

Con lo que personalmente pienso que un encóder es suficiente, y a los hecho me remito. Un giro ayudaría, es verdad, pero no es ninguna panacea ni ayuda milagrosa y desde luego el giro no te va a dar la velocidad que no tienes.

O al menos, eso diría yo ❓

Como dice mindless con simplificar me refiero a tener más opciones a la hora de programar, los encoders claro está que no se van a quitar, ya que son ideales para contar distancia, pero para detectar trazado además de los encoders puede ser muy conveniente tener otros sensores. Cuanto más compleja sea la electrónica más opciones tendrá el código, y al revés.. Por lo que no merece la pena invertir el tiempo en la placa que tenemos (no tenemos estos sensores), sino invertirlo en una nueva que nos dé todas las opciones posibles.

@DMG: creo que no filtra tramos, la curva se acaba cuando se llega a la diferencia de ticks, es decir si tenemos una curva en la que el robot la recorre con una diferencia de -30 ticks entre cada encoder, cuando se alcance esa diferencia el robot sabe que ha terminado la curva y que entra en el siguiente tramo, está en la curva hasta que se alcance la diferencia, los tramos y sus longitudes están ordenados en el código, con su duración de ticks correspondientes, y se va pasando de uno a otro secuencialmente.

No sincroniza con la pista, sólo le dice en que punto de los dos posibles empieza, a partir de ahí el robot ya conoce todos los tramos con los que se va a encontrar, y si se pierde creo que no tiene posibilidad de situarse de nuevo.

Creo que todo esto lo hace así

Técnicamente... pero una cosa es la técnica, y otra la realidad. Los acelerómetros meten una auténtica burrada de basura, para medir distancias, con precisión de milímetros, personalmente los veo completamente inservibles.

Piensa en los robots balancines, con un filtro de kalman y, si le añades encoders, aguantan estáticos horas. Tampoco sé hasta qué punto necesitas precisión de milímetros... pero bueno repito que creo que los encoders son necesarios.
El giroscopio es el único que realmente te daría la curva, de nuevo el acelerómetro, con su ruido, y el propio robot corrigiendo...
El acelerómetro sería útil pero para otros propósitos, los cuales dudo que se estén planteando ahora mismo.
Con lo que personalmente pienso que un encóder es suficiente, y a los hecho me remito.

Si lo que dices es que las correcciones del robot afectarán al acelerómetro, decirte que eso afecta más al gyro cuya respuesta es mucho más rápida. Por eso generalmente se usan filtros complementarios o filtros de Kalman para fusionar la señal del gyro y la del acelerómetro. Supongo que no has analizado las señales de un gyro y un acelerómetro sobre un robot velocista y por eso crees que no ayudan los sensores inerciales.

A los hechos me remito yo: el robot Pelopinxo cuando forzó, empezó a culear. Ya me contarás cómo detecta eso el encoder, te aseguro que con los inerciales se ve de una forma razonablemente sencilla (a esto se refiere JMN cuando dice que simplifica la programación). Por otro lado, si ves los vídeos de Cosmobot verás como Silvestre hace el zigzag completamente recto: eso lo hizo usando los sensores inerciales y le daba aproximadamente 3 décimas por vuelta sobre un total de 3.2 segundos. Seguramente si te enfrentas al reto de construir un robot que pueda ir a más de 2.5 m/s verás los beneficios de tener este tipo de sensores.

Como apunte, decirte que pelopincho llevaba giróscopo, acelerómetro y brújula aunque no los usó durante AESSBot por falta de tiempo. Estoy seguro de que su robot correrá más y mejor cuando los use 🙂

mindless

Piensa en los robots balancines, con un filtro de kalman y, si le añades encoders, aguantan estáticos horas. Tampoco sé hasta qué punto necesitas precisión de milímetros... pero bueno repito que creo que los encoders son necesarios.

Estamos de acuerdo entonces.

Si lo que dices es que las correcciones del robot afectarán al acelerómetro, decirte que eso afecta más al gyro cuya respuesta es mucho más rápida. Por eso generalmente se usan filtros complementarios o filtros de Kalman para fusionar la señal del gyro y la del acelerómetro. Supongo que no has analizado las señales de un gyro y un acelerómetro sobre un robot velocista y por eso crees que no ayudan los sensores inerciales.

Sí, tengo un vídeo de un DCM completo hecho por mi para un helicóptero. El giro es más rápido, pero sería algo muchísimo más lineal y limpio de ver que la salida del acelerómetro. Vamos, en un DCM normal, el giro tiene un peso del 95% y el acelerómetro sólo de un 5%... y en muchos es 99-1. Con eso te digo lo que vale la señal del acelerómetro respecto al giro 😉
A los hechos me remito yo: el robot Pelopinxo cuando forzó, empezó a culear. Ya me contarás cómo detecta eso el encoder, te aseguro que con los inerciales se ve de una forma razonablemente sencilla (a esto se refiere JMN cuando dice que simplifica la programación). Por otro lado, si ves los vídeos de Cosmobot verás como Silvestre hace el zigzag completamente recto: eso lo hizo usando los sensores inerciales y le daba aproximadamente 3 décimas por vuelta sobre un total de 3.2 segundos. Seguramente si te enfrentas al reto de construir un robot que pueda ir a más de 2.5 m/s verás los beneficios de tener este tipo de sensores.

Efectivamente, para medir el "culeo", dudo que haya una mejor forma. Cuando dije que:
El acelerómetro sería útil pero para otros propósitos, los cuales dudo que se estén planteando ahora mismo.
Pensaba en esto precisamente, aunque sí sería posible detectarlo planteado como un ESP del coche de calle... pero habría que ver si realmente el encóder tiene tanta precisión o si en un eje realmente se puede ver dicho "culeo".

Lo que quiero decir a modo de resumen, es que un robot que corre en curva a 2.6m/s, por meterle una IMU completa no va a correr más en curva. ¿Que ayuda?? Por supuesto!! Pero que parece que es la panacea para dar un salto en velocidad terrible, y la mejora que se obtiene, creo que es bastante pequeña.

Pero también te doy la razón en que realmente estoy hablando sin tener conocimiento 100% real en este tipo de robots, sino en otros. Cuando me llegue la placa de china, las nuevas Cortex y demás... entonces ya veré hasta qué punto estoy totalmente confundido y si tengo que rediseñar para sacar el I2C y conectar mi IMU de 9 grados 😛