Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 18
61  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: December 03, 2013, 11:34:30 am
my question is: with it leveled Angle
  • Output is "-0.35" and Angle [1] is "-6.92"! the question is: these are the Set-pitch and SetRoll should I consider? and if it could not as he spoke compesar adding positive values ​​to have both in Set's "Zero"?
Maybe I didn't make my self clear.. I understood your question previously and I suggested that you calibrate your accelerometer and gyrometer.. Even though we have the same hardware that doesn't mean our offsets are exactly the same.. These offsets can change with humidity, temperature, etc....
I see that Angle[0] and Angle[1] aren't zero when leveled.. This is of course wrong and an indication that you need to calibrate your sensors! No, please don't add a positive value to both.. It will initially compensate but because the angle calculation is an integral, this compensation will build up to become a huge error! So, I'm telling you again, calibrate your sensors..

Now before you make your next comment do this and report your results:

Set the following to zero:

Config.h
Code:
#define ACC_X_OFFSET  0
#define ACC_Y_OFFSET  0
#define ACC_Z_OFFSET  0

#define GYRO_X_OFFSET  0
#define GYRO_Y_OFFSET  0
#define GYRO_Z_OFFSET  0

Add the following lines in Sensor.ino
Code:
void updateAcc(){//High pass filter
  int buffer[3]; //Axl buffer
  MPU.getAxlData(buffer);
  buffer[0]=buffer[0]-ACC_X_OFFSET;
  buffer[1]=buffer[1]-ACC_Y_OFFSET;
  buffer[2]=buffer[2]-ACC_Z_OFFSET;

//---------ADD THESE LINES-------
Serial.print(F("AccX: "));
Serial.print(buffer[0]);
Serial.print('\t');
Serial.print(F("AccY: "));
Serial.print(buffer[1]);
Serial.print('\t');
Serial.print(F("AccZ: "));
Serial.println(buffer[2]);
//------------------------------
  accx_temp=(ACC_HPF_NR*accx_temp+(100-ACC_HPF_NR)*buffer[0])/100;
  accy_temp=(ACC_HPF_NR*accy_temp+(100-ACC_HPF_NR)*buffer[1])/100;
  accz_temp=(ACC_HPF_NR*accz_temp+(100-ACC_HPF_NR)*buffer[2])/100;
}

Now turn on Debug mode by un-commenting the following line in config.h
Code:
//#define DEBUG
//#define DEBUG_ANGLES
//#define DEBUG_GYRO
//#define DEBUG_PID
//#define DEBUG_RX
//#define DEBUG_SERIAL_CHART
Change it to:
#define DEBUG
//#define DEBUG_ANGLES
//#define DEBUG_GYRO
//#define DEBUG_PID
//#define DEBUG_RX
//#define DEBUG_SERIAL_CHART

Now disconnect your motors and upload the code to your quadcopter.. Now level your quadcopter and open the Serial monitor.. you should see the accelerometer values for X, Y and Z axis.. Type these down..

Now write your values in the config.h file where you previously zero'ed the values:

Code:
#define ACC_X_OFFSET  "TYPE THE X VALUE HERE"
#define ACC_Y_OFFSET  "TYPE THE Y VALUE HERE"
#define ACC_Z_OFFSET  "SEE COMMENT BELLOW"
For the Z value, you'll have to compensate so that the Z axis gives 265 when the quadcopter is perfectly leveled.. So if your output for the Z axis is 240, you calculate the offset with the following: OFFSET = YOUR_VALUE - 265; So for a value of 240 the offset will be OFFSET=240-265 = -25

Now delete the lines that we added to Sensor.ino because we are done with the accelerometer calibration.

For the gyrometer calibration, go to the config.h and un-comment the following lines:
Code:
//#define DEBUG
//#define DEBUG_ANGLES
//#define DEBUG_GYRO
//#define DEBUG_PID
//#define DEBUG_RX
//#define DEBUG_SERIAL_CHART
Change it to:
#define DEBUG
//#define DEBUG_ANGLES
#define DEBUG_GYRO
//#define DEBUG_PID
//#define DEBUG_RX
//#define DEBUG_SERIAL_CHART

