SemiWheelNav - Navegación semi-autónoma de Sillas de rueda mediante sensado externo

Dentro de este proyecto se tiene como objetivo principal la creación de un sistema de ayuda a la navegación de sillas de ruedas que no sofistique la misma, sea realmente útil al usuario final, y que se apoye en la infraestructura del edificio donde se instale, minimizando el mantenimiento (que es uno de los principales problemas de balizas, líneas, etc.). Según esta idea, la silla recibirá la información necesaria del entorno, para que en función de las opciones seleccionadas por el usuario, sea ayudada para moverse dentro del mismo, especialmente en situaciones difíciles (entornos intrincados, pasillos estrechos, etc.). Asimismo se podría extrapolar esta idea para otros sistemas asistenciales, como robots móviles de vigilancia, tipo guía de museos, etc.

No funcional - No bloquear el rendimiento RT del bus CAN-DX

• Ser capaces de comunicar dos pc_industrial_ts-7800 a través de su módulo CAN

• Ser capaces de comunicar tres pc_industrial_ts-7800 a través de su módulo CAN
• Realizar un análisis de tramas con el analizador CAN, analizando el tráfico de los PCs Industriales.

• Montar la Unidad de Control la unidad de potencia y los Motores (Comprobar que funcionan)
• Analizar el tráfico DX que hay en el bus haciendo uso del analizador de CAN

• Realizar una aplicación en el PC industrial que sea capaz de leer el tráficoDX e introducirlo en una estructura de datos. Su contenido debe ser coherente con la tramaDX original.

• Programar los PC Industriales para que sean capaz de sustituir conceptualmente al módulo de potencia.
• Un primer paso puede ser cambiar la dirección del módulo de potencia y que el PC-Industrial haga de módulo de potencia pasarela. Recibiendo los mensajes del UCM y reenviándolos a la UP

3 PCs industriales, llamados CharlieX (antes geusinX)

• Charlie1: 192.168.0.41
• Charlie2: 192.168.0.42
• Charlie1: 192.168.0.43

<propuesta> <planteadas y descartadas y razón>

• pc_industrial_ts-7800
• Analizador CAN CPC-USB/ARM7
• DXRemoteDolphin

• Apuntes de CAN de la asignatura de Sistemas, EMC (www.dte.us.es)

Dani Cagigas, Pablo Iñigo, Víctor Ferrer.

Toma de contacto, presentación de los miembros e intercambio de ideas.

Dani Cagigas, Pablo Iñigo, Manuel Caballero.

Se definen los objetivos incrementales del proyecto. Se revisa el material existente y se comparten ideas sobre el proyecto.

Pablo Iñigo, Manuel Caballero, Víctor Ferrer.
- Hemos identificado los elementos del sistema DX
- Las baterias van a 24 voltios, es decir 2 baterías de 12 voltios en serie

1. (Cancelada)

Dani Cagigas, Pablo Íñigo, Manuel Caballero, Víctor Ferrer.
- Hemos conseguido comunicado dos PCs industriales por CAN, instalando sus módulos ok etc.
- Hemos probado el sistema DX con la fuente de alimentación

objetivos de siguiente semana: - Adecuar los voltajes del sistema CAN, presumiblemente 24V al can de los PCsIndustriales (Minolo y Cagigas se encargan de ellos) ¿probablemente con alguna técnica similar a un MAX232?

Dani Cagigas, Pablo Iñigo, Manuel Caballero, Víctor Ferrer.
 - Se ha construido el cable directo RS232 de tres salidas para conectar dos pcs industriales y el analizador CAN. (testeado y funcionando)
 - Se ha investigado sobre la utilización del analizador CAN, módulos del kernel de linux necesarios y forma de ejecutar el servidor horch_mc

Minolo y Pablo

1. Confirmamos que existe un pico en el protocolo Can-DX utilizando el osciloscopio. Este hecho era ya comentado en la documentación (pg 33 del DX voumen 1- SYSTEM DESCRIPTION). La tensión del pico es V+ en lugar de 12V como se menciona en la documentación. Es decir la tensión del pico es la tensión de entrada. Esto se comprueba en siguiente experimento de osciloscopio:
2. ACLARACIÓN:
   1. la linea superior (amarilla, canal 1) es CANL
   2. la linea inferior (azul, canal 2) es CANH

- La tensión máxima del dispositivo es de 36 V, como la fuente es 30V no hay peligro (por el cartelíto típico de no tocar de la fuente).

