Sistemas Embebidos

Sistemas Embebidos

Electrónica analógica y digital: El corazón de los sistemas autónomos.

Códigos Fuente

Códigos Fuente

C, C++, Java, Verilog, VHDL, Object Pascal, PHP, etc... Lenguajes que describen Hardware y Software inteligente.

Mecatrónica

Mecatrónica

Mecánica, Electrónica y Diseño de Software conjugados para crear nuevos dispositivos.

Mejoras: Software DSP – HAL Corriente

La función de hardware de este módulo es recoger las lecturas de corriente desde los puentes H, sin embargo, también implementa un lazo de control de corriente que pone a disposición del módulo de control para accionar el vehículo por medio de referencias de torque en los motores.

Desde el punto de vista de hardware, este módulo configura y utiliza los periféricos de captura del DSP, los cuales registran internamente los instantes en que la señal de entrada experimenta flancos de bajada o de subida. De esta manera, se puede obtener directamente el período de la señal de entrada (un tren de pulsos generado en la tarjeta de los puentes H, cuya frecuencia es proporcional a la corriente en cada motor), con un alto nivel de precisión, facilitando el cálculo de la corriente en los motores.

Gracias a la linealidad del VCO que genera el tren de pulsos (ver Sección 4.2.1), únicamente fue necesario un proceso de calibración para determinar la pendiente de la recta que relaciona la frecuencia en Hertz con la corriente en Ampères. Para obtener la constante de desplazamiento y así caracterizar completamente esta función, el módulo toma muestras de corriente durante un segundo en la inicialización con los motores apagados, utilizando ese valor como los 0A, consiguiendo así lecturas sin corrimientos.

Al igual que en el módulo HAL Instrumentos, se realizan dos tipos de filtrado de la señal de corriente, uno por el promedio de un número determinado de muestras y otro limitando la velocidad con que la lectura de corriente puede cambiar, suponiendo que la dinámica del sistema es lo suficientemente lenta. Esto último no es necesariamente cierto puesto que no se trata de una variable mecánica sino eléctrica. Sin embargo, se comprobó empíricamente que este filtrado mejora el desempeño del control de corriente al omitir transientes eléctricos que no dicen relación con el comportamiento mecánico del sistema, haciéndolo más suave y estable.

Figura 4.16: Esquema de control de corriente.

Puesto que la corriente en los motores no sólo depende del ciclo de trabajo, se implementó un controlador de corriente proporcional, cuya salida es la variación del ciclo de trabajo respecto al anterior, tal como se observa en la Figura 4.16.

Inicialmente se planteó la posibilidad de utilizar un control proporcional integrativo, sin embargo, esto generó algunos problemas de inestabilidad ya que la referencia entregada a este controlador por el módulo de control de inclinación varía rápidamente, dificultando que el error acumulado se mantenga acotado.

Adicionalmente se observó, durante el proceso de puesta en marcha, que cuando el vehículo desarrollaba una velocidad tal que llevara la corriente a su límite de 25A en los motores (dado por el rango de medición de los sensores de corriente), el controlador era incapaz de compensar, haciendo que el usuario se inclinara hacia adelante, forzando su bajada y la detención del vehículo.

Por esta razón, se aplicó una modificación a la respuesta del controlador de corriente, de manera que la compensación sea más vigorosa antes que se alcance el límite de 25A, forzando la reducción de la inclinación del usuario antes de que se requieran torques mayores a los límites para mantener la estabilidad. En la Figura 4.17 se muestra la relación entre la corriente solicitada por el controlador de inclinación y la referencia efectiva que utiliza el controlador de corriente. Dicha referencia es castigada al pasar de ±20A, con una pendiente de 2 en la recta. Para los valores de corriente inferiores, no se aplica escalamiento alguno a la referencia (pendiente 1).

Figura 4.17: Referencia efectiva del controlador de corriente.

La medida resultó ser efectiva, permitiendo la operación del vehículo a velocidades constantes por tramos largos, sin sobrepasar los límites sobre los cuales no es capaz de compensar.

Producto de la incorporación interna del lazo de control de corriente en este módulo, su interfaz resulta de estructura similar a la del módulo HAL PWM, es decir, posee una función cuya entrada es la corriente positiva deseada en Amperes, el motor que se desea accionar y la dirección de giro esperada del motor.

Mejoras: Software DSP – HAL ADC