Now upload the code and open the Serial monitor.. Make sure that the quadcopter is standing perfectly still and write down the gyro-values for the three axis..

Write these values in config.h:
Code:
#define GYRO_X_OFFSET  "TYPE THE X VALUE HERE"
#define GYRO_Y_OFFSET  "TYPE THE Y VALUE HERE"
#define GYRO_Z_OFFSET  "TYPE THE Z VALUE HERE"

When your all done with these steps, try outputting the angles again and see if they are zero.. If they are not zero, then please report here and type the new angles for the leveled quadcopter...
62  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: December 03, 2013, 07:40:06 am
Basel,
LED's question was due to the issue of PID because you said a delay could increase output before, so I asked, but thought I would have some problems if you put a 50 millisecond blinking a led in the loop!

Yes I told you a delay would disrupt the PID timing and that is true.. But you don't need a delay to make a LED blink! Look at the example for "Blink without delay" http://arduino.cc/en/Tutorial/BlinkWithoutDelay ..

Basel,
  unable to calibrate the ESC´s to work with PWM as you had said, which still did not understand very properly is if you are zeroing the two values ​​of the angles "Pitch and Roll" or is leaving as setpoint values ​​are now output as "0 and -7 "(when capped)? it could reset the values ​​as some do by simply adding the corresponding void the output value when it is level!
Or is leaving the setpoint adjusted with the output of the sensors on the transmitter ... Type leaving the set "Zero" and "-7" in trasmissor at least in the angle mode?
Look, I got more stable values ​​with the Kalman filter, but are very similar to the complementary filter you are using!

You can set the offset of the angle in the config.h file.. You do that by making sure that your accelerometer and gyrometer are calibrated.. First make sure that your quad is leveled and not moving.. Read the gyrometer and accelerometer values.. And adjust the values in config.h accordingly.. The values that needs to be adjusted are:

Code:
#define ACC_X_OFFSET 19
#define ACC_Y_OFFSET 7
#define ACC_Z_OFFSET -73

#define GYRO_X_OFFSET 1.418431
#define GYRO_Y_OFFSET -1.05606
#define GYRO_Z_OFFSET -0.54401
63  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: December 02, 2013, 04:50:57 pm
Basel,
where in the code would to insert a blinking LED to indicate low battery?
Insert the LED code wherever you like.. There is no battery-status code, so feel free to write one, as long as the LED isn't LED 13.. Because LED 13 is tied to the angle/rate mode status...

and another thing, the setpoint angle mode is the output of the sensors? Zero "0" and "-7" and so rate is zero or the same? Because you crossed the ânguloX with gyro Y?

