Misión 08 del Lince: Ciudad Accesible en Estepona | AIDARAC

Dentro del proyecto AIDARAC / MonteSTeam, abordamos nuestra octava misión: Ciudad Accesible.

Una ciudad no es igual de “recorrible” para todo el mundo. Un bordillo sin rebaje, una acera de 70 cm invadida por una terraza o un tramo de adoquín irregular pueden convertir un paseo de cinco minutos en un obstáculo infranqueable para una persona usuaria de silla de ruedas, con muletas, con un carrito de bebé o, simplemente, con una rodilla que no responde como antes. La accesibilidad no es un lujo ni una reivindicación menor: es la condición para que el espacio público sea de todos.

Esta misión no parte de una hipótesis pedagógica aislada. El uso de datos ciudadanos y cartografía colaborativa para detectar barreras arquitectónicas cuenta con un recorrido consolidado en la literatura científica:

• Mobasheri, Deister y Dieterich (2017), en Journal of Open Geospatial Data, Software and Standards: presentan Wheelmap como plataforma de ciencia ciudadana para cartografiar la accesibilidad en silla de ruedas a partir de datos de OpenStreetMap.
• Mobasheri, Sun, Loos y Ali (2017), en Sustainability, 9(6), 997: evalúan si los conjuntos de datos de OpenStreetMap, generados por voluntariado, son suficientemente fiables para servicios de enrutamiento especializado destinados a personas con movilidad reducida.
• Biagi, Brovelli y Stucchi (2020), en ISPRS Archives XLIII-B4: comparan distintas técnicas para cartografiar la accesibilidad en OpenStreetMap e identificar barreras arquitectónicas de forma sistemática.
• Froehlich, Saugstad, Saha y Johnson (2022), arXiv:2207.13626: abordan el reto de cartografiar y evaluar la accesibilidad de las aceras en contextos socioculturales y geográficos diversos.
• El proyecto europeo CAP4Access (Universidad de Heidelberg) demostró que la incompletitud de los datos de accesibilidad en OpenStreetMap es, en sí misma, un problema medible y mejorable mediante campañas de mapeo ciudadano.

El objetivo de esta misión no es señalar culpables, sino medir la accesibilidad con rigor y proponer mejoras concretas, tomando como punto de partida el entorno del IES Monterroso (Avda. Santo Tomás de Aquino, Estepona) y su conexión con el casco antiguo, el Paseo Marítimo y los espacios verdes cercanos.

1. Investigación en el mapa: OpenStreetMap y Overpass Turbo

Antes de salir a la calle con el circuito, hacemos un primer diagnóstico “de escritorio” usando los datos ya existentes en OpenStreetMap (OSM), la cartografía libre y colaborativa más grande del mundo.

Tutorial paso a paso

1. Abrir Overpass Turbo: entra en overpass-turbo.eu. Es un editor de consultas que interroga la base de datos de OSM y dibuja el resultado directamente sobre un mapa.
2. Centrar el mapa en Estepona: usa el buscador de la esquina superior izquierda (icono de lupa) y escribe “Estepona, España” para centrar la vista.
3. Pegar la consulta en el panel izquierdo (sustituye el contenido de ejemplo) y pulsar Run (▶):

Overpass QL

[out:json][timeout:25];
area["name"="Estepona"]["boundary"="administrative"]->.a;
(
  node["wheelchair"](area.a);
  way["wheelchair"](area.a);
  node["kerb"](area.a);
  way["sidewalk"](area.a);
  node["tactile_paving"](area.a);
);
out body;
>;
out skel qt;

4. Leer el resultado: cada punto o línea coloreada es un elemento con alguna etiqueta de accesibilidad ya registrada. Pulsando sobre un elemento en el mapa se abre su ficha de etiquetas (wheelchair=yes/limited/no, kerb=raised/lowered/flush, tactile_paving=yes/no…).
5. Exportar los datos: en el menú Export, se puede descargar como GeoJSON o como imagen del mapa, para usarlo después en el análisis y en la entrada del blog.
6. Detectar los “vacíos”: la lectura más importante casi nunca es “aquí es accesible” o “aquí no lo es”, sino dónde no hay ningún dato registrado. Una zona en blanco en el mapa de Overpass no significa que sea accesible: significa que nadie la ha documentado todavía. Ese vacío es, en sí mismo, un resultado científico y el punto de partida para nuestra recogida de datos en campo.

