Interfaz rotor Arduino de K3NG

Gracias por los consejos. Yo también me he puesto en ello. A ver que sacamos 😉

Tengo el mando de RemoteQTH y un G800SDX

Hola yo estoy atento, pero mi problema es la programación......

Realmente no necesitas programar nada. Sólo se trata de quitar y poner barras de comentario //

Normalmente, para un programador, lo más difícil es modificar el código que ha escrito otro y un ejercicio de paciencia es modificar algo que lo ha escrito un grupo con aportaciones varias implementadas con calzador.

Personalmente sigo utilizando el mando que hice hace un par de años cuyo código he perdido, pero si, por alguna razón, se desprograma el Arduino que estoy utilizando no me planteo el trabajo de "podar" de nuevo el programa de K3NG sino que estoy decidido a hacer un programa nuevo específico para el Yaesu 650 o 1000, si es que cambio de rotor. 

Hola a todos:

Revisando por internet soluciones a mi problema, me he topado con este hilo. Os trato de resumir lo que trato de realizar:

Estoy construyendo un rotor para satélites basado en un Arduino UNO con una placa CNC Shield pinchada, un par de controladores DRV8825 configurados para micropasos, un par de motores por pasos Nema 17 con poleas y correas, y un sensor LSM303 conectado a las salidas I2C de la placa CNC Shield. No utilizo finales de carrera.

He probado el código para Arduino de SatNOGS pero modificándolo para incluir la lectura del sensor LSM303. El sistema funciona razonablemente bien.

Ahora trato de hacer funcionar el código de K3NG. Me detecta el sensor y puedo leer los valores, aunque la elevación estaba invertida la he corregido con las tablas de calibración y la lectura es más o menos correcta. En cuanto al azimut, he observado que existe un error en la lectura de alrededor de 50º con respecto a la orientación real (lo compruebo con una aplicación para el móvil) y no sé cómo corregirlo.

Por otro lado, al utilizar motores por pasos, estoy tratando de definir los pines en el fichero rotator_pins.h pero, salvo la habilitación de los motores, no consigo que se muevan. Es más, salvo los pines de paso y dirección, que más o menos veo claro dónde se especifican, no sé si es necesario especificar otros ya que el resto de valores entiendo que son para motores DC o de otro tipo.

He preguntado en el foro de Radioartisan también pero no es de mucha ayuda la información que me están dando (o no consigo explicarme bien o me están dando respuestas vagas).

¿Alguien que haya trabajado con este código me podría ayudar u orientar?

Muchas gracias. Saludos.

Hola Vic,

Tengo alguna experiencia en el manejo del código de K3NG en motores Split y de CC, también con sensores basados en potenciómetro. Veo que utilizas un acelerómetro LSM303. No tengo experiencia con ese tipo de dispositivo pero creo que puedes encontrar la forma de averiguar el funcionamiento en el sketch.

Vamos por partes.

Supongo que ya has activado la característica si tienes el módulo de Pololu

#define FEATURE_AZ_POSITION_POLOLU_LSM303

O el de Adafruit 

#define FEATURE_AZ_POSITION_ADAFRUIT_LSM303 

Esto es muy importante porque afecta a las librerías que se cargan

Ahora hay que seguir como funciona:

Estos son los parámetros que definen las lecturas máximas y mínimas del magnetómetro del módulo de Pololu

#if defined(FEATURE_AZ_POSITION_POLOLU_LSM303) || defined(FEATURE_EL_POSITION_POLOLU_LSM303)
LSM303 compass;
LSM303::vector<int16_t> running_min = {32767, 32767, 32767}, running_max = {-32768, -32768, -32768};
char report[80];
#endif //FEATURE_AZ_POSITION_POLOLU_LSM303

Aquí tienes la función de lectura acimutal del sensor

#ifdef FEATURE_AZ_POSITION_ADAFRUIT_LSM303
lsm.read();
float heading = atan2(lsm.magData.y, lsm.magData.x);
// heading += declinationAngle;
// Correct for when signs are reversed.
if (heading < 0) heading += 2 * PI;
if (heading > 2 * PI) heading -= 2 * PI;
raw_azimuth = (heading * RAD_TO_DEG); // radians to degree
#ifdef FEATURE_AZIMUTH_CORRECTION
raw_azimuth = (correct_azimuth(raw_azimuth));
#endif // FEATURE_AZIMUTH_CORRECTION
apply_azimuth_offset();
if (AZIMUTH_SMOOTHING_FACTOR > 0) {
if (raw_azimuth < 0){raw_azimuth = 0;}
raw_azimuth = int(raw_azimuth * ((float)1 - ((float)AZIMUTH_SMOOTHING_FACTOR / (float)100))) + ((float)previous_raw_azimuth * ((float)AZIMUTH_SMOOTHING_FACTOR / (float)100));
}
azimuth = raw_azimuth;
#endif // FEATURE_AZ_POSITION_ADAFRUIT_LSM303

