Hola a todos, soy nuevo en este Foro.
Mi hijo tiene un mBot Ranger y hoy lo ha desmontado y ha cambiado la construcción de Land Raider a Dashing Raptor pero ahora no le funciona el sensor de ultrasonidos.
El resto va todo ok, el sensor tiene encendido el led rojo.
He cambiado el cable por el del line follower per sigue igual... :-(

¿Alguna pista?

Saludos y gracias!

Hola a todos, soy nuevo en este Foro. Mi hijo tiene un mBot Ranger y hoy lo ha desmontado y ha cambiado la construcción de Land Raider a Dashing Raptor pero ahora no le funciona el sensor de ultrasonidos. El resto va todo ok, el sensor tiene encendido el led rojo. He cambiado el cable por el del line follower per sigue igual... :-( ¿Alguna pista? Saludos y gracias!

Hola,

Una vez me paso que ningun sensor me iba. Al final, exacto no se que hice. Pero se que estaba relacionado con actualizar el firmware y despues restablecer el programa predeterminado del menu de conectar del programa mblcok.

Hola, Una vez me paso que ningun sensor me iba. Al final, exacto no se que hice. Pero se que estaba relacionado con actualizar el firmware y despues restablecer el programa predeterminado del menu de conectar del programa mblcok.

Hola JOPBOT.

Nos ocurre un problema parecido, tras una práctica correcta con el sensor de ultrasonidos, este dejo de funcionar, cargamos de nuevo el firmware, varias veces, hubo un cambio de versión en mBlock, probamos con la antigua y la actual y nada que ha dejado de funcionar, quedaba la duda del firmware, como tenemos más prácticas y el sensor da mucho juego, a pesar del precio hemos adquirido uno nuevo con algún sensor más, y este recien adquirido funciona perfectamente, por lo que el problema, en mi caso, es que el sensor se ha roto y no sabemos como.

También estamos peleando con el sensor de sonido integrado, para que detecte sonido (con la carcasa quitada) hemos de dar gritos de "aupa" y bastante cerca, con un nivel de captación en silencio de unos 230, sobre los 1024 niveles, entre los sensores adquiridos uno de ellos es un microfono, lo hemos probado y no tiene nada que ver, detecta un chasquido de dedos desde la otra punta de la habitación, ¿esta tambien roto el micro de la placa auriga? y nos interesa que funcione el de la placa, ya que en elguna práctica hemos agotado los cinco puertos que ofrece la placa Auriga.
Por favor, podríais probarlo.

Saludos

Hola JOPBOT. Nos ocurre un problema parecido, tras una práctica correcta con el sensor de ultrasonidos, este dejo de funcionar, cargamos de nuevo el firmware, varias veces, hubo un cambio de versión en mBlock, probamos con la antigua y la actual y nada que ha dejado de funcionar, quedaba la duda del firmware, como tenemos más prácticas y el sensor da mucho juego, a pesar del precio hemos adquirido uno nuevo con algún sensor más, y este recien adquirido funciona perfectamente, por lo que el problema, en mi caso, es que el sensor se ha roto y no sabemos como. También estamos peleando con el sensor de sonido integrado, para que detecte sonido (con la carcasa quitada) hemos de dar gritos de "aupa" y bastante cerca, con un nivel de captación en silencio de unos 230, sobre los 1024 niveles, entre los sensores adquiridos uno de ellos es un microfono, lo hemos probado y no tiene nada que ver, detecta un chasquido de dedos desde la otra punta de la habitación, ¿esta tambien roto el micro de la placa auriga? y nos interesa que funcione el de la placa, ya que en elguna práctica hemos agotado los cinco puertos que ofrece la placa Auriga. Por favor, podríais probarlo. Saludos

Aunque quizá no tenga nada que ver, no está de más recordar aquí que una buena costumbre al utilizar el sensor de ultrasonidos es dejar delays entre lecturas. No es "saludable" dejar la lectura en un bucle continuo sin descanso.

En cuanto al problema concreto lo ideal sería probar otro sensor de ultrasonido para descartar que no se haya roto, aunque puede que no tengas ninguno a mano...

Saludos,

Dani S.

Aunque quizá no tenga nada que ver, no está de más recordar aquí que una buena costumbre al utilizar el sensor de ultrasonidos es dejar delays entre lecturas. No es "saludable" dejar la lectura en un bucle continuo sin descanso. En cuanto al problema concreto lo ideal sería probar otro sensor de ultrasonido para descartar que no se haya roto, aunque puede que no tengas ninguno a mano... Saludos, Dani S.

Hola JuegosRobotica.es

Decir que en las practicas que realizamos es así como dices, además siempre hay mas de un sensor con algún que otro delay y que tenemos por costumbre hacer una sola lectura del sensor para todo uso por ciclo del programa. Ahora al ir por I2C ¿El sensor trabaja constantemente a la espera que se le solicite por I2C el último dato?, ¿El sensor está parado hasta que se le solicita una medicion?, ¿Espera la Auriga el dato? ¿Donde se elabora el tiempo, auriga, el sensor?, nos hemos hecho muchas preguntas sobre como ha podido dejar de funcionar tras haberlo dejado funcionando, nos preguntamos si el error es nuestro, y si es así, que hemos hecho, no lo entendemos.

Tambien decir que para evitar usos de delay que no interesa que pare el programa, quiero usar "Timer" para hacer temporizadores y el programa me responde erraticamente.
Saludos

Hola JuegosRobotica.es Decir que en las practicas que realizamos es así como dices, además siempre hay mas de un sensor con algún que otro delay y que tenemos por costumbre hacer una sola lectura del sensor para todo uso por ciclo del programa. Ahora al ir por I2C ¿El sensor trabaja constantemente a la espera que se le solicite por I2C el último dato?, ¿El sensor está parado hasta que se le solicita una medicion?, ¿Espera la Auriga el dato? ¿Donde se elabora el tiempo, auriga, el sensor?, nos hemos hecho muchas preguntas sobre como ha podido dejar de funcionar tras haberlo dejado funcionando, nos preguntamos si el error es nuestro, y si es así, que hemos hecho, no lo entendemos. Tambien decir que para evitar usos de delay que no interesa que pare el programa, quiero usar "Timer" para hacer temporizadores y el programa me responde erraticamente. Saludos

Ahora al ir por I2C ¿El sensor trabaja constantemente a la espera que se le solicite por I2C el último dato?, ¿El sensor está parado hasta que se le solicita una medicion?, ¿Espera la Auriga el dato? ¿Donde se elabora el tiempo, auriga, el sensor?

Hola Jormafel!

No trabaja por I2C, pero entiendo lo que quieres decir... creo.

El sensor de makeblock no utiliza un pin de echo y otro de trigger, sino que obtiene la señal por un único pin de entrada. Eso nos haría pensar que el sensor está trabajando continuamente (suponemos que con un pequeño descanso entre medidas), y que continuamente podemos leer la medida.

58c154606a5a9.jpg

Habría que destripar la librería de Arduino para entender mejor su funcionamiento.

Si se confirma que funciona así en teoría no podrías haber cometido ningún error en la programación ni en la conexión.

Voy a ver si averiguo algo más de su funcionamiento interno y te cuento...

Saludos,

Dani S.

> Ahora al ir por I2C ¿El sensor trabaja constantemente a la espera que se le solicite por I2C el último dato?, ¿El sensor está parado hasta que se le solicita una medicion?, ¿Espera la Auriga el dato? ¿Donde se elabora el tiempo, auriga, el sensor? Hola Jormafel! No trabaja por I2C, pero entiendo lo que quieres decir... creo. El sensor de makeblock no utiliza un pin de echo y otro de trigger, sino que obtiene la señal por un único pin de entrada. Eso nos haría pensar que el sensor está trabajando continuamente (suponemos que con un pequeño descanso entre medidas), y que continuamente podemos leer la medida. ![58c154606a5a9.jpg](serve/attachment&path=58c154606a5a9.jpg) Habría que destripar la librería de Arduino para entender mejor su funcionamiento. Si se confirma que funciona así en teoría no podrías haber cometido ningún error en la programación ni en la conexión. Voy a ver si averiguo algo más de su funcionamiento interno y te cuento... Saludos, Dani S.

Hola JuegosRobotica.es

¡Anda! Que ya me vale.

Del PDF librombot_ranger_español:
_Es relevante conocer el significado de los colores ID que podemos encontrarnos en los
puertos de las diferentes placas de Makeblock. Estos son:
Rojo (motores), Amarillo (interface digital), Azul (interface digital dual), Gris (Puerto
serie, bluetooth), Negro (interface analógica y dual) y Blanco (Puerto I2C)
.

Muchisimas gracias por la documentación, ¿Donde has conseguido los esquemas? Mira que los he busacado, lo de I2C lo digo por que llamé a Soporte y así me lo confirmaron, aunque en su día destripando el firmware de la placa Auriga si ví las lineas de codigo, las habituales para tratar sensores de ultrasonidos con arduino y una función de la libreria MeAuriga y como en esas líneas se convertia el tiempo de recepción del eco en distancia, ahora pensando que iban por I2C empezaron todas esas preguntas que no entendia.

**

void readSensor(uint8_t device)
{
/**
ff 55 len idx action device port slot data a
0 1 2 3 4 5 6 7 8
*/
float value=0.0;
uint8_t port,slot,pin;
port = readBuffer(6);
pin = port;
switch(device)
{
case ULTRASONIC_SENSOR:
{
if(us == NULL)
{
us = new MeUltrasonicSensor(port);
}
else if(us->getPort() != port)
{
delete us;
us = new MeUltrasonicSensor(port);
}
value = (float)us->distanceCm();
writeHead();
writeSerial(command_index);
sendFloat(value);
}
break;
case ULTRASONIC_ARDUINO:
{
uint8_t trig = readBuffer(6);
uint8_t echo = readBuffer(7);
long pw_data;
float dis_data;
pinMode(trig,OUTPUT);
digitalWrite(trig,LOW);
delayMicroseconds(2);
digitalWrite(trig,HIGH);
delayMicroseconds(10);
digitalWrite(trig,LOW);
pinMode(echo, INPUT);
pw_data = pulseIn(echo,HIGH,30000);
dis_data = pw_data/58.0;
delay(5);
writeHead();
writeSerial(command_index);
sendFloat(pw_data);
}
break;


Ahora, veo en el esquema un pin5 T PWR del RJ11 y otro pin6 SIG conectados al microcontrolador y como vemos en el firmware parece que usa uno para trigger y otro para echo.

Momento en el que nos falló el sensor:

Teníamos en el puerto 10 el sensor de ultrasonidos, y en el 6 usabamos un interface para dos servos, por curiosidad del cableado, pasamos el sensor al puerto 6 y los servos al 10, arrancamos la aplicación y no funcionaba, habiamos dado al control de los servos al puerto del sensor US, rectificamos y estuvo funcionando correctamente, desmontamos, hacemos la práctica del robot de dos ruedas, el de las insrucciones, con el sensor en el puerto 10 y ya no funcionaba. ¿Pudo averiarlo cuando lo conectamos al puerto 6? esta práctica se realizó con conexión USB.

Saludos

Hola JuegosRobotica.es ¡Anda! Que ya me vale. Del PDF libro_mbot_ranger_español: _Es relevante conocer el significado de los colores ID que podemos encontrarnos en los puertos de las diferentes placas de Makeblock. Estos son: Rojo (motores), **Amarillo (interface digital)**, Azul (interface digital dual), Gris (Puerto serie, bluetooth), Negro (interface analógica y dual) y Blanco (Puerto I2C)_. Muchisimas gracias por la documentación, ¿Donde has conseguido los esquemas? Mira que los he busacado, lo de I2C lo digo por que llamé a Soporte y así me lo confirmaron, aunque en su día destripando el firmware de la placa Auriga si ví las lineas de codigo, las habituales para tratar sensores de ultrasonidos con arduino y una función de la libreria MeAuriga y como en esas líneas se convertia el tiempo de recepción del eco en distancia, ahora pensando que iban por I2C empezaron todas esas preguntas que no entendia. ##### ************ _void readSensor(uint8_t device) { /************************************************** ff 55 len idx action device port slot data a 0 1 2 3 4 5 6 7 8 ***************************************************/ float value=0.0; uint8_t port,slot,pin; port = readBuffer(6); pin = port; switch(device) { case ULTRASONIC_SENSOR: { if(us == NULL) { us = new MeUltrasonicSensor(port); } else if(us->getPort() != port) { delete us; us = new MeUltrasonicSensor(port); } value = (float)us->distanceCm(); writeHead(); writeSerial(command_index); sendFloat(value); } break; case ULTRASONIC_ARDUINO: { uint8_t trig = readBuffer(6); uint8_t echo = readBuffer(7); long pw_data; float dis_data; pinMode(trig,OUTPUT); digitalWrite(trig,LOW); delayMicroseconds(2); digitalWrite(trig,HIGH); delayMicroseconds(10); digitalWrite(trig,LOW); pinMode(echo, INPUT); pw_data = pulseIn(echo,HIGH,30000); dis_data = pw_data/58.0; delay(5); writeHead(); writeSerial(command_index); sendFloat(pw_data); } break;_ **************** Ahora, veo en el esquema un pin5 T PWR del RJ11 y otro pin6 SIG conectados al microcontrolador y como vemos en el firmware parece que usa uno para trigger y otro para echo. Momento en el que nos falló el sensor: Teníamos en el puerto 10 el sensor de ultrasonidos, y en el 6 usabamos un interface para dos servos, por curiosidad del cableado, pasamos el sensor al puerto 6 y los servos al 10, arrancamos la aplicación y no funcionaba, habiamos dado al control de los servos al puerto del sensor US, rectificamos y estuvo funcionando correctamente, desmontamos, hacemos la práctica del robot de dos ruedas, el de las insrucciones, con el sensor en el puerto 10 y ya no funcionaba. ¿Pudo averiarlo cuando lo conectamos al puerto 6? esta práctica se realizó con conexión USB. Saludos

Muchisimas gracias por la documentación, ¿Donde has conseguido los esquemas?

Están en la página de Makeblock global .

**

void readSensor(uint8_t device)
{
/**
ff 55 len idx action device port slot data a
0 1 2 3 4 5 6 7 8
*/
float value=0.0;
uint8_t port,slot,pin;
port = readBuffer(6);
pin = port;
switch(device)
{
case ULTRASONIC_SENSOR:
{
if(us == NULL)
{
us = new MeUltrasonicSensor(port);
}
else if(us->getPort() != port)
{
delete us;
us = new MeUltrasonicSensor(port);
}
value = (float)us->distanceCm();
writeHead();
writeSerial(command_index);
sendFloat(value);
}
break;
case ULTRASONIC_ARDUINO:
{
uint8_t trig = readBuffer(6);
uint8_t echo = readBuffer(7);
long pw_data;
float dis_data;
pinMode(trig,OUTPUT);
digitalWrite(trig,LOW);
delayMicroseconds(2);
digitalWrite(trig,HIGH);
delayMicroseconds(10);
digitalWrite(trig,LOW);
pinMode(echo, INPUT);
pw_data = pulseIn(echo,HIGH,30000);
dis_data = pw_data/58.0;
delay(5);
writeHead();
writeSerial(command_index);
sendFloat(pw_data);
}
break;


En esta librería que has colgado ya se ve que no trabaja como un sensor de ultrasonidos para Arduino genérico.

case ULTRASONIC_SENSOR:

Aquí se ve como trabaja el de Makeblock (lee valor directo)

case ULTRASONIC_ARDUINO:

Aquí se ve como trabaja el genérico (con echo y trigger).

Ahora, veo en el esquema un pin5 T PWR del RJ11 y otro pin6 SIG conectados al microcontrolador y como vemos en el firmware parece que usa uno para trigger y otro para echo.

No, no... aunque en el esquema esté claramente conectado el pin 5 está claro que el sensor se puede conectar a Arduino con sólo tres cables, 5v, gnd y señal. No está trabajando con trigger y echo... no. Lee el valor directo, de alguna manera el sensor debe estar leyendo de manera casi continua.

58c24a60a557a.jpg

¿Pudo averiarlo cuando lo conectamos al puerto 6? esta práctica se realizó con conexión USB.

Yo diría que no, opinión personal. A priori la configuración del puerto 10 y el 6 son iguales.

>Muchisimas gracias por la documentación, ¿Donde has conseguido los esquemas? Están en la [página de Makeblock global](http://learn.makeblock.com/en/me-ultrasonic-sensor/) . >##### ************ >_void readSensor(uint8_t device) >{ > /************************************************** > ff 55 len idx action device port slot data a > 0 1 2 3 4 5 6 7 8 > ***************************************************/ > float value=0.0; > uint8_t port,slot,pin; > port = readBuffer(6); > pin = port; > switch(device) > { > case ULTRASONIC_SENSOR: > { > if(us == NULL) > { > us = new MeUltrasonicSensor(port); > } > else if(us->getPort() != port) > { > delete us; > us = new MeUltrasonicSensor(port); > } > value = (float)us->distanceCm(); > writeHead(); > writeSerial(command_index); > sendFloat(value); > } > break; > case ULTRASONIC_ARDUINO: > { > uint8_t trig = readBuffer(6); > uint8_t echo = readBuffer(7); > long pw_data; > float dis_data; > pinMode(trig,OUTPUT); > digitalWrite(trig,LOW); > delayMicroseconds(2); > digitalWrite(trig,HIGH); > delayMicroseconds(10); > digitalWrite(trig,LOW); > pinMode(echo, INPUT); > pw_data = pulseIn(echo,HIGH,30000); > dis_data = pw_data/58.0; > delay(5); > writeHead(); > writeSerial(command_index); > sendFloat(pw_data); > } > break;_ >**************** En esta librería que has colgado ya se ve que no trabaja como un sensor de ultrasonidos para Arduino genérico. > case ULTRASONIC_SENSOR: Aquí se ve como trabaja el de Makeblock (lee valor directo) > case ULTRASONIC_ARDUINO: Aquí se ve como trabaja el genérico (con echo y trigger). >Ahora, veo en el esquema un pin5 T PWR del RJ11 y otro pin6 SIG conectados al microcontrolador y como vemos en el firmware parece que usa uno para trigger y otro para echo. No, no... aunque en el esquema esté claramente conectado el pin 5 está claro que el sensor se puede conectar a Arduino con sólo tres cables, 5v, gnd y señal. No está trabajando con trigger y echo... no. Lee el valor directo, de alguna manera el sensor debe estar leyendo de manera casi continua. ![58c24a60a557a.jpg](serve/attachment&path=58c24a60a557a.jpg) >¿Pudo averiarlo cuando lo conectamos al puerto 6? esta práctica se realizó con conexión USB. Yo diría que no, opinión personal. A priori la configuración del puerto 10 y el 6 son iguales.

Hola.

Tenías toda la razón, ayer desgranando un poco las librerías trabaja como indicas, el sensor de Makeblock utiliza un solo pin para la señal de trigger y el mismo pin recibir la señal de echo, la misma librería ya da el valor de distancia elaborado.

Tenemos dos posibilidades de trabajo:
58c29c5d5f74c.png

Si utilizamos "lee el sensor ultrasónico trig........"
Las lineas de código están en el firmware de la Auriga :

 case ULTRASONIC_ARDUINO:
      {
        uint8_t trig = readBuffer(6);
        uint8_t echo = readBuffer(7);
        long pw_data;
        float dis_data;
        pinMode(trig,OUTPUT);
        digitalWrite(trig,LOW);
        delayMicroseconds(2);
        digitalWrite(trig,HIGH);
        delayMicroseconds(10);
        digitalWrite(trig,LOW);
        pinMode(echo, INPUT);
        pw_data = pulseIn(echo,HIGH,30000);
        dis_data = pw_data/58.0;
        delay(5);
        writeHead();
        writeSerial(command_index);
        sendFloat(pw_data);
      }
      break;

y bajo esta instrucción podemos usar tanto los sensores que disponen de una patilla para trigger y otra para echo, eso si hay que localizar ante los puertos donde físícamente se van a conectar, yo por si acaso la prueba la he hecho con un arduino uno y la mShield sobre el puerto 3, para el sensor de mBlock tras localizar el pin correcto solo me ha bastado con poner tranto trigger como echo el mismo pin, el microcontrolador que lleva el sensor de ultrasónidos se encarga de gestionar el uso pel pin SIG.

La cosa cambia un poco cuanto usamos la instrucción : "ultrasonic sensor......"
el firmware de la auriga toma este camino :

    case ULTRASONIC_SENSOR:
      {
        if(us == NULL)
        {
          us = new MeUltrasonicSensor(port);
        }
        else if(us->getPort() != port)
        {
          delete us;
          us = new MeUltrasonicSensor(port);
        }
        value = (float)us->distanceCm();
        writeHead();
        writeSerial(command_index);
        sendFloat(value);
      }
      break;

Y cotilleando la libreria "MeUltrasonicSensor" el proceso es el mismo pero sobre el mismo pin para trigger y echo, manda el disparo y cambia a INPUT para esperar el flanco del ECHO, luego ofrece el valor ya terminado a través de

double MeUltrasonicSensor::distanceCm(uint16_t MAXcm)

Ya desgranado un poco como funciona, como puñetas se ha roto, si lo conectamos a una señal PWM (servo) que si no han cambiado el "prescaler" son unos 490Hz, no creo que sea suficiente para estropearlo, cambiamos el puerto y siguió funcionando con normalidad, ¿pero?......

Hola. Tenías toda la razón, ayer desgranando un poco las librerías trabaja como indicas, el sensor de Makeblock utiliza un solo pin para la señal de trigger y el mismo pin recibir la señal de echo, la misma librería ya da el valor de distancia elaborado. Tenemos dos posibilidades de trabajo: ![58c29c5d5f74c.png](serve/attachment&path=58c29c5d5f74c.png) Si utilizamos "lee el sensor ultrasónico trig........" Las lineas de código están en el firmware de la Auriga : ```` case ULTRASONIC_ARDUINO: { uint8_t trig = readBuffer(6); uint8_t echo = readBuffer(7); long pw_data; float dis_data; pinMode(trig,OUTPUT); digitalWrite(trig,LOW); delayMicroseconds(2); digitalWrite(trig,HIGH); delayMicroseconds(10); digitalWrite(trig,LOW); pinMode(echo, INPUT); pw_data = pulseIn(echo,HIGH,30000); dis_data = pw_data/58.0; delay(5); writeHead(); writeSerial(command_index); sendFloat(pw_data); } break; ```` y bajo esta instrucción podemos usar tanto los sensores que disponen de una patilla para trigger y otra para echo, eso si hay que localizar ante los puertos donde físícamente se van a conectar, yo por si acaso la prueba la he hecho con un arduino uno y la mShield sobre el puerto 3, para el sensor de mBlock tras localizar el pin correcto solo me ha bastado con poner tranto trigger como echo el mismo pin, el microcontrolador que lleva el sensor de ultrasónidos se encarga de gestionar el uso pel pin SIG. La cosa cambia un poco cuanto usamos la instrucción : "ultrasonic sensor......" el firmware de la auriga toma este camino : ```` case ULTRASONIC_SENSOR: { if(us == NULL) { us = new MeUltrasonicSensor(port); } else if(us->getPort() != port) { delete us; us = new MeUltrasonicSensor(port); } value = (float)us->distanceCm(); writeHead(); writeSerial(command_index); sendFloat(value); } break; ```` Y cotilleando la libreria "MeUltrasonicSensor" el proceso es el mismo pero sobre el mismo pin para trigger y echo, manda el disparo y cambia a INPUT para esperar el flanco del ECHO, luego ofrece el valor ya terminado a través de ```` double MeUltrasonicSensor::distanceCm(uint16_t MAXcm) ```` Ya desgranado un poco como funciona, como puñetas se ha roto, si lo conectamos a una señal PWM (servo) que si no han cambiado el "prescaler" son unos 490Hz, no creo que sea suficiente para estropearlo, cambiamos el puerto y siguió funcionando con normalidad, ¿pero?......
3.67k
vistas
8
respuestas
4
seguidores
vista previa (en vivo)
introduzca al menos un 10 caracteres
Advertencia: Mencionaste a %MENTIONS%, pero ellos no pueden ver el mensaje y no serán notificados
Guardando...
Guardado
Todos los posteos de este tema serán borrados ?
Borrador pendiente ... Click para continuar editando
Descartar borrador