Help on several topic

[tibean]

Hi! First of all congratulations for the amazing project and secondly thank you for sharing with us. I'm facing some issues on which I need your support. I have a LILYGO® TTGO T-Display ESP32 1.14" ST7789 Colour LCD, and a 360deg servo (AZ) together with a 90deg servo (EL).

1. My AZ servo limits are 555us (0deg) and 2475us (359deg). What should be my minAzPWM and maxAzPWM to be inserted on this part of the code? I'm a bit confused with "right and left".

if defined STM32F1xx - my STM32 based tracker has different servos

minAzPWM = 600 - right because mine is reversed, yours may differ maxAzPWM = 2200 - left minElPWM = 700 - front maxElPWM = 2300 - back

else

minAzPWM = 625 - right (because mine is reversed) maxAzPWM = 2240 - left minElPWM = 700 - front maxElPWM = 2257; // back

endif

2. Using the serial monitor to debug I get this error just after TestServos:

E (307496) gpio: gpio_set_level(226): GPIO output gpio_num error

This message is looping and filling the monitor outuput, which makes hard to make any debug. Googling the issue points maybe to TFT_eSPI lib, but even after changing it with a different version and messing with some settings I get no sucess. Do you have any clue what can be the origin of the error?

3. The only time I get the servos moving and have have active tracking is when I set "3 Trackerbox_Compass" as heading source. When I set "4 Trackerbox_GPS_And_Compass" the system never moves, although I have a correctly detected GPS with lock. Note: I'm using MissionPlanner simulation to feed MAVLINK messages to the tracker, and normally the planner reports only 10 sats. Is it somehow related?

Thank you again! Tiago

[zs6buj]

Hi Tiago, thank you for your kind words.

I'm going to assume you are using v2.19.09

1) From your post above, I would change the defaults like this. I also assume that your az and el servos have the same limits.

Leave these settings unchanged. This is where the geometric degree limits are set, not the physical limits if the servos:

  // Set the degree range of the servos here. Do not adjust servo mechanical limits here.                         
  #if defined Az_Servo_360   // 1 x 360, 1 x 90 (or 180) servos  
    int16_t minAz = 0;          // Az lower limit in degrees, left of tracker facing flying field
    int16_t maxAz = 359;        // Az upper limit in degrees
    int16_t minEl = 0;          // El lower limit in degrees, horizontal 
    int16_t maxEl = 90;         // El upper limit in degrees, straight up
  #else                      // 2 x 180 deg servos
    int16_t minAz = 0;          // Az lower limit in degrees, left of tracker facing flying field
    int16_t maxAz = 180;        // Az upper limit in degrees, right of tracker facing flying field
    int16_t minEl = 0;          // El lower limit in degrees, horizontal and forward
    int16_t maxEl = 180;        // El upper limit in degrees, horizontal and rearward
  #endif 

Below is where we establish the uS equivalent of a particular angle.

  // ADJUST THE MECHANICAL LIMITS OF MOVEMENT OF YOUR SERVOS HERE BELOW
  #if defined STM32F1xx      // my STM32 based tracker has different servos
    uint16_t minAzPWM = 555;   // right (because mine is reversed)
    uint16_t maxAzPWM = 2475;  // left   
    uint16_t minElPWM = 555;   // front 
    uint16_t maxElPWM = 2475;  // back
  #else
    uint16_t minAzPWM = 625;   // right (because mine is reversed)
    uint16_t maxAzPWM = 2235;  // left 
    uint16_t minElPWM = 600;   // front
    uint16_t maxElPWM = 2257;  // back  
  #endif

The left and right nomenclature originally referred to 180 deg servos. In this configuration, left (usually) means start at 0 deg and move clockwise to 359 deg, but servos might differ. If you want the servo to change the direction of rotation, switch min and max around.

So now let's assume if you feed your az servo with 555uS, it will point to 0 deg (relative to itself), feed 1515uS it will point to 180 deg, and 2475 it will point to 359 (or back to zero).

Next, I would change these settings like this, because we ahve a 360 deg azimuth servo.

  #define Az_Servo_360  // else assumes 180
  #define azStart  0     
  #define elStart   0       