lsm.read() es un objeto de la clase lsm. que efectúa la lectura

Deberías revisar si tienes activada la corrección FEATURE_AZIMUTH_CORECTION y AZIMUTH_SMOOTHING_FACTOR

Además, puedes monitorizar el comportamiento del sensor (de lo que lee el Arduino en el sensor) utilizando el depurador. En este caso deberías descomentar 

// #define DEBUG_POLOLU_LSM303_CALIBRATION

en el archivo rotator_debug_log_activation

Para utilizar el depurador necesitas más memoria que la que te ofrece el UNOI. Yo utilizo una placa MEGA PRO china que funcionan de vicio y cuestan unos 5€, los circuitos los monto con placas perforadas estándar, estoy construyendo un máquina CNC para circuitos impresos y hacer juguetes a mi ultimo nieto, pero estancado porque la Dremel se niega a cortar unas barras de acero de 10mm y si utilizo una Rotaflex mi sufrida me destierra.

Bueno... he estado leyendo el funcionamiento de un magnetrómetro de tripe eje, parece evidente que la comunicación del sensor con el microprocesador lo hace a través del puerto I2C (SCL y SDA) y no utiliza puertas I/O a pesar de que algunas placas llevan una salida con tensión proporcional al ángulo XY. Ya indicarás que tipo de placa utilizas porque hay varios fabricantes y varios modelos de chip.

En cualquier caso, el código de K3NG no lleva ninguna entrada específica para estos dispositivos por lo tanto cabe deducir que, son las instancias de cada librería las que de ocupan de leer y decodificar los datos que llegan de los tres ejes a través del puerto.

Por ejemplo, otro dispositivo como un RTC con el cual he tenido la oportunidad de jugar se comunica por el mismo puerto y Arduino no necesita más que asignar las puertas A4 y A5 (en UNO y NANO 20 y 21 para MEGA) para SCL y SDA del puerto I2C.

He mirado por encima la librería de Adafruit para el LSM303 y, efectivamente, tiene una función de lectura de los ajes a través del puerto:

Una instancia que lee desde la librería a través del puerto,

