Tras analizar todas las partes de LibreServo, he decidido realizar de nuevo varios cambios de diseño. Estoy contento con los resultados obtenidos con la placa de test ya que sin ella hubiera sido imposible analizar todos los componentes por separado y detectar todos los errores y fallos que he encontrado, es algo que tendría que haber hecho desde un primer momento y que me hubiera ahorrado muchísimo tiempo. Las conclusiones son las siguientes:
Sensor de Corriente
Como vimos en el analísis del sensor ZXCT1010, no voy a seguir usando dicho sensor, como sustituto usaré el ACS711KE de 15A. Un sensor que mide corriente en ambos sentidos, que puedo proteger fácilmente contra tensión inversa y que me asegura que en picos de corriente, pase lo que pase, el sensor nunca me generará una tensión superior al que admite el microcontrolador.
Protección ante cambio de polaridad de alimentación
No es nada descabellado pensar que al trabajar con baterías, conectores... en algún descuido conectemos la batería al revés, a todos nos ha pasado. En un circuito normal sin protección y trabajando con baterías LIPO que pueden dar decenas de amperios sin despeinarse, eso significa que el descuido va a significar quemar uno o varios componentes al instante, microcontralador, sensores, drivers... Incluso las propias pistas del PCB he visto fundirse y saltar en menos de un segundo al conectar una batería al revés.
Una forma sencilla, pero eficaz, de proteger un circuito ante un cambio de polaridad de alimentación es usar un mosfet P. En nuestro caso he elegido el P5103EMA, por su pequeño tamaño, por su bajo RDS(ON) de menos de 0.05 Ohms en condiciones normales y por soportar tensión inversa de hasta 20V. En las diferentes pruebas que he realizado se ha comportado de manera esperada sin presentar problema alguno.
Protección de cambio polaridad con Mosfet P
En el caso a) VGS es negativo por lo que el transistor se activa y funciona como un interruptor cerrado, mientras que en el caso b) VGS es positivo por lo que el transistor mosfet funciona como un interruptor abierto y no circula corriente protegiendo al resto del circuito.
Nueva alimentación, mpm3610
Tras el extenso análisis del mpm3610 que hice, el circuito de alimentación final constará de un mpm3610 a 3.8V seguido de una ferrita de 2A que filtrará la señal antes del AP2112 que será el que de los 3.3V.
Sensor de temperatura NTC
El sensor de temperatura no dio problema alguno y funcionó de la manera esperada. Lo probé en varias condiciones de temperatura entre los 5 grados del frigorífico y los 80 grados del soldador de aire (preconfigurado) y la respuesta siempre fue rápida y muy cercana a la realidad. Lo único complejo fue la programación, que una vez encontrada la fórmula adecuada no resultaba de mayor problema:
if(dma_adc1_buff[1]==2048) external_temp_A = 2047*3.3/4096; //Volt=lectura*3.3V*4096 (Evitar en la fórmula log(1)=0 y X/0 es indeterminación)
else external_temp_A = dma_adc1_buff[1]*3.3/4096; //Volt=lectura*3.3V*4096
external_temp_B = 3.3-external_temp_A; //Caida_Volt=3.3-Volt
external_temp_B = external_temp_B/10000; //Corriente=Caida_Volt/10KOhms
external_temp = external_temp_A/external_temp_B; //R2=Volt/Corriente
external_temp_A = 3435/log(10000/external_temp); //Fórmula cálculo de Temp en NTC
external_temp = ((25+273.15)*external_temp_A)/(external_temp_A-(25+273.15))-273.15;
Nuevo led RGB más compacto
El nuevo led RGB es mucho más compacto que la versión anterior y su brillo sigue siendo totalmente notable. El nuevo led ASMB-KTF0-0A306 reduce su tamaño de 3,2x2,8 mm a 2,2x2 mm. No tengo un colorímetro, pero a ojo el blanco se consigue con las siguientes resistencias:
- Led Rojo: 187 Ohms (3,37mA)
- Led Verde: 270 Ohms (2.23mA)
- Led Azul: 309 Ohms (2.35mA)
Comunicación serie RS-232 vs RS-485
Se han realizado pruebas y en ambos casos se han llegado a los 9 Mbps sin problema alguno, incluso intentando meter ruido eléctrico con un motor externo. El problema está en que a pesar de que con dos cables con RS-232 podrías tener comunicación full-duplex, fabricantes como Robotis que fabrican servos con RS-232 y RS-485 recomiendan usar RS-485 sobre RS-232 casi en cualquier circunstancia y Lynxmotion, que analicé hace un tiempo, sólo ofrecen RS-232 a 115200 bps a pesar de que el microcontrolador que usan tiene una UART mucho más rápida debido a que, como me confesaron, les era imposible mantener mayores velocidades sin introducir continuos errores en la comunicación.
RS485 Hola mundo a 9 Mbps
Además, se analizó el uso de código de detección de errores. Tras varias pruebas, se programó y se verificó el correcto funcionamiento del código de detección de errores. Por ser un código ligero en cuanto a uso de CPU y porque son sólo dos bytes (16 bits) extra en la comunicación, he decidido que LibreServo usará CRC16 (se podrá desactivar si el usuario así lo quiere). CRC8 puede que se quede corto en transmisiones de más de 64 bytes y CRC32 ya sí entraña mucho uso de CPU y es matar moscas a cañonazos en nuestro caso.
Nuevo sensor magnético AEAT-8800
Al principio en las pruebas todo empezó mal con el sensor. Quería leer el sensor AEAT-8800 mediante su salida de encóder estándar (ABI) y así poderlo leer con el DMA del microcontrolador de manera automática sin usar ciclos de CPU. Desgraciadamente el sensor viene configurado de fábrica con la resolución más baja posible en su salida ABI y hay que cambiarlo mediante registros por SPI. Para rizar más el rizo, no tenía en el microcontrolador pines suficientes para todo ello, así que utilicé un multiplexador para poder, con los mismos pines en el microcontrolador, escribir el registro mediante SPI y luego cambiar para leer ya de continuo el encóder. Desgraciadamente el cambio de pines en el multiplexador no iba todo lo fino que requería y el sensor se negaba a escribir el registro. Me iba a dar por vencido hasta que descubrí que por defecto el sensor viene configurado para funcionar a máxima precisión, 16 bits nada más y nada menos 😍, si se lee directamente la posición en SSI (un protocolo muy parecido a SPI). Así que quité el multiplexador, soldé varias pistas, programé a mano el protocolo SSI y... el resultado fue el siguiente:
Lectura AEAT-8800 por SSI
Aún sin optimizar el código, el sensor se leía en 25.18µs que es aproximadamente unos 40KHz. Sólo se requerirá leer el sensor a un máximo de 1KHz, con lo que se deja suficiente margen para el resto de tareas e incluso optimizando un poco mi código no sería difícil bajar de 20µs, con lo que estoy muy contento con el resultado final. Sí que es cierto que no lo podré leer mediante DMA, pero me ahorro el multiplexor, lo leo a 16bits de resolución en vez de a 14 que da en la salida ABI y además obtengo 3 bits de estado en cada lectura que me indican si hay algún error con el sensor.
También diseñé en Fusion360 el adaptador para el sensor para sustituir al potenciómetro de un servomotor. Una vez impreso en 3D quedó perfecto y encaja sin problema alguno en el mismo hueco que utilizaba el potenciómetro, con rodamiento e imán incluído.
Adaptador encóder a potenciómetro
Puente en H
Un fracaso 😭. Sin medias tintas, el puente en H ha funcionado fatal. Por un lado la conexión en el microcontrolador no era la correcta, pero superando ese escollo, algo ocurre entre el driver de mosfets y el mosfet de canal P que de algún modo se activa y desactiva, el mosfet de canal P entra en un bucle diabólico oscilando en megaherzios que termina quemando el driver de mosfet en segundos... La única explicación que he podido encontrar es que al usar mosfets para el puente en H con alta capacitancia en los pines gate, estos funcionan como pequeños condensadores que entran en resonancia entre el driver de mosfets y el propio mosfet y termina por quemar el driver. En principio este problema se soluciona con una resistencia de 6 Ohms entre el driver y el mosfet, pero eso es suponiendo que realmente fuera ese el problema. Ahora mismo, es la única incógnita en el proyecto de LibreServo.
Próxima PCB
Actualmente me encuentro diseñando una nueva placa de test con todos los cambios y todas las decisiones tomadas puestas en práctica. En principio será una placa más definitiva que la anterior de test, sin tantas opciones ni switches y más cercana a la final, pero aún con un marcado diseño de test para poder probar y leer las señales de manera cómoda para poder encontrar posibles errores, sobre todo en la parte del puente en H. Además, será una PCB de 4 capas, ya que LibreServo pasará de un diseño de 2 capas a 4 capas. A día de hoy JLCPCB ofrece placas de 5x5cm por sólo 5 dólares (en el día que escribo esto tiene una oferta especial de ¡sólo 2 dólares!). El cambio a 4 capas deberá desahogar el diseño del PCB en cuanto a espacio, mejorar el rutado, tener planos de alimentación y tierra en exclusiva que proporcionará alimentación más limpia y menos ruido... Realmente no hay muchas excusas para no usar el servicio de 4 capas en placas pequeñas, como es LibreServo, a día de hoy.