Este módulo de abstracción de hardware, maneja las entradas analógicas del sistema, obtiene las lecturas del mando de dirección, el estado de las baterías y la presión del sensor ubicado en la plataforma para los pies.

En la función de ejecución de este módulo, se leen los valores desde los conversores análogo digital y se aplican filtrados de promedio. Se accede a estos valores a través de funciones específicas para tal fin, aplicando las conversiones necesarias. La tensión de las baterías es ponderada para generar la medición en décimas de Volt y la lectura del sistema de dirección es limitada para evitar que el vehículo se descontrole ante una eventual falla.

Mejoras: Software DSP – HAL GPIO

El módulo HAL GPIO es el encargado de administrar las entradas y salidas de propósito general GPIO del DSP.

Para este trabajo, únicamente se utilizó la salida de propósito general encargada de excitar el altavoz integrado en la tarjeta de control. Los tonos emitidos son de una frecuencia de 5kHz, determinada por la configuración fijada en el módulo HAL Timer que ejecuta este módulo cada 100µS, permitiendo que en cada paso se cambie de estado un pin específico (de alto a bajo y viceversa) completando un ciclo completo en dos pasos.

El módulo cuenta con una función que ordena la emisión de un tono, recibe la duración del tono en décimas de mili segundo y si se debe repetir indefinidamente. Esta última opción genera tonos intermitentes como el usado para la alarma de batería baja.

Mejoras: Software DSP – HAL Serial

En este módulo se sustenta la comunicación del controlador del vehículo con la pantalla LCD y con el software de supervisión en un computador. Su función básica es manejar el periférico de comunicación serial del DSP.

El protocolo de comunicación desarrollado para el vehículo se basa en comandos contenidos en un paquete de datos de 7 bytes, los cuales son interpretados y respondidos por el DSP. En la Tabla 4.2 se muestra una descripción de la estructura de cada comando.

Byte N° Descripción
1 Código de operación
2 Identificador del paquete
3 Byte de información 1
4 Byte de información 2
5 Byte de información 3
6 Byte de información 4
7 Fin de paquete (255)

Tabla 4.2: Estructura del paquete de datos que conforma cada comando

Cada comando posee un código de operación que determina su función, un identificador único para detectar una eventual pérdida de paquetes y 4 bytes destinados al envío y recepción de datos.

Para la administración del puerto serie del DSP se utiliza un enfoque similar al del módulo HAL Instrumentos, con rutinas que evitan cualquier posibilidad de bloqueo utilizando variables marcadores para indicar la ocurrencia de algún evento en vez de esperar por ellos con el sistema detenido.

La recepción de los comandos desde el exterior se hace leyendo byte a byte la información recibida desde el puerto serie hasta completar un comando completo, el cual es almacenado en una cola que puede guardar hasta 4 comandos a la espera de su procesamiento. La interfaz del módulo provee una función que consulta si existe un comando a la espera de ser procesado y otra que lee el primer comando de la cola. Así mismo, implementa también una función que envía las respuestas de los comandos atendidos, eliminándolos de la cola. Este mecanismo conduce a que sólo un comando pueda ser atendido a la vez, evitando ambigüedades en los demás módulos. Si se reciben comandos con la cola llena, serán ignorados.

Cada comando posee un código de operación que determina su función, un identificador único para detectar una eventual pérdida de paquetes y 4 bytes destinados al envío y recepción de datos.

Para la administración del puerto serie del DSP se utiliza un enfoque similar al del módulo HAL Instrumentos, con rutinas que evitan cualquier posibilidad de bloqueo utilizando variables marcadores para indicar la ocurrencia de algún evento en vez de esperar por ellos con el sistema detenido.

La recepción de los comandos desde el exterior se hace leyendo byte a byte la información recibida desde el puerto serie hasta completar un comando completo, el cual es almacenado en una cola que puede guardar hasta 4 comandos a la espera de su procesamiento. La interfaz del módulo provee una función que consulta si existe un comando a la espera de ser procesado y otra que lee el primer comando de la cola. Así mismo, implementa también una función que envía las respuestas de los comandos atendidos, eliminándolos de la cola. Este mecanismo conduce a que sólo un comando pueda ser atendido a la vez, evitando ambigüedades en los demás módulos. Si se reciben comandos con la cola llena, serán ignorados.

Mejoras: Software DSP – Módulo de Comandos