No, it's not the same.. I didn't cross angleX with gyro Y..  It is just the way I set up my coordinate system.. When you for example Roll you move the Z- and X axis while the Y axis is constant (because it's rotating around its own axis).. Staring at this picture for 5 minutes will make things clearer..


So you calculate:

Accelerometer: AngleX_Acc = tan(accX/accZ)
Gyrometer: AngleX_Gyro = gyroY*dt + AngleX_Old
Comp-filter: AngleX = (CONSTANT)*Angle_Gyro + (1-CONSTANT)*Angle_Acc
64  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 30, 2013, 01:55:34 pm
@Satiro: Using the servo library is a bad choice.. It's simply to slow (50Hz vs the 500Hz PWM).. Anyway.. You'll probably be able to fly it in rate mode, but not angle mode.. Angle mode needs 500Hz PWM... Looking at your code you have 4 huge mistakes, in ControlV.ino:

Code:
 
  M1.write(throttle);
  M2.write(throttle);
  M3.write(throttle);
  M4.write(throttle);

It should be:
Code:
 
  M1.write(m1);
  M2.write(m2);
  M3.write(m3);
  M4.write(m4);

And you need to change the defined range for the PID's because the servo library takes values between 1000-2000us compared to the PWM 0-254... The start PID-values can be approx. by scaling the default values in the config.h with a scaling factor of (2000/254 = 7.9) .. But be careful though, if you'd like, start with half of the default PID values and work yourself up...

Another thing, you chose to use M1.write, but to send the right values I believe you'd have to change it to M1.writeMicroseconds for all of the motors..

@Xeno: I'm glad that it's working for you.. Well, bluetooth won't work out of the box assuming you're using a bluetooth modem (serial) module.. The reason is one of the serial pins is used by the receiver.. What you could do is maybe use SoftwareSerial together with a bluetooth modem.. The implementation is straight forward.. There is a lot of examples on how to use SoftwareSerial, so I suggest you start of by reading those...

//Basel
65  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 28, 2013, 06:20:50 pm
First off, I want to apologize for the people waiting for the UNO/MEGA versions of this code.. I have a lot going on right now and simply not a lot of free time to work with this.. But I'm still open to answer any questions when I have time, so if any volunteers want to take a shot "like Elmardus" and write a UNO/MEGA version, then please go ahead, and I'll try to help along as much as I possibly can..

@Elmardus: I took a quick look around the code you wrote/changed.. And I have some feedback... First off, I'm happy that it didn't arm because if it did, that would have been dangerous.. The reason? Is the delay(3000) you put in "BlueCopter.ino" under setup().. If you want to initiate something and throw something out through serial and follow up with a delay then please do it before the following line: tp=millis(); or move tp=millis(); down to the very last line in the setup() section.. tp=millis() defines the start time-point for all of the PID's in the system... So if you follow up with a delay and the quadcopter moves/shakes or whatever when it's about to leave that delay, that will result in a huge controller output (which in a worst case scenario equals to the quadcopter running the motors at the current speed plus approx. 30-40%)..

Now as I said, I didn't read the whole thing, but just skipped through to the important parts.. I will assume that you know your way around timers, so I skipped checking the initializing part.. Now the reason it didn't arm can be many.. Let me start by asking you a couple of questions:

- Did you get your receiver code to work properly?
- If it is working, does the values that is in rxVal hit the proper configured intervals?? If you don't know which intervals I'm talking about then look in "Config.h" under RX Config, section.. You'll see for example, THROTTLE_RMIN, THROTTLE_RMAX, which means throttle read minimum and throttle read maximum.. Which corresponds to the minimum and maximum values possible in rxVal.. You'll have to read the RAW data coming from your controller with your code "of course" and type these values in the corresponding macro-variables..
- When all your controller macro-variables is set try to arm it again.. If it still doesn't work then try reading the output of the throttle during run-time.. Because the SAFE procedure uses the throttle value to arm/un-arm the quadcopter.. The arming procedure is in FlightCtrl.ino and Motor.ino and looks like this:

FlightCtrl.ino
Code:
#ifdef SAFE
  if(rxVal[0]<1100){
    motorArm();
  }
#endif
Motor.ino
Code:
while(rxVal[0]<1100){};

So as you see if the throttle raw value is under 1100ms then the quadcopter won't start! You can change these values if you'd like, or try to tune your controller output to somewhere in that range..

Edit: One more question, is your ESC calibrated for the PWM range of 125 to 254?? What ESC are you using?? Do they support PWM at a frequency of 480-500Hz??

//Basel
66  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 04, 2013, 07:10:27 pm
For the rate, I can go up to 450Hz now.
Getting the angles, integrating the gyro rates, using atan2 for acc values and finally using a complementary filter takes most of my loop time. I think you did a pretty good optimasation job in your code!

For reading the acc, I think I will read it at 450Hz too but then use a low-pass filter and use the filtered data in the Angle Control Loop at 50Hz only.


All sounds good! Hope you have a video for us with the first-flight soon =)!

//Basel
67  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 03, 2013, 02:30:10 pm
hey you seem pretty well knowledged with this topic. I was wondering if the pin layout would be same for an Arduino Uno.