1. Parece (creemos haber visto en la documentación) que la frecuencia por defecto es de 2.4kbps. Sin embargo, con el osciloscopio hemos comprobado que la frecuencia a la que parece trabajar actualmente (puede que por defecto) es del orden de 100kbps (a ojimetro ¿alguna frecuencia estandar cercana a esta? 115200bps). Esto es interesante porque a priori sería compatible con la placa ts-can1 cuyas limitaciones de frecuencia no permiten sintonizar a 2.4kbps y sí a 100kbps (porque tienen que ser múltiplos de 1kbps).
   1. Observación: Puede que no pase nada si las frecuencias son similares. No sabemos si la siguiente afirmación será extrapolable al CAN: Algunos protoclos de comunicaciones como RS232 utilizan un bit de start que sincroniza y a partir de este momento el “error acumulado en el desfase temporal” se resetea. Esto es una característica de cualquier protocolo asincrono. Debe haber una forma de evaluar el error en la frecuencia con la longitud máxima de la trama. De esta forma una frecuencia no exactamente igual podría ser válida para comunicar dos dispositivos.
   2. Observación: Parece ser conveniente el trabajar a 115200bps (además de por los motivos evidentes algoritmicos) porque (según la observación anterior) una frecuencia mayor permitiria ajustar el tscan1 a una frecuencia adecuada (múltiplos 1k) ya que el error porcentual sería más bajo que si se hiciera lo mismo con una frecuencia más baja (ej: 2400bps, en el tscan1 deberíamos trabajar a 2000bps - 16.6% de error). Sin embargo trabajar a 115200 podemos trabajar en el tscan1 a 115kbps - 0.17%)

1. Una duda que surge tras experimentos con el osciloscopio es: ¿por qué el bus DX parece utilizar como parte del protocolo “incumplimiento del par diferencial” mientras que el ts-can1 parece experimentalmente que no necesita este tipo de mecanismos (según el experimento ./sendburst…)?¿Es esto parte del protocolo CAN, del protocolo DX?¿No era DX un protocolo montado sobre CAN?
2. DEFINICIÓN NUESTRA: “Modo Reposo” - Cuando la UCM no transmite ningún tipo de trama por el bus CAN y solo hay actividad en el CANL con el módulo de potencia.
   1. Es posible que la UCM detecte que no hay ningún dispositivo al que mandar ordenes y se inhiba su actividad en el bus (según lo observado en el osciloscopio empíricamente el CANH no tiene actividad - ver imagen).
   2. Propuesta: Si le conectamos el módulo funcionar de luces, o el motor: el comportamiento de la UCM seguramente sea distinto (parece que está en un modo reposo y podrián justificar esas violaciones del par diferencial). Una forma de comprobar que esto es así es conectar directamente la silla o adquirir un módulo extra para DX para que se registre y analizar el protocolo.

1. MENCIONAR: Según la documentación existe un modo “DRIVE INHIBIT” que se activa cuando el sistema está en carga y otras situaciones. En estas situaciones aparece en el display de la UCM un guión “-”. En este modo es posible que este detectando nuestra fuente como que la batería está en carga. Pensamos así porque vemos los leds de batería baja activados.
2. TEORIA: El modo DRIVE INHIBIT y nuestro “Modo reposo” son lo mismo.
3. Respecto a esta teoría y a las dudas de sobre si el DX trabaja sobre CAN o una extensión del mismo todavía no se puede decir nada porque cabe la posiblidad de que CAN pueda trabajar con una sola línea según creemos haber leido en internet. Si DX fuera una extensión y violara de forma incompatible el protocolo CAN sería un problema crítico para utilizar los módulos TSCAN1.

- Todavía no hemos visto en el osciloscopio ningún comportamiento relacionado con las órdenes del usuario. Esto puede ser producido por el problema comentado anteriormente (“”) - Si queremos interactuar en el sistema DX seguramente necesitaremos detectar la señal de sincronimo (pico de tensión) emitida por la UCM. Probablemente si implementamos software compatible con DX tendremos que ser conscientes de cuando ocurre esto. Se plantea tener una pequeña extensión del hardware para detectar ese pico y utilizar como interrupción al procesador para que el software reinicie las variables necesarias.

CONCLUSIONES

1. Realmente aunque yo (Pablo) creo que llegamos a comprobar en su día que el módulo DX era “incomunicable” con los TS-7800, realmente no recuerdo la razón. Lo que si recuerdo es que el analizador can podía esnifar tramas y monitorizar entre dos pcs industriales. La frecuencia no fue un problema en este experimento porque sabíamos que todo trabajaba a 1Mbps. Por otro lado, experimentamos que el ts7800 no era capaz de leer tramas del bus DX ni tampoco el Snifer. Ahora surge la pregunta de si realmente las frecuencias de estos elementos mencionados era la adecuada para trabajar con el bus DX. ES DECIR: Realmente no podemos afirmar que el módulo DX no se pueda comunicar con los pcs-industriales, esto está todavía por ver y es un experimento que podemos hacer desde ya.