2. El Hardware: Circuito Simulado en Wokwi

Para el trabajo en el aula y en el simulador Wokwi, combinamos dos sensores que ya conocéis de misiones anteriores, aplicados aquí a un problema distinto: la accesibilidad.

• Sensor de distancia HC-SR04 (mide anchura de paso y detecta obstáculos/estrechamientos en la ruta).
• Sensor inercial MPU6050 (mide la inclinación —pendiente de rampas— y la vibración del recorrido —estado del pavimento—).

Esquema de conexiones (Arduino UNO / Nano en Wokwi):

• Sensor Ultrasónico HC-SR04:
  • VCC: Conectado a 5V de la placa Arduino.
  • GND: Conectado a GND (Tierra).
  • Trig: Conectado al pin digital D9.
  • Echo: Conectado al pin digital D10.
• Sensor Inercial MPU6050 (I2C):
  • VCC: Conectado a 3.3V (o 5V, según el módulo) de la placa Arduino.
  • GND: Conectado a GND.
  • SCL: Conectado al pin A5 (Arduino UNO/Nano).
  • SDA: Conectado al pin A4 (Arduino UNO/Nano).
• LED Indicador de Alerta (barrera detectada):
  • Ánodo (+): Conectado al pin digital D13 a través de una resistencia de 220Ω.
  • Cátodo (-): Conectado a GND.

Nota técnica y pedagógica: en el simulador usamos el componente nativo MPU6050 de Wokwi, que reproduce fielmente el comportamiento del acelerómetro/giroscopio por I2C. En el aula, el sensor físico disponible es un módulo GY-91 (que integra un MPU9250 + un BMP280), no un MPU6050 puro — la diferencia entre ambos y por qué necesita su propio código se explica en el apartado 4.

3. El Programa de Control (Wokwi — Simulación)

Opción A: Código C++ para Arduino UNO/Nano (Wokwi, MPU6050 + HC-SR04)

C++

// Misión 08: Ciudad Accesible - Código Arduino UNO (Wokwi, simulado con MPU6050)
#include <Wire.h>
#include <MPU6050.h>

MPU6050 mpu;

const int PIN_TRIG = 9;
const int PIN_ECHO = 10;
const int PIN_LED_ALERTA = 13;

const float ANCHURA_MINIMA_CM = 90.0;   // Anchura mínima considerada accesible
const float PENDIENTE_MAXIMA_GRADOS = 8.0; // Pendiente máxima recomendada (norma habitual de accesibilidad)

void setup() {
  Serial.begin(9600);
  pinMode(PIN_TRIG, OUTPUT);
  pinMode(PIN_ECHO, INPUT);
  pinMode(PIN_LED_ALERTA, OUTPUT);

  Wire.begin();
  mpu.initialize();

  Serial.println("--- MONITOREO CIUDAD ACCESIBLE ESTEPONA INICIADO ---");
}

void loop() {
  // 1. Medición de anchura de paso / obstáculos (HC-SR04)
  digitalWrite(PIN_TRIG, LOW);
  delayMicroseconds(2);
  digitalWrite(PIN_TRIG, HIGH);
  delayMicroseconds(10);
  digitalWrite(PIN_TRIG, LOW);

  long duracion = pulseIn(PIN_ECHO, HIGH);
  float distanciaCm = duracion * 0.034 / 2;

  // 2. Medición de inclinación (MPU6050)
  int16_t ax, ay, az;
  mpu.getAcceleration(&ax, &ay, &az);
  float pendienteGrados = atan2(ax, sqrt((long)ay * ay + (long)az * az)) * 180.0 / PI;

  // 3. Telemetría vía Puerto Serie (Formato clave:valor)
  Serial.print("ANCHURA_CM:");
  Serial.print(distanciaCm);
  Serial.print(" | PENDIENTE_GRADOS:");
  Serial.println(pendienteGrados);

  // 4. Umbral de accesibilidad (anchura insuficiente o pendiente excesiva)
  if (distanciaCm < ANCHURA_MINIMA_CM || abs(pendienteGrados) > PENDIENTE_MAXIMA_GRADOS) {
    digitalWrite(PIN_LED_ALERTA, HIGH); // Barrera detectada
  } else {
    digitalWrite(PIN_LED_ALERTA, LOW);  // Tramo accesible
  }

  delay(2000); // Muestreo cada 2 segundos
}