Hey, this code only works on the arduino leonardo (for the moment).. I'm working on a version for the UNO.. Stay tuned!

//Basel
I am not that experienced on this stuff, i can not order the parts yet. If I have an Arduino Uno as an interface board (seperate from control board of quadcopter) what type of signal will it have to put out to control the quadcopter.

Would it be PPM?

There is no such feature in the code.. It is really up to you and what you want to implement..

//Basel
68  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 03, 2013, 01:11:09 pm
hey you seem pretty well knowledged with this topic. I was wondering if the pin layout would be same for an Arduino Uno.

Hey, this code only works on the arduino leonardo (for the moment).. I'm working on a version for the UNO.. Stay tuned!

//Basel
69  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 03, 2013, 10:19:38 am
I was also thinking, could I use PPM? I have a dragonlink receiver that can output 12ch PPM or so. I have been looking how to implement that into your code, but I haven't managed to do that yet. Would then PPM only use 1 interrupt instead of 4?

Would that be an easier solution?

My code already use PPM.. I think what you meant is PPM-sum.. Which means that you have all the channel-signals sent with one wire... Well, it is easy to program, but I'm going to re-use as much as I can of the existing code.. So I'm not going to write it, sorry  smiley-roll-blue .. Maybe something for you to work out smiley-wink?

//Basel
70  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: November 03, 2013, 08:55:42 am
Is it a lot of work for you to rewrite? I was looking at MultiWii, but the code is not very easy to understand.

Hey,

Well, I'm not very sure, didn't look directly at the differences.. But from the top of my head, I know that the receiving end needs a rewrite.. Everything else, I believe can be left as is.. I need to map all the available ports and see what needs to be changed.. I'll report back when I have something! =)

MultiWii, isnt meant to be understood =P! it's more a software LEGO.. Where you give it your available hardware (in config).. And everything else will be generated (macros) based on your choices... It's simple really..

//Basel
71  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: October 31, 2013, 06:55:25 pm
I don't understand. These are only the times for reading the RAW values for the IMU. It is normal that it takes the same time to read 3 RAW gyro values or 3 RAW acc values!?

Well, I wasn't talking about the time it takes to make an actual read.. If you want to read the data with 100, 400 or 1000 kHz is up to you and what the hardware can handle.. But what I meant is the time between each read, and that should be 1/50 seconds for the acc. and 1/800 for the rate..

//Basel
72  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: October 31, 2013, 05:30:58 pm
Woow that's fast..  (I am a bit jealous since we use the same microcontroller  smiley ). But ESCs refresh update rate are generally around 500Hz, so more than 500Hz is unnecessary?

The rate update rate is 800Hz, going through a moving average filter which slows the update to 400Hz smiley-wink.. Which is a bit slower than the maximum update rate for the ESC.. You see what I did there smiley-wink!?

1140 microsec to read either the 3 gyro values or the 3 acc values => 880Hz
1980 microsec to read the six values => 505Hz
Do you have something like that?

The micros sounds about right, for the gyro that is.. For the acc. it should be slower.. You shouldn't read the acc. more than 50 times per second (50Hz).. So it is not only the "angle-PID" calculations that you do 50 times per second, but actually the reading of the acc. itself also! Reading the acc. more than 50 times per second will lead to a lot of "gibberish" numbers..

If you want to keep reading the acc. that fast then i'd suggest that you put some kind of filter in code (I myself am using a first order low pass filter), just to smooth the output..

The MPU6050 is a good gyro+acc.. Actually better than what I'm using L3G4200D+ADXL345.. Are you doing all the math in your code, or are you using something included in the library (you know calculating angles and such)?

//Basel






73  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: October 31, 2013, 11:20:03 am
Thanks for the quick answer again!

So ok you update your rate values at 300Hz and your angle values at 50Hz. When I looked at the main arduino loop:

Yes, the angle update freq. is 50Hz.. The rate update rate is 800Hz, reread the code smiley-wink

It appears to me that you run FlightControl() even if the values (rates or angles) haven't change. I find this kinda strange.