Este módulo de alto nivel tiene por objetivo interpretar y ejecutar los comandos recibidos desde el módulo HAL Serial. Para ello implementa una serie de máquinas de estado que, ayudadas por la estructura de los comandos, distribuyen su decodificación y procesamiento en varios ciclos de ejecución. De esta manera, un único comando tardará varios ciclos de ejecución del programa principal en ser completamente contestado, distribuyendo temporalmente la carga de esta tarea de menor prioridad en la CPU del DSP.

El Módulo de Comandos puede realizar 3 tipos de tareas determinadas por el código de operación del comando recibido: las tareas de lectura de un parámetro desde el vehículo, su escritura o la ejecución de una orden. Se discriminan interpretando los primeros dos bits del código de operación tal como se muestra en la Tabla 4.3.

Código de Operación Tipo de Acción
00XXXXXX No especificada
01XXXXXX Escribir Parámetro
10XXXXXX Leer Parámetro
11XXXXXX Ejecutar Orden

Tabla 4.3: Decodificación básica del código de operación.

Además del procesamiento de comandos individuales, el módulo posee un modo de flujo para ciertos comandos de lectura, en el cual un cliente solicita al DSP el envío de uno o más parámetros de forma continua, permitiendo monitorear en tiempo real variables como las lecturas de los instrumentos, corriente en los motores, etc. En este modo, el Módulo de Comandos enviará en cada ejecución un valor por el puerto serie hasta recibir un nuevo comando, el cual automáticamente detendrá el flujo, cualquiera que este sea.

Figura 4.18: Diagrama de estados del Módulo de Comandos.

En la Figura 4.18 se muestra el diagrama de estados del Módulo de Comandos de forma simplificada. El estado inicial es el de recepción que consulta al módulo HAL Serial por la llegada de algún comando. Luego de la recepción se realiza la decodificación y se deriva a la función correspondiente que terminará de decodificar el comando, realizando la acción específica y devolviendo siempre una respuesta por el puerto serie con el mismo código de operación e identificador para indicar al cliente que su solicitud ha sido atendida. En cada proceso de interpretación es posible pasar al estado de envío de mensaje de error si no se reconoce el código de operación.

Mejoras: Software DSP – Módulo de Control

Este es el módulo de mayor relevancia en la operación del vehículo, su objetivo es aplicar una estrategia de control que lo mantenga estable, permitiendo que un usuario se desplace con comodidad. Para ello se sustenta en todos los sistemas previamente descritos, abstrayéndose de sus funciones específicas.

En esencia, se aplica una estrategia de control proporcional derivativa con el ángulo de inclinación del vehículo como entrada y el torque aplicado a las ruedas como salida. Sin embargo, las condiciones reales del sistema hacen necesaria la incorporación de bloques adicionales en este esquema.

Figura 4.19: Esquema general de control del vehículo

En la Figura 4.19 se muestra el esquema general de control implementado en este módulo, el cual busca llegar a la referencia de 0° en el ángulo de inclinación. Las variables involucradas se indican en la Tabla 4.4.

Tabla 4.4: Variables utilizadas por el algoritmo de control.

La unidad IMU obtiene directamente el ángulo de inclinación y su derivada desde los instrumentos en tiempo real. Sin embargo, la lectura de θm posee un retardo de aproximadamente 200mS respecto a la lectura del giróscopo, lo cual hizo necesario aplicar una operación de compensación para estimar el valor real de la inclinación a partir de la lectura obtenida y la proyección dada por su derivada. De esta manera, la estimación utilizada tiene la forma:

donde Ɵest es la estimación obtenida y Δ es el intervalo de tiempo de la proyección.

A continuación, el valor del ángulo estimado y su derivada son ponderados por las constantes del controlador Kp y Kd con signo negativo, para así realizar la acción de compensación y llegar a la referencia de 0° para Ɵ. El valor resultante de esta operación y la suma de los valores parciales, es un torque que debe ser aplicado a ambas ruedas por igual.
Para maniobrar el vehículo, se obtiene un valor proporcional a la posición del mando de dirección que se traduce en una diferencia de torques en los motores, la cual hará girar el vehículo hacia la izquierda o hacia la derecha, permitiendo incluso el giro sobre su propio eje. Dicha diferencia se incorpora al valor de torque obtenido por el algoritmo de control principal de la siguiente manera:

donde TIzq es el torque para el motor izquierdo, TDer es el torque para el motor derecho, T es el torque obtenido por la etapa anterior y Tdir es el torque obtenido desde el sistema de dirección. Si Tdir es positivo, se aplicará más torque al motor izquierdo que al derecho causando que el vehículo doble hacia la derecha. Si este valor es negativo, se obtiene el efecto contrario.

Los torques resultantes se convierten en las referencias para el módulo HAL Corriente, el cual obtiene las corrientes que circulan por los motores y aplica un lazo de control proporcional como se muestra en la Figura 4.16. El uso de torques como referencias de corriente, para este lazo de control, se justifica por la relación existente entre la corriente por el motor y el torque generado, descritos en la ecuación (2.2), ya que los motores empleados son de imanes permanentes.

Se supone en todo momento la hipótesis de linealidad del sistema a controlar. Sin embargo, se exploró también la posibilidad de usar aproximaciones de segundo orden para las funciones trigonométricas asociadas a los ángulos de inclinación, sin resultados perceptibles por el usuario. Esto se justifica además por el hecho de que los ángulos de inclinación siempre son pequeños (menores a 10°), estando constantemente en torno al punto de operación, es decir, en posición vertical (θ=0°). Por esta razón se conservó el controlador lineal, quedando comentadas las líneas de código que incorporan la aproximación.

Para el esquema de control descrito, se utilizan dos juegos de parámetros, sintonizados empíricamente para optimizar la estabilidad y desempeño del vehículo, cuando hay un usuario sobre la plataforma y otro set para cuando este no está presente.

La necesidad de discriminar ambos estados surge del hecho de que, constructivamente el vehículo es un sistema dinámico estable cuando no hay un usuario sobre él, puesto que su centro de masa se ubica bajo el eje de pivote de la base. Sin embargo, al subir una persona, el centro de masa cambia y se ubica sobre este eje, creando una situación de péndulo invertido. Es por esta razón que los parámetros que mejor desempeño logran con un pasajero abordo, desestabilizan al vehículo sin usuario.

El cambio de parámetros se realiza al superar un determinado umbral en la lectura del sensor de fuerza, ubicado en la plataforma para los pies.

Mejoras: Software DSP – Módulo Principal

Este módulo corresponde a la función principal que ejecuta el programa del DSP. Administra el estado del vehículo y ordena la ejecución de los demás módulos como se indica en la sección 4.3.2. Puesto que las labores de inicialización y ejecución de los módulos están encapsuladas en cada uno de ellos, el código es sumamente sencillo y tiene la siguiente forma:

void main(void)
{
hal_inicializar_dsp();
mod_comando_inicializar();
mod_control_inicializar();
funcionamiento(); //Se pone en marcha el programa
}

La función hal_inicializar_dsp inicializa todos los módulos de abstracción de hardware y deja el sistema configurado para su uso. Luego se inicializan los módulos de alto nivel, para finalmente hacer un llamado a una función que contiene la operación en régimen permanente del programa.

Esta última función, al igual que muchas de las funciones críticas del sistema, posee una directiva de compilación justo encima de ella en el código, que las clasifica para luego ser cargadas en la memoria RAM del DSP, lo cual mejora su velocidad de ejecución, puesto que la memoria Flash (donde se aloja el programa), posee mayor latencia, reduciendo notoriamente el rendimiento en labores complicadas como el lazo de control de corriente o la lectura de los instrumentos IMU.

La orden de copia de estas funciones de la memoria Flash del DSP hacia la RAM se hace durante la inicialización del DSP, en la función hal_inicializar_dsp.

En régimen permanente, el vehículo puede estar en uno de cuatro estados denominados: Iniciando, Detenido, Operando y Falla. Al momento del encendido, el sistema se encuentra en el estado Iniciando, el cual espera dos segundos, permitiendo así que todas las lecturas entren en régimen permanente, para luego fijar los parámetros predeterminados del controlador, dando paso entonces al estado Detenido.

En el estado Detenido, el sistema espera la recepción de un comando de encendido desde el exterior. Al ocurrir este evento, enciende el módulo HAL PWM permitiendo que los motores reciban energía y pasa al estado Operando, del cual sólo saldrá ante una orden de apagado o la activación de alguna alarma.