⚠️ Aviso importante — simulación en Wokwi

En el simulador Wokwi, el sensor MPU6050 no gira ni se inclina en tiempo real: no existe ningún control que puedas mover mientras la simulación está en marcha. Los valores de aceleración se fijan antes de arrancar (editando diagram.json) y se mantienen fijos durante toda la ejecución. Es decir: el simulador nos sirve para comprobar que el código funciona y que la lógica de aviso de barrera es correcta, no para “notar” una rampa como si camináramos con él.

La medición real de la pendiente —la que de verdad cambia según por dónde caminéis— solo la vamos a obtener con el montaje físico (GY-91) en la calle. Así que si en Wokwi el número no se mueve al tocar nada, es normal: no es un fallo vuestro, es una limitación del simulador.

4. Montaje Real en el Aula: GY-91 (no MPU6050)

En clase no disponemos de un módulo MPU6050 “puro”, sino de un GY-91, que combina un MPU9250 (acelerómetro + giroscopio + magnetómetro) con un BMP280 (presión/altitud). El bloque de acelerómetro y giroscopio del MPU9250 es, a nivel de registros, casi idéntico al del MPU6050 — pero su registro de identificación WHO_AM_I devuelve 0x71 en vez de 0x68, y muchas librerías de MPU6050 comprueban ese valor al arrancar y se detienen si no coincide. Por eso el montaje real necesita su propio código, aunque el cableado y la magnitud física medida sean los mismos.

Esquema de conexiones (GY-91 real, idéntico en pines al esquema simulado):

• VCC → 3.3V de la placa (el GY-91 trabaja a 3.3V; comprobar la etiqueta del módulo antes de conectar a 5V).
• GND → GND
• SCL → A5
• SDA → A4
• HC-SR04 y LED de alerta: igual que en el apartado 2.

Opción B: Código C++ para Arduino con GY-91 (MPU9250) real

C++

// Misión 08: Ciudad Accesible - Código Arduino UNO (montaje real, GY-91 / MPU9250)
// Requiere la librería MPU9250_WE (Gestor de Librerías del IDE de Arduino)
#include <Wire.h>
#include <MPU9250_WE.h>

#define MPU9250_ADDR 0x68
MPU9250_WE mpu = MPU9250_WE(MPU9250_ADDR);

const int PIN_TRIG = 9;
const int PIN_ECHO = 10;
const int PIN_LED_ALERTA = 13;

const float ANCHURA_MINIMA_CM = 90.0;
const float PENDIENTE_MAXIMA_GRADOS = 8.0;

void setup() {
  Serial.begin(9600);
  pinMode(PIN_TRIG, OUTPUT);
  pinMode(PIN_ECHO, INPUT);
  pinMode(PIN_LED_ALERTA, OUTPUT);

  Wire.begin();
  if (!mpu.init()) {
    Serial.println("GY-91 (MPU9250) no detectado. Revisa el cableado I2C.");
  }
  mpu.autoOffsets(); // Calibración en reposo sobre superficie horizontal

  Serial.println("--- MONITOREO CIUDAD ACCESIBLE ESTEPONA (HARDWARE REAL) INICIADO ---");
}