Strong point there! If you think of it, it's both dumb and smart at the same time smiley.. The reason it is dumb is that you, as you said, run it even when the values haven't changed yet.. The reason it's smart: You save code space! Because it takes a few extra lines of code, to make the same "time check" procedure for the flightcontrol.. And I chose to optimize my code based on size, both to make it simple for the reader to follow along and to kind of compete with the exiciting open source solutions smiley-wink...What if I put a "time check" there, what will I gain? Maybe better accuracy in the scale of microseconds.. But believe me, you don't need that kind of accuracy for perfectly stable flight!

Another thing, so let's say you rate update frequency is 300Hz and angle frequency is 50Hz. So you will update like this:

update rate 1
........................................

In my case the update angle takes some times (reading the accelero values) and I am not too sure if between update rate 6 and update rate 7 there will be really 1/300Hz = 3 mili sec. Did you have the same problem? Like when you update your angle, your rate update frequency will be a bit slower.

I hope this makes sense for you!


You shouldn't have that kind of delay.. Did you initialize your accelerometer right? Because, the accelerometer will update its values once each 1/50 seconds.. But the communication between the accelerometer and Arduino has a speed of atleast 100kHz (I2C)... So you should not get that kind of delay.. I don't know if you read my last post, but I gave you a tip to use micros() instead of millis() for the rate loop, when it comes to the "time-check".. So instead of 1000/FREQ, you'll have 1000000/FREQ..

If you don't figure out the reason for the problem, please post your code, so I can take a look at it.. Also, what kind of IMU are you using?

//Basel
74  Community / Exhibition / Gallery / Re: BlueCopter - Arduino Quadcopter on: October 30, 2013, 07:00:12 pm
So my problem is that, for now, both loops run at the same frequency (around 200Hz). The inner loop could run alone at (I guess) around 300Hz. And I would like the outer loop to run at around 50Hz. But I don't know how to structure my code to obtain this. I looked at your code, but it's not very clear to me how you do it.

Hey,

Well I do it by reading millis() and comparing that to the value 1000/FREQ (which equals to the duration of each loop in milliseconds).. For example:

Code:

#define RATE_FREQ  300 //Hz
#define ANGLE_FREQ  50 //Hz

long prevRate=millis();
long prevAngle=millis();

void updateValues(){

  if((millis()-prevRate)>(1000/RATE_FREQ)){
    //Run rate specific function
    prevRate = millis();
  }

  if((millis()-prevAngle)>(1000/ANGLE_FREQ)){
    //Run Angle specific function
    prevAngle = millis();
  }

}


void setup() {               

 
}

void loop() {
updateValues(); 
}

if you want to see it in my code, then look in the Sensor.ino (https://github.com/baselsw/BlueCopter/blob/master/BlueCopter/Sensor.ino)

On lines 15 (rate) and 19(angle)...

If you have further questions feel free to ask =)!

Edit: Just a small tip.. Use Micros for things with high frequency, like the rate loop.. Just to get better accuracy when it comes to timing =)!

//Basel
75  Using Arduino / Microcontrollers / Re: About to give up using TQFP atmega's, they just don't work! on: October 24, 2013, 11:56:47 am
Sorry for the late reply. The pcb is powered from my arduino so it's the same ground. I have pads connected to TX, RX and RST with a hole through them, wires are soldered to these pads and connected directly to my arduino. I don't have a rst cap, but I've honestly never had a problem with this before (my DIP chips don't need them at least)..

You need the reset cap.. without it the mcu will stay in the reset state (because serial is pulling the reset low while it is open! )... The cap will allow the the reset pin to go low for a brief moment (until it is charged via the 10K resistor connected to Vcc and rst) before it gets charged and goes high..

Try this to test if the missing cap is the problem: disconnect the DTR pin and manually reset the mcu before uploading.. did it work? In that case put the cap where it belongs smiley

//Basel
Pages: 1 ... 3 4 [5] 6 7 ... 18