En todo momento se monitorea el estado de las baterías, emitiendo un tono de alerta si la tensión baja de cierto umbral, para indicar al usuario que las baterías están prontas a agotarse y pasa a estado de falla si baja de un segundo umbral. Por otro lado, las características del circuito analógico utilizado para enviar la señal al DSP hacen que se envíen 3,3V cuando la tensión medida es cero, permitiendo pasar inmediatamente a estado de falla si se detecta la desconexión del circuito de potencia o falla del fusible.

Mejoras: Software de Monitoreo

La interfaz por comandos desarrollada para el vehículo, permite el acceso a información interna en tiempo de ejecución y es indispensable para la operación del mismo, al recibir los comandos de encendido y apagado desde los controles ubicados en la parte superior del vehículo. Sin embargo, el objetivo de este sistema de comunicación es permitir el acceso a un software de monitoreo que se ejecuta desde un computador, el cual tiene la capacidad de mostrar en tiempo real parámetros del vehículo a un operador, e incluso registrarlo en archivos para su posterior análisis.

Este programa fue realizado bajo el entorno de desarrollo de software Delphi, el cual se especializa en la programación visual, permitiendo la generación de interfaces gráficas de manera sencilla utilizando el lenguaje de programación Object Pascal. El programa compilado es un archivo ejecutable para sistemas operativos Windows. En la Figura 4.20 se muestra la interfaz gráfica del programa de monitoreo al momento de iniciarse.

Figura 4.20: Interfaz gráfica del software de monitoreo del vehículo.

El programa se comunica a través de una interfaz RS-232, cuyo hardware es el conversor a USB incorporado en la tarjeta de control, por lo que únicamente se requiere un puerto USB disponible en un computador con plataforma Windows para utilizarlo.

La interfaz gráfica posee un área llamada “Datos Recibidos”, que muestra automáticamente el valor de los parámetros allí incluidos al recibir la información desde el vehículo. De esta manera, si se envía al vehículo el comando que solicita el flujo de datos del módulo IMU, automáticamente los indicadores de la parte superior mostrarán la inclinación y la velocidad de inclinación en tiempo real y el valor numérico de las lecturas. Lo mismo sucede con cualquiera de los otros datos que se solicite. El indicador vertical, ubicado al costado derecho de esta área, permite visualizar el valor de la acción de control calculada por el vehículo en tiempo real, si es que se solicita esa información (ver Figura 4.20).

La sección “Interfaz” posee una representación de los controles disponibles en la parte superior del mando de dirección en el vehículo, siendo posible emular su funcionamiento.

En la sección “Comandos” se pueden enviar comandos arbitrarios. Es posible elegir comandos predefinidos de una lista, pero siempre se permite escribir los códigos manualmente, al igual que el valor enviado.

Este software posee también un historial de los comandos enviados, que también registra algunos de los comandos recibidos.

Los comandos implementados en el vehículo se muestran en la Tabla 4.5:

Nombre de comando

Código decimal

Efecto sobre el vehículo

PING_DSP

192

Este comando no ejecuta ninguna acción excepto generar la devolución del mismo. Su objetivo es verificar conectividad con el controlador.

TRIP_MOTOR

193

Apaga de inmediato los motores. Es el comando de detención del vehículo.

UNLOCK_MOTOR

194

El controlador esperará que el vehículo se encuentre detenido y vertical para encender efectivamente los motores.

FIJAR_INCL_NULA

196

Envía una orden a los inclinómetros, para que éstos fijen su ángulo 0° en la posición actual.

DETENER_FLUJOS

197

Detiene los flujos de datos si los hubiera.

LEER_INCLINOMETROS

129

Envía la lectura de inclinación al software de monitoreo.

LEER_GIROSCOPOS

130

Envía la lectura de velocidad de inclinación al software de monitoreo.

LEER_CORRIENTE_D

131

Envía la lectura de corriente del motor derecho al software de monitoreo.

LEER_CORRIENTE_I

132

Envía la lectura de corriente del motor izquierdo al software de monitoreo.

FLUJO_INCLINOMETROS

133

Envía un flujo de datos con los valores en tiempo real de inclinación al software de monitoreo.

FLUJO_GIROSCOPOS

134

Envía un flujo de datos con los valores en tiempo real de velocidad de inclinación al software de monitoreo.

FLUJO_CORRIENTE_MD

135

Envía un flujo de datos con la corriente en el motor derecho al software de monitoreo.

FLUJO_CORRIENTE_MI

136

Envía un flujo de datos con la corriente en el motor izquierdo al software de monitoreo.