2 Did you select the correct board by uncommenting this line:

//=============================================================================================
//=====================   S E L E C T   E S P   B O A R D   V A R I A N T   ===================
//=============================================================================================
//#define ESP32_Variant     1    //  ESP32 Dev Module - there are several sub-variants that work
//#define ESP32_Variant     4    //  Heltec Wifi Kit 32 
#define ESP32_Variant     5    //  LILYGO® TTGO T-Display ESP32 1.14" ST7789 Colour LCD
//#define ESP32_Variant     6    // LILYGO® TTGO T2 ESP32 OLED Arduino IDE board = "ESP32 Dev Module"
//#define ESP32_Variant     7    // ESP32 Dev Module with ILI9341 2.8" colour TFT SPI 240x320

and did you leave these setting unchanged:

  #if (ESP32_Variant == 5)          // LILYGO® TTGO T-Display ESP32 1.14" ST7789 Colour LCD, IDE board = "ESP32 Dev Module"
    uint8_t in_rxPin =        27;       // uart1 for general serial in, including flight gps
    #define in_txPin          17 
    uint8_t gps_rxPin =       13;       // uart2 for tracker box GPS if applicable
    #define gps_txPin         15
    bool rxInvert = false;              // ONLY FOR FrSky S.Port, NOT F.Port, NOT MAVLINK
    #define SetHomePin        12
    #define StatusLed         25        // Add your own LED with around 1K series resistor
    #define BuiltinLed        99    
    #define azPWM_Pin         32  // azimuth servo (can't be 34,35,36,39 because input only !!)
    #define elPWM_Pin         33  // elevation servo(can't be 34,35,36,39 because input only !!)    
    #define startWiFiPin  99      // 99=none. No input pin available (non touch!) Could use touchpin with a bit of messy work.    

    #if !defined displaySupport    // I2C TFT board is built into TTGO T-Display
      #define displaySupport
    #endif    
    #define ST7789_Display          // TFT display type - if you have a display you must define which type
    #define SCR_ORIENT   1          // 1 Landscape or 0 Portrait    

    /* Below please choose either Touch pin-pair or Digital pin-pair for display scrolling
     *  Pin == 99 means the pin-pair is not used
     */  
    #define Pup            0        //  0 Board Button 1 to scroll the display up
    #define Pdn           35        // 35 Board Button 2 to scroll the display down      
    #define Tup           99        // 33 Touch pin to scroll the display up
    #define Tdn           99        // 32 Touch pin to scroll the display down   

    #define SCR_ORIENT     1        // 1 Landscape or 0 Portrait

    #define SDA           21        // I2C TFT board and/or Compass (grey wire)
    #define SCL           22        // I2C TFT board and/or Compass (brown wire)
    #define display_i2c_addr      0x3C     
    #define compass_i2c_addr      0x1E   // 0x1E for HMC5883L   0x0D for QMC5883
  #endif

3 Could you please post the log output from boot at least for a page or two.

[tibean]

Hi Eric.

Thanks again for your help. Yes, I'm running the latest version 2.19.09.

My servos are different due to the design of my own pan tilt mechanism. The timings were determined with an oscilloscope, and they are: EL: 0 deg: 1280us; 90 deg: 1840us. AZ: 0 deg: 555us; 180 deg: 1520us; 359 deg: 2475us.