Lee una cadena de 6 posiciones (0 a 5) (mientras que el puerto está abierto y la posición es menos que 6. Asigna el resultado de cada posición a seis valriables, xlo, xhi, ylo, yhi, zlo y zhi, es decir dos posiciones, alta y baja, para cada uno de los tres ejes. A partir de ahí es cuando la librería hace los cálculos para determinar el rumbo.

Como te he indicado, tienes que conocer la posiciones que entrega el sensor en cada momento con el depurador y contrastar con un instrumento externo. Me sorprende que en el correo de usuarios de de Radioartisan no te hayan facilitado información para ajustar los rotores. En cualquier caso, valoraría si la precisión que necesitas para orientar la antena es tan crítica que no te permita utilizar potenciómetros sincronizados. Es lo más sencillo de programas y utilizar.

Hola EA2J:

Gracias por tus respuestas y tu ayuda. Voy a intentar ir por partes a falta de probar las indicaciones que escribes:

- En cuanto al azimut, utilizo FEATURE_AZ_POSITION_POLOLU_LSM303, ya que FEATURE_AZ_POSITION_ADAFRUIT_LSM303 me da valores del sensor que no me cuadran demasiado. Según he visto en la documentación, para utilizar Pololu, es preciso definir las tablas de calibración.

- Utilizo FEATURE_AZIMUTH_CORRECTION. Por tanto, tengo que definir los valores

AZIMUTH_CALIBRATION_FROM_ARRAY {0,359}
AZIMUTH_CALIBRATION_TO_ARRAY {0,359}

Los he puesto así pero, por lo que me indicas, posiblemente tenga que corregir algo aquí.

En cuanto a los valores de correción para la elevación, ya que el sensor los devuelve invertidos:

ELEVATION_CALIBRATION_FROM_ARRAY {-180,0,180}
ELEVATION_CALIBRATION_TO_ARRAY {180,0,-180}

- Para el uso de Pololu, como he comentado antes, uso las tablas de calibración obteniendo los valores máximos y mínimos del ejemplo que viene con la librería. En mi caso tengo lo siguiente:

POLOLU_LSM_303_MIN_ARRAY {-213, -494, -1042}
POLOLU_LSM_303_MAX_ARRAY {+957, +376, -300}

- La placa CNC Shield lleva los pines adecuados I2C y funcionan adecuadamente.

- En cuanto a los pines para los motores por pasos, tengo definido lo siguiente, ya que no tengo claro qué más valores tengo que poner:

/* azimuth pins --------------------- (use just the azimuth pins for an azimuth-only rotator) */

#define rotate_cw 0 // goes high to activate rotator R (CW) rotation - pin 1 on Yaesu connector
#define rotate_ccw 0 // goes high to activate rotator L (CCW) rotation - pin 2 on Yaesu connector
#define rotate_cw_ccw 8 // goes high for both CW and CCW rotation
#define rotate_cw_pwm 0 // optional - PWM CW output - set to 0 to disable (must be PWM capable pin)
#define rotate_ccw_pwm 0 // optional - PWM CCW output - set to 0 to disable (must be PWM capable pin)
#define rotate_cw_ccw_pwm 0 // optional - PWM on CW and CCW output - set to 0 to disable (must be PWM capable pin)
#define rotate_cw_freq 0 // optional - CW variable frequency output
#define rotate_ccw_freq 0 // optional - CCW variable frequency output
#define button_cw 0 // normally open button to ground for manual CW rotation (schematic pin: A2)
#define button_ccw 0 // normally open button to ground for manual CCW rotation (schematic pin: A3)
#define serial_led 0 // LED blinks when command is received on serial port (set to 0 to disable)
#define rotator_analog_az A0 // reads analog azimuth voltage from rotator - pin 4 on Yaesu connector
#define azimuth_speed_voltage 0 // optional - PWM output for speed control voltage feed into rotator (on continually unlike rotate_cw_pwm and rotate_ccw_pwm)
#define overlap_led 0 // line goes active when azimuth rotator is in overlap (> 360 rotators)
#define brake_az 0 // goes high to disengage azimuth brake (set to 0 to disable)
#define az_speed_pot 0 // connect to wiper of 1K to 10K potentiometer for speed control (set to 0 to disable)
#define az_preset_pot 0 // connect to wiper of 1K to 10K potentiometer for preset control (set to 0 to disable)
#define preset_start_button 0 // connect to momentary switch (ground on button press) for preset start (set to 0 to disable or for preset automatic start)
#define button_stop 0 // connect to momentary switch (ground on button press) for preset stop (set to 0 to disable or for preset automatic start)
#define rotation_indication_pin 0
#define blink_led 0
#define az_stepper_motor_pulse 2 //0
#define az_stepper_motor_direction 5
#define az_rotation_stall_detected 9




/*----------- elevation pins --------------*/
#ifdef FEATURE_ELEVATION_CONTROL
#define rotate_up 0 // goes high to activate rotator elevation up
#define rotate_down 0 // goes high to activate rotator elevation down
#define rotate_up_or_down 8 // goes high when elevation up or down is activated
#define rotate_up_pwm 0 // optional - PWM UP output - set to 0 to disable (must be PWM capable pin)
#define rotate_down_pwm 0 // optional - PWM DOWN output - set to 0 to disable (must be PWM capable pin)
#define rotate_up_down_pwm 0 // optional - PWM on both UP and DOWN (must be PWM capable pin)
#define rotate_up_freq 0 // optional - UP variable frequency output
#define rotate_down_freq 0 // optional - UP variable frequency output
#define rotator_analog_el A1 // reads analog elevation voltage from rotator
#define button_up 0 // normally open button to ground for manual up elevation
#define button_down 0 // normally open button to ground for manual down rotation
#define brake_el 0 // goes high to disengage elevation brake (set to 0 to disable)
#define elevation_speed_voltage 0 // optional - PWM output for speed control voltage feed into rotator (on continually unlike rotate_up_pwm and rotate_down_pwm)
#define el_stepper_motor_pulse 3
#define el_stepper_motor_direction 6 // Originalmente no está este valor
#define el_rotation_stall_detected 10
#endif //FEATURE_ELEVATION_CONTROL

- No tengo muy claro para qué sirve el parámetro AZIMUTH_SMOOTHING_FACTOR. Si no lo he entendido mal, es como un factor de correción ya que los valores que devuelve el sensor cuando está parado no son fijos, van oscilando ligeramente. Creo que con este parámetro se trata de buscar un valor medio como referencia. ¿Estoy en lo cierto?

Muchas gracias. Un saludo.

AZIMUTH_SMOOTHING_FACTOR es un factor de corrección de la lectura de la tensión variable de un potenciómetro en puertas analógicas. KNG utiliza varias funciones de lecturas y escrituras que las etiqueta como "enhanced", tienen por objeto detectar si están activados en la lecturas analógicas el ADC de 10 o de 12 bit (Para utilizar con microprocesador con ADC de una u otra resolución) y si la tensión de referencia para decodificación es de 5V 3.3V u otros parámetros asociados a diferentes componentes. En esa función,

int analogReadEnhanced(uint8_t pin){}

Se realiza lectura de una puerta de entrada analógica, yo la he modificado añadiendo una instancia "for· para que lea 100 veces la puerta y devuelva el promedio.

En el mismo proceso de lectura acimut se detecta si el valor definido de AZIMUTH_SMOOTING_FACTOR es mayor que 0, si es así, comprueba el valor que devuelve la función anterior, y si es menor que 0, fuerza la variable a 0 y aplica el factor de corrección definido.

Ahora bien, el valor del factor SMOOTHING solo se aplica cuando el sensor de dirección es un potenciómetro, por lo tanto no afecta a tu proyecto y en este caso la definición debe ser 0.

En cuanto a los pines de los motores paso a paso, no conozco el principio de funcionamiento por lo tanto no te puedo ayudar y en este momento ando demasiado liado como para ponerme a estudiar estos rotores, estoy seguro que algún compañero conoce el funcionamiento de este tipo de motores.

En cualquier caso, si conozco los pines específicos que afectan a la activación digital de relés para el funcionamiento de motores split o de CC. Como norma general, los pines afectan al giro CW (derecha) o CCW(izquierda), freno, parking, botón de inicio de paro, botones de giro manual, son digitales y actúan sobre relés (abierto o cerrado), los PWM, aceleración o variación de corriente son los que afectan a los variadores. En tu caso, supongo que los que tienes que verificar son los "steeper_motor_pulse".

Muchísimas gracias de nuevo por tus comentarios. Seguiré con el prueba y error con respecto a los motores por pasos.

Un saludo.

Hola

Una cosa, ¿ has realizado la calibración de LSM303 ?

Te leí  en el grupo de Radiartisan, pero estoy como tú......hay veces que funciona y otras no, y no lo entiendo, con potenciometros sin problemas.

Con el LSM303 lo que he visto es que con unas librerias funciona y con otras no, te recomiendo busque las del que tu tengas, pues hay  infinidad de modelos y  pruebes, primero con los parametros que vienen  por defecto y luego con los que te de al calibrarlo

No se si te he aclarado algo o te he liado mas... a la tarde cuando este en casa te puedo dar mas información sobre la calibración de todas formas si buscas en los Email recibidos del grupo por LSM303 hay info de un VK, que alomejor te aclara algo,

Saludos cordiales

Anibal - EA1V

Publicado por: @ea1v

Hola

Una cosa, ¿ has realizado la calibración de LSM303 ?

Te leí  en el grupo de Radiartisan, pero estoy como tú......hay veces que funciona y otras no, y no lo entiendo, con potenciometros sin problemas.

Con el LSM303 lo que he visto es que con unas librerias funciona y con otras no, te recomiendo busque las del que tu tengas, pues hay  infinidad de modelos y  pruebes, primero con los parametros que vienen  por defecto y luego con los que te de al calibrarlo

No se si te he aclarado algo o te he liado mas... a la tarde cuando este en casa te puedo dar mas información sobre la calibración de todas formas si buscas en los Email recibidos del grupo por LSM303 hay info de un VK, que alomejor te aclara algo,

Saludos cordiales

Anibal - EA1V

Gracias. Sí, he leído todo lo referente a la calibración y, ciertamente, los valores que devuelve son bastante coherentes. Seguiré investigando.

Muchas gracias.

Como apunta Anibal, es probable que tanto el dispositivo sensor como la elección de librerías sean la clave.

De nuevo por aqui.... Estoy intentando hacer un controlador para el rotor con un Nano y un buffer de salida ULN2003A.

Me acabo de dar cuenta que la lógica de las salidas necesito invertirla. ¿Alguien podría decirme donde (en qué archivo) Puede estar el HIGH o LOW de las salidas ?

Gracias

Bueno, parece que ese no es el problema..... Lo que me está ocurriendo es que la salida que configuro para giro en azimuth CW siempre se queda a nivel alto al enchufar el usb, por lo tanto el rotor se pone a girar, hasta que me doy cuenta y le doy a STOP.

He probado a cambiar a otro pin (al pin 4) y en el momento que le cargo el software, pasa de nivel bajo a nivel alto (5v).

He probado con otro Arduino Nano y lo mismo, en cuanto le subo el soft, zas a 5 voltios

¿A alguien le ha ocurrido algo parecido?

Gracias

Probablemente es debido a los estados de las entradas y salidas digitales. Si manejas un pulsador para mover el rotor lo que haces pasar el estado de la puerta digital de HIGH a LOW (1 a 0) que es lo mismo de 5V a 0V (bueno no exactamente 0 o 5 sino de los umbrales de estado que no recuerdo ahora.

Las puertas lógicas necesitan que al arrancar les digas la función, entrada o salida y el estado inicial y, además, es conveniente que tengan una resistencia. De hecho las puertas lógicas tienen resistencia que se necesitan activar, las resistencias pueden ser PULLUP o PULLDOWN, depende de si quieres iniciar con la puerta LOW y pasar a HIGH cuando pulses un botón.

Lo más ortodoxo es colocar unas resistencia externas de 10K asociadas a las puertas para dejar de inicio la puerta LOW y que pase a HIGH con un evento (pulsado de botón o respuesta lógica de activación.

De memoria creo que K3NG pone los pulsadores con las PULLUP internas activadas, te lo digo de memoria y lo deberías comprobar.

Un ejemplo de inicio de puertas.

void init_relays_pins () {
for (uint8_t relayNum = 0; relayNum <= MaxRelay; relayNum++) {
uint8_t relayPin = RelayPins [relayNum];
pinMode (relayPin, OUTPUT);
digitalWrite (relayPin, LOW);
}
}

Esta función inicializa pinMode(número de pin, OUTPUT o INPUT) en los pines de un array externo (RelayPins) una serie de salidas y pone todas las salidas a LOW.

Tendría que revisar cómo trata el código de K3NG a las salidas, pero siempre puedes invertir la posición de una salida. 

Edito: Si se activas loas resistencias PULLUP, el estado del pulsador es HIGH, por lo tanto la salida, si no está modificada sería HIGH como te la encuentras.

Gracias Enio por tu respuesta.

Anoche estuve estudiando el código y pese a añadirle algunas lineas para poner a cero esa salida en la función initialize_pins(), siguió haciendo cosas raras.

Esta mañana me he bajado la última versión del código ( https://github.com/k3ng/k3ng_rotator_controller ) y ahora parece que funciona. El problema ahora es que el código ocupa mucho más, después de eliminar todas las funcionalidades que no voy a necesitar, me ocupa un 95% de la memoria del NANO (antes ocupaba un 60%).

Voy a preparar un UNO y en Navidades pruebo ambos.

Gracias

Bueno, hace tiempo que no utilizo ni el NANO ni el UNO, utilizo el MEGA 2560 PRO, que es un clon de la Arduino MEGA más pequeño que un UNO. Tiene más memoria y el precio, aunque ha subido, se puede encontrar por menos de 15€. El USB/UART es un CH340 que dispone de drivers P&P en Windows sin problemas.

Yo estoy trabajando en pulir los métodos (funciones) que manejan el protocolo de comunicación Yaesu y tengo pendiente de revisar el funcionamiento del encoder pata la función preset que no va bien. El manejo de encoders requiere puertas I/O que manejen interrupciones y esto no está documentado en el código. Mover el rotor y orientar con un sensor basado en un potenciómetro es sencillo, así como el sistema de comunicación visual, sea con display 1602, 2004 o TFT. El código se complica con la comunicación vía Serial/USB para el control remoto y el manejo de preselección de dirección por encoder. Quizá se pueda simplificar el código utilizando un preselector con un potenciómetro de precisión multivuelta.

Ten en cuenta que el UNO y el NANO utilizan el mismo mCU y que la memoria es la misma, la única diferencia es que el UNO tiene la entrada de alimentación con un conector de barrilete y que el NANO tiene un par de puertas más que el UNO conectadas al ADC, por lo tanto, dos entradas más analógicas. 

Me siguen pasando cosas raras.... Estoy probando el mismo código con un UNO:

Desde pstrotator, algunas veces, al girar en azimut, envía también señal por el pin de Elevación Abajo. Es aleatorio, no lo hace siempre. He probado en modo EasyCom y es como mejor va, ya que parece que lo hace menos. 

Desde puerto serie, con los comandos (mediante putty), va perfecto.

Por lo tanto, parece un fallo de pstrotator....