FLUJO_IMU

137

Envía un flujo de datos con los datos tanto de inclinación como de velocidad de inclinación al software de monitoreo.

FLUJO_ADC

138

Envía un flujo de datos con el valor obtenido del sistema de dirección, la lectura de las baterías y la presión en el sensor de fuerza, al software de monitoreo.

FLUJO_CONTROL

141

Envía un flujo de datos con la salida del algoritmo de control PD al software de monitoreo.

SET_MD_F_DUTY

65

Fija el ciclo de trabajo del motor derecho hacia adelante. (Si está operando el controlador, éste sobre escribirá este valor)

SET_MD_B_DUTY

66

Fija el ciclo de trabajo del motor derecho hacia atrás. (Si está operando el controlador, éste sobre escribirá este valor)

SET_MI_F_DUTY

67

Fija el ciclo de trabajo del motor izquierdo hacia adelante. (Si está operando el controlador, éste sobre escribirá este valor)

SET_MI_B_DUTY

68

Fija el ciclo de trabajo del motor izquierdo hacia atrás. (Si está operando el controlador, éste sobre escribirá este valor)

SET_CTRL_KP

69

Fija la constante proporcional del controlador de inclinación para cuando hay un usuario sobre la plataforma.

SET_CTRL_KD

70

Fija la constante derivativa del controlador de inclinación para cuando hay un usuario sobre la plataforma

Tabla 4.5: Descripción de comandos del vehículo.

Finalmente, los controles de la parte inferior izquierda de la interfaz gráfica (ver Figura 4.20) permiten almacenar flujos de datos solicitados al vehículo. Una vez que se detiene la captura, se puede generar un archivo de texto separado por tabulaciones con los valores recibidos durante el período de captura.

Resultados: Introducción

El vehículo terminado fue sometido a un intenso período de pruebas, en el cual estuvo expuesto a movimientos violentos, largos tiempos de operación, funcionamiento en superficies irregulares e incluso algunos golpes que pusieron a prueba, tanto el montaje de los componentes electrónicos, como a la estructura mecánica del vehículo.

En este capítulo se abordan en detalle los resultados técnicos y de percepción de los cambios realizados, desde un punto de vista comparativo, respecto al estado inicial del vehículo, verificándose que éste consiguió operar sin necesidad de modificaciones adicionales a las ya expuestas, con un comportamiento confiable.

La nueva organización de los componentes, que se mantuvo fiel al diseño planteado en este trabajo, permite un armado y desarmado completo del vehículo en alrededor de 3 horas. En este tiempo se puede pasar de un vehículo totalmente funcional a la estructura de acero de la base vacía, con los componentes separados y viceversa. Esto resulta sumamente útil para las labores de diagnóstico y mantenimiento.

Resultados: Aspectos Mecánicos

El diseño estructural del vehículo no sufrió mayores modificaciones, por lo que sus características de firmeza y robustez ante condiciones difíciles se mantuvieron consecuentemente. Sin embargo, la modificación realizada al sistema de dirección sufrió una falla durante el período de pruebas, al ceder la soldadura que une el eje sobre el cual pivota el mando de dirección, a la estructura de acero de la base. Dicha situación se solucionó soldando nuevamente la pieza a la estructura, con un tipo diferente de soldadura, aportando más material a la unión en busca de fortalecerla.

A pesar de lo anterior, el nuevo mando de dirección funcionó correctamente luego de algunos ajustes en el sistema de montaje del potenciómetro que mide la posición del mando de dirección. El movimiento lateral permite maniobrar el vehículo con movimientos naturales de inclinación del cuerpo, tal como se esperaba.

La cubierta exterior del vehículo también jugó un rol importante al prevenir el ingreso de suciedad al interior, protegiendo también los componentes internos de los golpes, así como a los usuarios, puesto que su forma redonda, sin puntas filosas, evita cualquier tipo de lesión por impacto. Cabe destacar que en ningún caso el vehículo golpeó con fuerza a un usuario luego de perder el equilibrio, puesto que el proceso de aprendizaje siempre se realizó a velocidades reducidas y bajo supervisión. Además, se tomaron medidas de apagado automático del vehículo ante detección de golpes o ángulos de inclinación extremos, tal como se describió anteriormente, las cuales funcionaron de manera adecuada.

Páginas:«12345»

Categorías

Enlaces

Estadísticas


eXTReMe Tracker