1. I've followed your instructions and set:

   define Test_Servos // Move servos through their limits, then try

   box_hdg every 45 degrees of circle

   define Az_Servo_360 // Means the azimuth servo can point in a 360 deg

   circle, elevation servo 90 deg // Default (comment out #define above) is 180 deg azimuth and flip over 180 deg elevation

   define azStart 0 // 0 deg = left, 90 deg = straight ahead, 180

   deg = right, 270 deg = behind

   define elStart 0 // 0 = horizontal, 90 = vertical

   define Servo_Slowdown 10 // Default 0 - Try 5, 10.. ms/degree to limit

   angular velocity

   // Set the degree range of the servos here. Do not adjust servo mechanical limits here. // Default values for SG90 servos; 500 and 2400 // My 180 deg servos have a PWM range of 700 through 2300 microseconds. Your's may differ. // ADJUST THE MECHANICAL LIMITS OF MOVEMENT OF YOUR SERVOS HERE BELOW

   if defined STM32F1xx // my STM32 based tracker has different servos

   uint16_t minAzPWM = 555; // right (because mine is reversed) uint16_t maxAzPWM = 2475; // left uint16_t minElPWM = 1280; // front uint16_t maxElPWM = 1840; // back

   else

   uint16_t minAzPWM = 555; // right (because mine is reversed) uint16_t maxAzPWM = 2475; // left uint16_t minElPWM = 1280; // front uint16_t maxElPWM = 1840; // back

   endif

Inside your TestServos() function I changed the code to:

void TestServos() { delay(1500); moveServos(0, 45); delay(5000); moveServos(0, 90); delay(5000); moveServos(0, 45); delay(5000); moveServos(0, 0); // az, el delay(5000); moveServos(90, 0); delay(5000); moveServos(180, 0); delay(5000); moveServos(270, 0); delay(5000); moveServos(359, 0); delay(5000); moveServos(270, 0); delay(5000); moveServos(180, 0); delay(5000); moveServos(90, 0); delay(5000); moveServos(0, 0); // az, el delay(5000); moveServos(azStart, elStart);

so I can watch the movement in EL in 45deg steps and AZ in 90deg steps.

Results: Strangely, the EL mechanism only moves to around 45 degs, never getting to the 90deg position. Scratching my head... In AZ the situation is also strange: instead of moving 90deg, it rotates 180deg each step, double of what was expected. When addressing more than 270deg it stays stopped, which I suspect is because the PWM time value calculated and sent to the servo is far way from the supported limits of the servo.

What is your feeling?

2. Yes, the board selected is the correct one and I have not changed other definitions. I've also noticed that the message appears at the very beginning. Have a look on the serial output:

Starting AntTrack version:2.19.09 Setting up wire I2C SDA:21 SCL:22 Display support activated: Landscape 135x240 text_size=2 char_w_px=12 char_h_px=16 scr_h_ch=8 scr_w_ch=20 Target Board = 3 ESP32 / Variant is LILYGO® TTGO T-Display ESP32 1.14 inch ST7789 Colour LCD Serial Telemetry In Selected protocol is Mavlink 2 E (2612) gpio: GPIO can only be used as input mode E (2612) gpio: gpio_set_level(226): GPIO output gpio_num error headingSource = 3 Tracker Box Compass Compass type HMC5883L expected Servo slowdown factor is 10ms per degree of rotation moveServos() az=0 el=0 Servo write az=0 el=0 Testing Servos moveServos() az=0 el=45 Servo write az=0 el=45 moveServos() az=0 el=90 Servo write az=0 el=90 moveServos() az=0 el=45 Servo write az=0 el=45 moveServos() az=0 el=0 Servo write az=0 el=0 moveServos() az=90 el=0 Servo write az=90 el=0

3. Sure, I can do it, but I suppose I should turn on some of the debug options, right? Each one?

Regards, Tiago

[zs6buj]

"E (2612) gpio: GPIO can only be used as input mode E (2612) gpio: gpio_set_level(226): GPIO output gpio_num error"

    #define azPWM_Pin         32  // azimuth servo (can't be 34,35,36,39 because input only !!)
    #define elPWM_Pin         33  // elevation servo(can't be 34,35,36,39 because input only !!)   

This is telling us we can't use one of those pins for pwm I think. I'm pretty sure I use these pins on my own test tracker, but we can't ignore this. Perhaps I can dig my tracker out of storage.

Regretfully I have a busy day ahead, but I'll try to get back to you tomorrow.

[zs6buj]

Ok, I tested v2.19.9 with my test mule, and it works fine here.

https://user-images.githubusercontent.com/12892533/229452467-ea7ef864-46c6-4a3a-b0ab-86445a7d1fd7.mp4

It's set up for the T-Display board, and Trackerbox_GPS_And_Compass, and I also created a binary for you. Latest v2.19.9 c on my github. In addition, libraries have been updated with newest eTFT_eSPI library, setup for the T_Display.

Hope this helps.

EDIT: Of course this is not setup for your servos, but let's see if your previous error

E (2612) gpio: GPIO can only be used as input mode
E (2612) gpio: gpio_set_level(226): GPIO output gpio_num error

goes away

[tibean]

Same result. In reality what you have displayed in your TFT display is the same as I have in mine. The issue is reported only in the serial monitor. Did you check it? Nevertlhess I think maybe we can ignore it for while, because we have servos moving and data being displayed. My major concern are the limits in servos not working properly as I wrote at March 31.

[zs6buj]

I'm wondering if your servos don't require a different pwm frequency. What does the documentation say? Also what voltage is specified?

[zs6buj]

No errors in my serial log.

[tibean]

I'm wondering if your servos don't require a different pwm frequency. What does the documentation say? Also what voltage is specified?

Not really. They are HK15138, regular 180deg servos. The only difference is that I designed a 360º mechanism based in a 1:2 gear, which gives me 360º in AZ but only 90º in EL (hardware limitation). The result is a a system with the following limits in AZIM: 0deg: 555 us 180deg: 1520 us 360deg: 2475 us

and in ELEVATION: 0deg: 1280 us 90deg: 1840 us

[tibean]

With a simple sketch like this, addressing directly the servo with the timming, I get a correct movement of both servos.

include

byte servoPin = 32; //32 is AZ, 33 is EL Servo servo;

void setup() {

servo.attach(servoPin, 500, 2500);

}

void loop() {

servo.writeMicroseconds(555); //0 deg printf("0deg\n"); delay(5000); servo.writeMicroseconds(1038); //90deg printf("90deg\n"); delay(5000); servo.writeMicroseconds(1520); //180 deg printf("180deg\n"); delay(5000); servo.writeMicroseconds(1998); //270 deg printf("270deg\n"); delay(5000); servo.writeMicroseconds(2475); //360 deg printf("360deg\n"); delay(5000); servo.writeMicroseconds(1998); //270 deg printf("270deg\n"); delay(5000); servo.writeMicroseconds(1520); //180 deg printf("180deg\n"); delay(5000); servo.writeMicroseconds(1038); //90deg printf("90deg\n"); delay(5000); }

[zs6buj]

Ok, that is very compelling evidence that the problem lies with the 360 degree macro. I'll check it out tomorrow.

[zs6buj]

Wait, maybe not. I'm thinking we might be using different servo libraries.

[zs6buj]

Could you please try

#define Debug_Servos

and run TestServos() again

[tibean]

Hi Eric. Sorry for my late reply, but I have been pretty busy and also taking the last few days to perform some tests. I don't think we are using different libraries. I believe there's some issue with math on 360 macro. Let me explain what I've done. First, I've 3D printed a mechanism like yours, capable of 180º in EL and 180º in AZ (in reality it is capable of 360º in AZ), and measured the timing of the limits.

For the sake of clarity, they are: EL: 0º: 710us 90º: 1325us 180º: 1940us

AZ: 0: 555us 180: 1520us 360: 2475us

Test 1: Running a 180+180 system

Commented out the 360 line and inserted my new limits EL [ 710us, 1940us] AZ[ 0: 555us, 180: 1520us] and ran the Test_Servos.

define Test_Servos // Move servos through their limits, then try

box_hdg every 45 degrees of circle

//#define Az_Servo_360 // Means the azimuth servo can point in a 360 deg circle, elevation servo 90 deg // Default (comment out #define above) is 180 deg azimuth and flip over 180 deg elevation

define azStart 0 // 0 deg = left, 90 deg = straight ahead, 180

deg = right, 270 deg = behind

define elStart 0 // 0 = horizontal, 90 = vertical

void TestServos() { delay(5000); moveServos(0, 0); delay(5000); moveServos(90, 0); delay(5000); moveServos(90, 90); delay(5000); moveServos(90, 180); delay(5000); moveServos(90, 0); delay(5000); moveServos(180, 0);

Result: Sure enough, everything works correctly (only tested the Test_Servos), all angles are correct, so no issues with math. :)

Test 2a: Running a 360+180 system: Uncommenting the line define Az_Servo_360 and inserting:

uint16_t minAzPWM = 555;   // right
uint16_t maxAzPWM = *1520;  // left ----> this corresponds to only 180º

in AZ* uint16_t minElPWM = 710; // front uint16_t maxElPWM = 1940; // back

and running: void TestServos() { // az, el delay(5000); moveServos(0, 0); ---> OK delay(5000); moveServos(90, 0); ---> OK delay(5000); moveServos(90, 90); ---> OK delay(5000); moveServos(90, 180); ---> OK delay(5000); moveServos(90, 0); ---> OK delay(5000); moveServos(180, 0); ---> OK delay(5000); moveServos(270, 0); ---> no movement delay(5000); moveServos(359, 0); ---> no movement delay(5000); moveServos(180, 0); ---> OK

Test 2b: Running a 360+180 system: uint16_t minAzPWM = 555; // right (because mine is reversed) uint16_t maxAzPWM = 2475; // left ----> this corresponds to 360º in AZ uint16_t minElPWM = 710; // front uint16_t maxElPWM = 1940; // back

and running the same TestServos:

void TestServos() { // az, el delay(5000); moveServos(0, 0); ---> OK delay(5000); moveServos(90, 0); ---> AZ Servo moves to 180º delay(5000); moveServos(90, 90); ---> AZ Servo at 180º, EL moves to 90º delay(5000); moveServos(90, 180); ---> AZ Servo at 180º, EL moves to 180º delay(5000); moveServos(90, 0); ---> AZ Servo at 180º, EL moves to 0º delay(5000); moveServos(180, 0); ---> AZ Servo moves to 360º delay(5000); moveServos(270, 0); ---> no movement delay(5000); moveServos(359, 0); ---> no movement delay(5000); moveServos(180, 0); ---> AZ Servo stays at 360º delay(10000);

So, basically it seems to me that in the 360 macro there is a factor of 2, which leads to these values. Although I've not fully tested, it seems to me that there's also some issue with EL servo, but this time with a factor of 0.5 when I define it as a 90º servo ( uint16_t maxElPWM:1325us).

Message ID: @.***>

[tibean]

Hi Eric.

Based on the success I had using 180º servos, I'm redesigning my tracker to use such servos. So, maybe it is not worth spending time on the issue about the 360º topic. Nevertheless I have two further questions:

1. From what I understood, GPS in the tracker is not mandatory, as the home position is received from Mavlink telemetry in the moment plane/drone is armed. Am I correct?
2. For the Heading I will use a external compass. From the Wiki: "Glue a suitable magnetometer anywhere on the tracker box, facing the direction of the antenna at rest." So the compass does not need to move with AZ nor EL? I also noticed in the movie you shared in the above post that indeed your GPS (and included Compass I believe) is static in the base box. If you accidentally rotate the tracker during it's operation, will the system correct the error by itself?

[zs6buj]

1 "From what I understood, GPS in the tracker is not mandatory, as the home position is received from Mavlink telemetry in the moment plane/drone is armed. Am I correct?"

Correct. The box GPS is not essential, but convenient. In addition, it allows for the tracker to move while tracking.

2 The box compass is attached to the box, and provides the orientation (relative to the outside world, of the box. Yes, if you accidentally rotate the box, the tracker will compensate. So as per above, the tracker can move while tracking. Contributor Bohan recently added a feature for box compass offset correction called COMPASS_ALIGN. This is to correct the orientation of the way the box compass is fixed to the box. For example, box mag north might be fixed 180 degrees off of true north.

Available options: ALIGN_DEFAULT, CW0_DEG, CW90_DEG, CW180_DEG, CW270_DEG, CW0_DEG_FLIP, CW90_DEG_FLIP, CW180_DEG_FLIP, CW270_DEG_FLIP

[tibean]

Thats great Eric.

I managed to get the system running and I'm performing some tests.

Meanwhile I found the issue that was causing these messages: E (2612) gpio: GPIO can only be used as input mode E (2612) gpio: gpio_set_level(226): GPIO output gpio_num error

in config.h:

if (ESP32_Variant == 5) // LILYGO® TTGO T-Display ESP32 1.14" ST7789 Colour LCD, IDE board = "ESP32 Dev Module"

uint8_t in_rxPin =        27;       // uart1 for general serial in, including flight gps
#define in_txPin          17 
uint8_t gps_rxPin =       13;       // uart2 for tracker box GPS if applicable
#define gps_txPin         15
bool rxInvert = false;              // ONLY FOR FrSky S.Port, NOT F.Port, NOT MAVLINK
#define SetHomePin        12
#define StatusLed         25        // Add your own LED with around 1K series resistor
#define BuiltinLed        25        //Original:99    
#define azPWM_Pin         32  // azimuth servo (can't be 34,35,36,39 because input only !!)
#define elPWM_Pin         33  // elevation servo(can't be 34,35,36,39 because input only !!)    
#define startWiFiPin  99      // 99=none. No input pin available (non touch!) Could use touchpin with a bit of messy work.  

you have "#define BuiltinLed 99" by default. I changed it to 25 (I do not use the StatusLed) and no more messages are shown. I believe one of the libraries does not like the 99 pin. I'm also guessing that if using the Wifi section this pin "startWiFiPin 99" will cause issues. But let's see later on.

[zs6buj]

Thanks for the feedback Tiago. Yes I found it and fixed it in v2.19.10 last week. It turned out to not be relevant to the issue you reported.

[tibean]

Hi Eric.

Sorry for the long delay, but I've had some problems finding a HMC5883L board (I do not want to use a GPS) until now. I'm finally testing your system, and have a bunch of new questions. Running lastest version (let you know the GPIO message issue is still present) with two 180º servos. Feeding mavlink telemetry via serial port and MP Simulator.

-Where should I point the compass to during installation? To the equivalent of AZ = 0º of the mechanism? Or 90º? Or 180º? Because I'm facing some problems having the mechanism pointing to the right direction while tracking.

-With #define Debug_Servos enabled for debugging, I'm getting some strange overloaded values for ELevation which seems that hangs out the CPU. Is this normal?

worldAz = 0 ourEl = -1 boxHdg = 290 ourAz = 70 ourEl = -1 boxHdg = 290 moveServos() az=70 el=65535 az reversed Servo write az=110 el=65535

-Which DEBUG defines should I turn ON in order to check the correct behaviour of the system without overloading the CPU?

Thanks.

[zs6buj]

-Where should I point the compass to during installation? To the equivalent of AZ = 0º of the mechanism? Or 90º? Or 180º? Because I'm facing some problems having the mechanism pointing to the right direction while tracking.

Hi Tiago, around line 91 in config.h

// Bohan's PR
// Select compass orientation. Many of the available GPS/Compass boards have their compass oriented in non-standard way,
// the correct re-orientation information should be provided by the manufacturer.
// Available options: ALIGN_DEFAULT, CW0_DEG, CW90_DEG, CW180_DEG, CW270_DEG, CW0_DEG_FLIP, CW90_DEG_FLIP, CW180_DEG_FLIP, CW270_DEG_FLIP
#define BOX_COMPASS_ALIGN       ALIGN_DEFAULT
//#define BOX_COMPASS_ALIGN       CW90_DEG
//#define BOX_COMPASS_ALIGN       CW90_DEG_FLIP

worldAz = 0 ourEl = -1 boxHdg = 290 ourAz = 70 ourEl = -1 boxHdg = 290 moveServos() az=70 el=65535 az reversed Servo write az=110 el=65535

Elevation should not be -1. That is where the 655nn comes from. You need to find out why.

Check where pointServos() is called. You can use the Edit/Find pull-down in the Aurduino editor. I found a call in TestServos(). Start there. And also around line 1009 in main (AntTrack tab)

Try these two debug macros

define Debug_AzEl

define Debug_Servos

[zs6buj]

Stale I think