Detector de líneas (respuesta lenta), se puede acelerar?

Saludos:

Estamos probando el sensor siguelíneas, con la programación básica para que siga la línea negra. Funciona.

 Pero en las curvas, notamos que le cuesta girar y es porque no nos gira nada más detectar los estados 1 o 2 del siguelíneas. Vamos que la respuesta no es inmediata y a veces se va porque pasa del estado 0 al 3.

 **¿Se puede hacer algo para que esa respuesta sea más rápida?**

 Como el código básico nos funciona queremos complicar el circuito para avanzar en la codificación.

 Entiendo que, por ejemplo, el circuito de abajo es muy complicado pero me parece muy interesante, los retos que se proponen en él (línea discontinua, curvas extremas, intersecciones...)

¿Existe algún lugar donde poder ver qué tipo de código se utilizar para superar estas situaciones?

Mil gracias!!!

Hola Jokin,

La respuesta del programa es inmediata, pero debes tener en cuenta que si el robot está en movimiento hay una inercia.

Lo que quiero decir es que si en programa le pones una condición de giro en el caso de que la respuesta del sensor sea 1 o 2, aunque la respuesta es inmediata por parte del programa, la inercia del robot y el diseño del propio programa hacen que no pueda corregir y pase a lectura "3" perdiendo la línea, pero aunque tú no lo puedas comprobar no ha pasado del 0 al 3.

Para corregir ese caso en curvas cerradas debes memorizar al menos el sentido en el que perdiste la línea para seguir buscando en la misma dirección a pesar de estar en lectura "3".

Para la gestión de líneas discontinuas, cruces, etc hace falta adecuar el programa para que prevea esas situaciones, pero ya es mucho más complicado de responder aquí.

Puedes compartir el programa que estás utilizando por si se puede mejorar de manera sencilla.

Saludos,

Dani S.

Mil gracias Dani!

"Para corregir ese caso en curvas cerradas debes memorizar al menos el sentido en el que perdiste la línea para seguir buscando en la misma dirección a pesar de estar en lectura "3"."

Me interesa esta frase tuya. Eso cómo se haría?

El resto de casuística como dices es complicada quizá desarrollarlo en este foro...pero hay algún lugar dónde se comenten situaciones de este tipo? (foro, comunidad, blog...)

El código que tenemos ahora, lo estamos probando primero sin robot, con los sensores de colores y dibujado un robot en mblock. Más que nada para entender el funcionamiento.

A ver si luego puedo subir lo que hemos hecho.

Mil gracias!!!
Un saludo!

Lo que te quería decir con esa frase es que lo que tienes que hacer es memorizar el último valor devuelto por el sensor siguelíneas cuando la lectura es "3".

Si memorizas ese valor en una variable continuamente y lo consultas cuando tengas la lectura inmediata sea "3" podrás saber que si fue "1" el robot se ha salido por la derecha por lo que deberías girar con fuerza hacia la izquierda para recuperar la línea, pero si fue "2" el robot se ha salido por la izquierda y debe girar con fuerza hacia la derecha.

Luego lo puedes complicar con un control más o menos PID, pero lo básico es eso.

El foro o comunidad más adecuado para plantear tus dudas es precisamente este en el que estamos escribiendo, y también lo tienes más grande en lengua inglesa .

Ya que preguntas por ello os recuerdo que tenéis a vuestra disposición tutoriales y restos de programación con mBot y Ranger en mi web JuegosRobotica.es y si quieres formarte con mayor profundidad tienes la plataforma de cursos con robótica educativa de Juegos Robótica .

Saludos,

Dani S.

El tiempo de respuesta, depende de que tipo de conexión tienes con el mBot.

Si cargas el código directo en el arduino, sin duda que el tiempo del bucle es mínimo y lo que más va a pesar es el tema inercia. Un par de consultas y una actuación dan un tiempo de bucle del orden de los 70 us (microsegundos) o sea mas de 10.000 veces en un segundo.

No creo que utilices un cable, pero si ese fuera el caso, los paquetes entre mBlock y el mBot están separados unos 32 ms (milisegundos) según mis medidas con un analizador lógico. Eso significa que si en el bucle principal envias un par de consultas al mBot y una actuación, el tiempo de bulce ronda los 100ms y por tanto tienes 10 bucles por segundo.

Un mBot alimentado con 6V recorre unos 20 cm (un poco menos) en un segundo a una velocidad de 100, por tanto en una décima de segundo recorre 2cm y entre bucle y bucle: consulta y consulta viaja 2cm, eso te puede dejar fuera de la línea...

Probando una conexión bluetooth, estos tiempos son mas largos (60ms promedio entre paquetes) y supongo que si la conexión es wifi, no va a ser mejor que por cable.

Mi recomendación es, utilizar la menor cantidad de paquetes por bucle, o sea, siempre que puedas, lee un sensor en una variable y luego utiliza la variable, en vez de hacer varias lecturas (bloques de consulta de la distancia o los siguelineas, ya que cada bloque genera una transacción serie de ida y vuelta que conlleva los 32 ms a los que hago referencia)

Estas pruebas fueron realizadas entre el software mBlock y un arduino uno programado con el firmware del mBot y entre el mBlock y el simulador v-rep enlazado mediante dos módulos ftdi físicos para poder intercalar el analizador lógico. Los resultados fueron practicamente iguales

saludos

Juan