void loop() {
  // 1. Medición de anchura de paso / obstáculos (HC-SR04)
  digitalWrite(PIN_TRIG, LOW);
  delayMicroseconds(2);
  digitalWrite(PIN_TRIG, HIGH);
  delayMicroseconds(10);
  digitalWrite(PIN_TRIG, LOW);

  long duracion = pulseIn(PIN_ECHO, HIGH);
  float distanciaCm = duracion * 0.034 / 2;

  // 2. Medición de inclinación (GY-91 / MPU9250)
  xyzFloat angulo = mpu.getAngles();
  float pendienteGrados = angulo.x;

  // 3. Telemetría vía Puerto Serie
  Serial.print("ANCHURA_CM:");
  Serial.print(distanciaCm);
  Serial.print(" | PENDIENTE_GRADOS:");
  Serial.println(pendienteGrados);

  // 4. Umbral de accesibilidad
  if (distanciaCm < ANCHURA_MINIMA_CM || abs(pendienteGrados) > PENDIENTE_MAXIMA_GRADOS) {
    digitalWrite(PIN_LED_ALERTA, HIGH);
  } else {
    digitalWrite(PIN_LED_ALERTA, LOW);
  }

  delay(2000);
}

Si al cargar el código real aparece mpu.init() devolviendo false, comprobad primero con un sencillo escáner I2C (Wire.h + bucle de direcciones 0x00–0x7F) que el módulo responde en 0x68; algunos GY-91 vienen con AD0 puenteado a 0x69.

5. Rutas propuestas en Estepona

Tomando el IES Monterroso (Avda. Santo Tomás de Aquino) como punto de partida, proponemos cuatro recorridos cortos y variados, pensados para completarse en una sesión de clase:

1. IES Monterroso → Casco Antiguo: calles estrechas, adoquinadas e irregulares; permite comparar pavimento histórico frente a acera moderna.
2. IES Monterroso → Paseo Marítimo / Playa de la Rada: tramo llano, ancho y en principio muy accesible — sirve como “control” de referencia frente a los demás.
3. IES Monterroso → Parque del Calvario / Plaza Alonso Quijano: zona verde con rampas, bordillos y accesos a comprobar.
4. Avenida de España / Avenida Santo Tomás de Aquino: eje principal de tráfico, con pasos de peatones, terrazas y mobiliario urbano que puede invadir la acera.

Cada grupo de alumnado recorre una ruta con el montaje (simulado primero en Wokwi para validar el código, después real con el GY-91) y registra sus datos junto con las coordenadas GPS del móvil, para poder situarlos después sobre el mapa de Overpass del apartado 1.

6. Simulación de datos conseguidos

A modo de ejemplo de cómo se vería la tabla de resultados una vez completadas las cuatro rutas (datos simulados para validar el análisis antes de salir a la calle):

Punto / Tramo	Anchura mín. (cm)	Pendiente máx. (°)	Estado OSM previo	Resultado
Casco Antiguo — C/ Real	68	4	Sin datos	Barrera (anchura)
Paseo Marítimo — Playa de la Rada	210	1	wheelchair=yes	Accesible
Parque del Calvario — rampa acceso	140	11	Sin datos	Barrera (pendiente)
Plaza Alonso Quijano	180	3	wheelchair=limited	Accesible
Avda. Santo Tomás de Aquino — cruce IES	95	2	Sin datos	Accesible (límite)

7. Análisis, conclusiones y propuesta

Cruzando lo medido con lo que ya figuraba en OpenStreetMap se observa el patrón más interesante de la misión: los tramos con mayor problema de accesibilidad real (Casco Antiguo, rampa del Calvario) son precisamente los que no tenían ningún dato registrado en el mapa colaborativo, mientras que los tramos ya etiquetados (Paseo Marítimo, Plaza Alonso Quijano) resultan, en efecto, accesibles. Esto confirma lo que señalan Mobasheri et al. (2017) sobre la incompletitud de OSM como reto central, más que la falta de fiabilidad de los datos ya existentes.

Propuesta del alumnado:

• Editar OpenStreetMap añadiendo las etiquetas de accesibilidad detectadas en los tramos sin datos, contribuyendo directamente a cerrar ese vacío de información.
• Elaborar el “Mapa de Rutas Accesibles de Estepona”, destacando alternativas cuando la ruta más corta no sea la más accesible.
• Trasladar la propuesta de mejora concreta (rebaje de bordillo, ensanche de acera, corrección de pendiente) a quien corresponda, con los datos como argumento objetivo — no como queja, sino como evidencia.

Con esta misión, el alumnado no solo practica programación y electrónica, sino que experimenta en primera persona —muchas veces literalmente, empujando el carrito del sensor por una acera estrecha— lo que significa que una ciudad sea, o no, de todos.