ill get right on that but before i do, would adding a switch be an issue? i never really thought about it much but for the longest time, my quad had a switch just because i thought it was convenient. i haven't thought about it when i add it at the beginning. could that be part of the issue?
Trouble with brush less motors and Power.
- Thread starter vortix
- Start date
ill get right on that but before i do, would adding a switch be an issue? i never really thought about it much but for the longest time, my quad had a switch just because i thought it was convenient. i haven't thought about it when i add it at the beginning. could that be part of the issue?
i removed it, minimal change.
ill note that current battery is 7.4 2S lipo with 250 mAh 20C . switching to a 450 mAh 80C reduced the motors speed quite noticeably but they still turn off at the same microseconds write. this must mean something but i don't what. anyway, ill document everything. photos of the setup and code and all. ill post it all soon. thank you.
There also to discuss here but generally, everything is global. i know that's a bad idea structurally and i plan to change that at some point. the part where pretty much everything happens is the adjust() method. it does the reading of the gyro, the pid and the motors write. so after we read a message and figure out what we do with it, the message goes to adjust. Few things to note: 1. i limited the cycle of the calling to adjust by a timer of 4 milis. so we only adjust motor speed and do PID once every 4 milis. i personally don't know why thats needed but it seems that its needed at least according to the articles i read.
2. right now, the message coming from the transmitter effects the "desired value" of the Pid with the range of -250 to 250 degrees per second. the Value subtracted to it is the Raw gyro Value taking into account the offset of the Gyro. as far is i have seen, this should be enough to fly in "rate mode" which is what the Angle mode would build on. if something is missing, please to tell me since needless to say, this doesn't fly and i dont know what im missing.
3. Motor 1 seem to lag behind all other motors by a flat 150. if i dont write 150u+ , then it doesn't even start. its the same motor thats shutting of when turning the power too high. im beginning to think that it maybe the ESC and i should replace it.
4. any questions or suspicions, please do tell. i appreciate any type of input. thank you.
5. there is a word limit in the Forum but the way i communicate with the MPU is using jeff's library. google "MPU 6050 jeff" and it comes right up. his code is not included in this segment. only my code.
MPU6050 mpu;
MPU6050 accelgyro;
int16_t ax, ay, az;
int16_t gx, gy, gz;
void setup() {
Serial.begin(115200);
pinMode(LedPin,OUTPUT);
pinMode(LedPin2,OUTPUT);
pinMode(Motor1ESC,OUTPUT);
pinMode(Motor2ESC,OUTPUT);
pinMode(Motor3ESC,OUTPUT);
pinMode(Motor4ESC,OUTPUT);
digitalWrite(LedPin,LOW);
digitalWrite(LedPin2,LOW);
ESC.attach(Motor1ESC , 1000 , 2000); //3
ESC2.attach(Motor2ESC , 1000 , 2000);//
ESC3.attach(Motor3ESC , 1000 , 2000);
ESC4.attach(Motor4ESC , 1000 , 2000);
ReadInitialAccValues=true;
}
void loop() {
//Read the Incomeing Message.
ReadMessage();
MessTime=millis();
HandleMessage(Data);
HandleMessage_AnglesAndLED(Data);
if (SignalEnd==true) {
SignalEnd=false;
}
if(ReadInitialAccValues==false){
SetMotorsSpeed();
}
if(MessTime>interval && ReadInitialAccValues==true){
digitalWrite(LedPin,HIGH);
ReadInitialAccValues=false;
ReadInitial_Yaw_Pitch_Roll();
}
}
///////////////// This method reads message from the controller one char at a time.
void ReadMessage(){
char character;
//read a char if you recieve one.
while(Serial.available()>0){
SignalEnd=false; // we recieved a signal.
character = Serial.read(); //read the char
if(character=='-' ){ // "-" is the char we determined to be the end signal char. it can be anything we want but we are used "-".
SignalEnd=true; // meessage ended
RecievedMessage[MessagePosition]='\0'; //end the array with the \0 . its a needed char in the C language.
MessagePosition=0; // reset message position
strncpy(Buff,RecievedMessage,5); // write the message in a buffer.
Data=atoi(Buff); // change the type of data from A char string to an int.
}
else{RecievedMessage[MessagePosition]=character; // save current char in the buffer.
MessagePosition++; // move the position counter one step so that we dont overwrite our previously saved char.
}
}
}
//========== Set the Motor Speed =============
void SetMotorsSpeed(){
MessTime2=millis();
if(MessTime2-HoldTime2>interval2){
HoldTime2=MessTime2;
Adjust();
}
}
//============ Handle Messages Recieved From From Master========
//This handles the Data after its received. All Data is changed from char array to int. Depending on the int, we determine the appropriate action by the Quad.
void HandleMessage(int RecievedData){
if(RecievedData>=1000 && RecievedData<2000){
MotorPower_Throttle=RecievedData;
}
else if( RecievedData==1000){
Data=1000;
MotorPower_Throttle=1000;
SignalEnd=false;
}
}
void HandleMessage_AnglesAndLED(int RecievedData){
if(RecievedData>190 && RecievedData<280){
if(digitalRead(LedPin2)==HIGH){
digitalWrite(LedPin2,LOW);
}
else{digitalWrite(LedPin2,HIGH);}
}
if(RecievedData>=400 && RecievedData<500){
RCx=(RecievedData-400)*2;
}
else if(RecievedData>=500 && RecievedData<600){
RCx=(RecievedData-500)*-2;
}
else if(RecievedData>=600 && RecievedData<700){
RCy=(RecievedData-600)*-2;
}
else if(RecievedData>=700 && RecievedData<800){
RCy=(RecievedData-700)*2;
}
else if(RecievedData>=800 && RecievedData<900){
RCy=0.0;
}
else if( RecievedData>=900){
RCx=0.0;
}
else if(RecievedData>=200 && RecievedData<300){
RCz=(RecievedData-200)*-2;
}
else if(RecievedData>=300 && RecievedData<400){
RCz=(RecievedData-300)*2;
}
}
void Adjust(){
PidTime=micros();
accelgyro.getRotation(&gx, &gy, &gz); // This line reads the Gyro value from the MPU 6050
gx=((gx/131)* 180/M_PI);
gy=((gy/131)* 180/M_PI);
gz=((gz/131)* 180/M_PI);
if(gx<minInput){gx=minInput;}
if(gy<minInput){gy=minInput;}
if(gz<minInput){gz=minInput;}
if(gx>maxInput){gx=maxInput;}
if(gy>maxInput){gy=maxInput;}
if(gz>maxInput){gz=maxInput;}
TimeError=(PidTime-LastPidTime)/1000000;
CurrentReading_Yaw=gz;;
CurrentReading_Roll=gx;
CurrentReading_Pitch=gy;
Desired_Roll=RCx; // this is values from the transmitter
Desired_Pitch=RCy;
Desired_Yaw=RCz;
Desired_Yaw=map(Desired_Yaw,-180,180,-350,350);
Desired_Roll=map(Desired_Roll,-180,180,-250,250);
Desired_Pitch=map(Desired_Pitch,-180,180,-250,250);
Error_Pitch=Desired_Pitch-CurrentReading_Pitch;
Error_Roll=Desired_Roll-CurrentReading_Roll;
Error_Yaw=Desired_Yaw-CurrentReading_Yaw;
int_errorGain_Pitch+=(Error_Pitch*TimeError);
int_errorGain_Roll+=Error_Roll*TimeError;
int_errorGain_Yaw+=Error_Yaw*TimeError;
Integral_Pitch=Integral_gain*int_errorGain_Pitch;
Integral_Roll=Integral_gain*int_errorGain_Roll;
Integral_Yaw=Integral_gain*int_errorGain_Yaw;
Derivative_Roll=Derivative_gain*((Error_Roll-Prev_Error_Roll)/TimeError);
Derivative_Pitch=Derivative_gain*((Error_Pitch-Prev_Error_Pitch)/TimeError);
Derivative_Yaw=Derivative_gain*((Error_Yaw-Prev_Error_Yaw)/TimeError);
Input_Pitch=(Porpotional_gain*Error_Pitch)+Integral_Pitch; // no derivative gain cus it seems unnecessary according to multiple sources..
Input_Roll=(Porpotional_gain*Error_Roll)+Integral_Roll;
Input_Yaw=(Porpotional_gain*Error_Yaw)+Integral_Yaw;
Motor_1_Speed=(MotorPower_Throttle)+Input_Roll+Input_Pitch+Input_Yaw;
Motor_3_Speed=(MotorPower_Throttle)-Input_Roll+Input_Pitch-Input_Yaw;
Motor_2_Speed=(MotorPower_Throttle)-Input_Roll-Input_Pitch+Input_Yaw;
Motor_4_Speed=(MotorPower_Throttle) +Input_Roll-Input_Pitch-Input_Yaw;
int MotorMin=1000;
int MotorMax=2000;
if(Motor_1_Speed<MotorMin){Motor_1_Speed=MotorMin;}
if(Motor_2_Speed<MotorMin){Motor_2_Speed=MotorMin;}
if(Motor_3_Speed<MotorMin){Motor_3_Speed=MotorMin;}
if(Motor_4_Speed<MotorMin){Motor_4_Speed=MotorMin;}
if(Motor_1_Speed>MotorMax){Motor_1_Speed=MotorMax;}
if(Motor_2_Speed>MotorMax){Motor_2_Speed=MotorMax;}
if(Motor_3_Speed>MotorMax){Motor_3_Speed=MotorMax;}
if(Motor_4_Speed>MotorMax){Motor_4_Speed=MotorMax;}
Serial.print("1 : ");Serial.println(Motor_1_Speed);
Serial.print(" 2: ");Serial.print(Motor_2_Speed);
Serial.print(" 3: ");Serial.print(Motor_3_Speed);//
Serial.print(" 4: ");Serial.println(Motor_4_Speed);
ESC.writeMicroseconds(Motor_1_Speed+150); // Why +150? i which i know. that same motor doesnt start unless its getting 150u more than others.
ESC2.writeMicroseconds(Motor_2_Speed);
ESC3.writeMicroseconds(Motor_3_Speed);
ESC4.writeMicroseconds(Motor_4_Speed);
Prev_Error_Pitch=Error_Pitch; // update values that we neeed to carry for the next loop call.
Prev_Error_Roll=Error_Roll;
LastPidTime=PidTime;
}
void ReadInitial_Yaw_Pitch_Roll(){
LastPidTime=micros();
Initial_Yaw =0.0;
Initial_Roll=0.0;
Initial_Pitch=0.0;
}
Last edited:
wafflejock
Well-Known Member
If the motor with the issue is the top left in the image above I'd redo those solder connections. When the wire is stripped back make sure to pre-tin it first, if the solder is having trouble holding onto the wire itself then it might have some enamel coating or something but would check that out first. For the calibration you just need to send the ESC a high PWM/throttle up (2000us pulse) signal before plugging power into the ESC then when you hear one beep from the motors set the throttle down to minimum position (1000us pulse) and should hear confirmation tone on motors then can disconnect battery and should be all calibrated.
If calibration or redoing the soldering for the motor wires doesn't work out for the one in question would try swapping motors between the ESC spots to make sure it's not just the motor itself, and if the problem persists can say it's the ESC most likely.
If calibration or redoing the soldering for the motor wires doesn't work out for the one in question would try swapping motors between the ESC spots to make sure it's not just the motor itself, and if the problem persists can say it's the ESC most likely.
thank you. its been resolved. It seems to be a calibration issue. i calibrated it a few times before. i switched escs and the same issue stayed so i didn't suspect it but yup. its working now
wafflejock
Well-Known Member
That's awesome to hear glad it was just calibration for the one ESC part sure PID tuning and or any filtering will help but be a challenge, glad to hear it's moving in the right general direction now though . Keep us posted
. Keep us postedThat's awesome to hear glad it was just calibration for the one ESC part sure PID tuning and or any filtering will help but be a challenge, glad to hear it's moving in the right general direction now though
its kinda odd but i tried to do some adjustments but it not working. essentially, it seems that it can only go up like that if i increase the speed quickly with significant amount of yaw. so if i adjust the yaw so that its not yawing like a car wheel, than it won't fly up. is that a common issue? which PID term should i adjust for that?
wafflejock
Well-Known Member
Not going to lie I don't have a good answer but can give some guesses. If the I term for yaw is too high then it could be accounting for too big of a window of errors and be in a runaway I suppose. I would suggest checking out "betaflights PID tuning guide" to see if any of the issues they mention sound similar and then take similar action as they suggest there (sometimes chopping certain values by 1/3 but would just follow suggestions based on behavior compared to what they have listed there).
wafflejock
Well-Known Member
The best way to know what's going on here really is to do logging to a file on sd card in a way that is easy to dump into Excel or a similar spreadsheet and generate graphs.
That is without writing custom code for an interface to read black box data, or maybe could make the data format compatible with betaflight black box log viewer application.
That is without writing custom code for an interface to read black box data, or maybe could make the data format compatible with betaflight black box log viewer application.
alright its flying! still problem with yawing. i need to figure out why its not correcting for yaw that well but i could definitely call it flight. my room is too small to let it go free and test it properly. cant say how well its flying sense it keeps smashing into things before taking off fully but it looks really promising. it goes forward rather than straight up but i think that's normal for a rate flight controller.
one question tho, on other forums, someone suggested writing to the Esc using analog write instead of servo. he mentions that servo is 50hz while analog write is 500hz which makes it more suitable, he pretty much suggested using PWM using analog write and map values to 0-255.
is this true that its better? cus my esc doesn't like analogwrite and it doesnt seem to work. either way, ill keep you guys updated and thank you bros, huge help in this forum.
wafflejock
Well-Known Member
What they say has some truth that function will output a higher speed pwm signal but using the servo library works for standard servo signals. The exact frequency of the PWM signal depends on the board and pin as shown in the table here
www.arduino.cc
In general most ESCs and modern flight controllers will use d-shot 600 or d-shot 1200. Looks like someone is working on a library for it here https://arduino.stackexchange.com/questions/43851/dshot-implementation-on-arduino-esc-protocol
You'll probably want to turn off serial logging/debugging once you are ready for flight testing too usually I'll just do this with a
#define DEBUG
Then around the serial logging blocks
#ifdef DEBUG
Serial.println("some debug info");
#endif
this way can comment out the define line to turn off the serial statements (same thing around serial begin). Taking that out can help your overall loop time. Looks like you may be using it for control input but just a general suggestion if only using it for logging and need fast loop times.
analogWrite() - Arduino Reference
The Arduino programming language Reference, organized into Functions, Variable and Constant, and Structure keywords.
In general most ESCs and modern flight controllers will use d-shot 600 or d-shot 1200. Looks like someone is working on a library for it here https://arduino.stackexchange.com/questions/43851/dshot-implementation-on-arduino-esc-protocol
You'll probably want to turn off serial logging/debugging once you are ready for flight testing too usually I'll just do this with a
#define DEBUG
Then around the serial logging blocks
#ifdef DEBUG
Serial.println("some debug info");
#endif
this way can comment out the define line to turn off the serial statements (same thing around serial begin). Taking that out can help your overall loop time. Looks like you may be using it for control input but just a general suggestion if only using it for logging and need fast loop times.
What they say has some truth that function will output a higher speed pwm signal but using the servo library works for standard servo signals. The exact frequency of the PWM signal depends on the board and pin as shown in the table here
analogWrite() - Arduino Reference
The Arduino programming language Reference, organized into Functions, Variable and Constant, and Structure keywords.
In general most ESCs and modern flight controllers will use d-shot 600 or d-shot 1200. Looks like someone is working on a library for it here https://arduino.stackexchange.com/questions/43851/dshot-implementation-on-arduino-esc-protocol
You'll probably want to turn off serial logging/debugging once you are ready for flight testing too usually I'll just do this with a
#define DEBUG
Then around the serial logging blocks
#ifdef DEBUG
Serial.println("some debug info");
#endif
this way can comment out the define line to turn off the serial statements (same thing around serial begin). Taking that out can help your overall loop time. Looks like you may be using it for control input but just a general suggestion if only using it for logging and need fast loop times.
so higher Pwm is better than servo? i did some adjustments and it works with analogwrite right now But i don't notice any difference.
wafflejock
Well-Known Member
Yah in theory sending a higher speed pwm signal is better than a lower speed one but there is time it takes for the motor to physically change speed as well so at some point you're going to be sending signals to the ESCs faster than they can physically make changes so then it doesn't really matter. Basically protocols are in this order for FC to ESC
PWM - most basic certain duty cycle or high/on time corresponds to percent throttle
Multishot
DShot600
Dshot1200
At some point you'll probably max out the CPU trying more advanced protocols or higher speed updates between your FC and the ESCs, but newer/faster protocol you can run at full speed is best bet. In betaflight it shows CPU usage in the bottom of the configurator so various filtering or other features and speed of updates can be tweaked until you are stressing out the CPU. Most FCs use STM32F4 microprocessor that runs at a few hundred MHz whereas the Arduino typically uses a chip from Atmel called the atmega328p that runs at 16MHz at some point you'll likely be running out of CPU time but know that ardupilot managed with limited resources of Atmel chips so it is possible.
In betaflight there are options for running the PID loop and gyro loop frequency think 2k/2k (2000 reads per second and 2000 PID calculations per second) is good enough maybe even less but some people run higher speed loops (if CPU permits)
wafflejock
Well-Known Member
You can used the timeelapsed library to set a counter and keep track of how fast the loop is running and maybe keep a counter for loops done per second to get an idea of what the update frequency can be from the Arduino and if it's an issue.
sometimes i wanna punch the wall! Gaaaah! i had to move the battery cus the build was kinda shaky and weak. As i was doing the reassembling, i peeled off the metal that connects one of the motors to the ESC by mistake so i had to replace the ESC. after tons of re assembling and soldering, ITS NOT WORKING. grrrrrr. its same code but different ESC and i cant figure out why it doesn't work the same. i mean it cant be that different. Both ESCs are fit for 2S and both uses blheli_s firmware. calibrated the same as well so i expected relatively similar results. But nope.
wafflejock
Well-Known Member
Bummer yah working on electronics can be infuriating easy to short something or otherwise make a trivial mistake that sets you back days, it's why I've been collecting more diagnostic and repair stuff over time too. Personally learning about STM32 tools and development at the moment and it's super hit or miss on if an imported project will compile or not and flash or not depending on tool chain and seemingly a million configuration/build variables, incredible anyone is able to make this stuff work