Help on several topic
Closed this issue · 20 comments
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).
- 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
- 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?
- 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
Hi Tiago, thank you for your kind words.
I'm going to assume you are using v2.19.09
- 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.
"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.
Ok, I tested v2.19.9 with my test mule, and it works fine here.
20230403_095411.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
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.
I'm wondering if your servos don't require a different pwm frequency. What does the documentation say? Also what voltage is specified?
No errors in my serial log.
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
With a simple sketch like this, addressing directly the servo with the timming, I get a correct movement of both servos.
#include <ESP32_Servo.h>
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);
}
Ok, that is very compelling evidence that the problem lies with the 360 degree macro. I'll check it out tomorrow.
Wait, maybe not. I'm thinking we might be using different servo libraries.
Could you please try
#define Debug_Servos
and run TestServos() again
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:
- 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?
- 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?
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
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.
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.
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.
-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
Stale I think