Today was my first flight with my Quadcopter
1) he was airborne then makes a looping and crashed into ground
2) 2 propellers are flying
3) But the quadcopter-system after crash is ok
- engines ok
- l3g4200d ok
- laser range finder ok
- gps running and ok
:-)) but its fly....
i think this is normal for my quadcopter developments.
and i think the code must have some improvementsand perhaps a better hardwareFrame ???
only for informations the 2 attachments:
- ppb-rcAxisPidXF46.spin with pst.output
- ppb-rcAxisPidXF46-1.spin flying code no pst
the show must go on...
thanks for your helps in the last months
regards nomad
Jason,
You have done a great job with this project. Are the videos on the first page of this post with the gyro only and no auto-level? If so your quad seems to hover very nicely. I have read most of this post and I am going to read it again, but have you released your code for the gyro and acc. auto level function? I would love to read though it. I am also building a quad, and after research, trial and error I have realized it is a large task to take on. I have been building one piece of code at a time. Right now I can only run the motors with input from a spectrum transmitter, no gyro or anything. I have purchased the sparkfun ITG3200 AX combo, but I have not tried hooking it up yet. Thank you for doing this work and sharing and helping.
Shawn
Yes, the videos posted here are all using just the gyro, so there's no self-leveling active. I have that code "working", but it's hyper-sensitive to vibration and prone to drifting. I'm trying to figure out if it's excessive vibration in my frame or something wrong in the code.
The core of the self-leveling flight code is dramatically different than that of the gyro-only version, and considerably more complicated. It's based on the DCM code I posted here, though I've made a number of changes to that code to improve the speed and precision. Life has gotten in the way of progress recently, so I haven't had much time to work on it.
I would like to thank you too Jason. I am just finishing up converting your "MinIMU-pasm" to work with the Pololu MinIMU-9 v2 in my setup. The only thing that isn't reading correctly is the temperature. But I really don't need it, I will just use the temp from another sensor I am using.
The gyro, accelerometer, and compass are all I was concerned with and they are reading fine. I haven't tried it in the air yet, I literally just finished the conversion last night and am waiting for new smaller SMT-Prop PCB's to be delivered to mount it on. This is going to save a lot of weight (and space) over the three seperate sensors I was using before. That is if I can do the SMT soldering without wasting ten boards trying. This will be my first attempt.
I would like to thank you too Jason. I am just finishing up converting your "MinIMU-pasm" to work with the Pololu MinIMU-9 v2 in my setup. The only thing that isn't reading correctly is the temperature. But I really don't need it, I will just use the temp from another sensor I am using.
The gyro, accelerometer, and compass are all I was concerned with and they are reading fine. I haven't tried it in the air yet, I literally just finished the conversion last night and am waiting for new smaller SMT-Prop PCB's to be delivered to mount it on. This is going to save a lot of weight (and space) over the three seperate sensors I was using before. That is if I can do the SMT soldering without wasting ten boards trying. This will be my first attempt.
So thanks!
Seeker, what did you have to change in Jason's code to get it to work with the v2? I have the same board and have not been able to get any data out of it.
Seeker, what did you have to change in Jason's code to get it to work with the v2? I have the same board and have not been able to get any data out of it.
Jason I have been playing with a sensor called a 3-Space from Yost Engineering Inc. Today I have all the motors responding correctly to the sensor and the
joysticks. I still have a lot of work to do with the PID settings and getting things scaled properly but thanks to your code I am at the beginning of trying my own self leveling Elev 8.
Whoops! I figured out your pid scaled object can only accept up to $7F00_0000. $8000_0000 on up returns negative values so I thought I had the sensor and joysticks responding properly using ViewPort to look at the outputs.
At least the sticks are correct now but I have more work on getting the sensor outputs adjusted correctly. I notice the most I can get from your scaled PID object is around * .51. using $7f00_0000. Back to playtime!
My input values are really large, so I always needed to scale down - If you scale up your input values, it has the same effect as scaling up the P/I/D values by that scale.
Thanks for that Jason. I scaled up my sensor input. After I'm confident on the sensor alignment I will go about adjusting the PID's with the info you gave in post#50. Just getting were I'm at
has wore my arm out. I really look forward to tuning PID's - NOTTTTT!!!
The best thing to do is start with no D term at all. Keep doubling the P value until it starts to oscillate, then back it off. Now start doing the same with the D term. The effect of the D term is harder to describe - it will help get rid of that oscillation, and should also hel you hit your set point faster. Once the D is tuned you should be able to apply more P again - bump it up in 20% increments until it oscillates, then back off to the last value.
I don't remember what my original values were, so I'll have to check later tonight.
Edit: I just looked at the screen shot from he first post, and my number for P is 2400, D is 2560. Are those the "default" values you mentioned?
PitchRoll_PGain long $9_6000 '2400 << 8
PitchRoll_IGain long $0
PitchRoll_DGain long $0A00_0000 '2560 << 16
PitchRoll_D2Gain long $4000_0000 '16384 << 16
Yaw_PGain long $28_0000 '10240 << 8
Yaw_IGain long $0
Yaw_DGain long $1900_0000 '6400 << 16
Yaw_D2Gain long $0
Also, just to confirm that the lower section PID refers to YAW?
I'm surprised the default values didn't respond for you at all. Be careful if you're using the GroundStation to enter them - The $9600 value is hex, and has already been scaled up. The comment that follows it shows the number that will be displayed in the GroundStation software (the 2400 part).
The GroundStation code takes the number you enter and scales it up before transmitting to the Prop, so if you enter the $9600 value two bad things will happen:
1) The $ in front will confuse the code that's expecting a decimal number, so it'll ignore the rest.
2) The number will be multiplied by a scale (either 256 or 65536, depending which parameter you're entering).
So if you're using the ground station, enter the numbers you see in the comments on the right. If you're already doing that then I may have a bug in the code somewhere. I generally entered the numbers into the code, because I was constantly tweaking it, and every time I reprogrammed the Prop it'd lose the settings.
Thanks Jason for pointing out to start with low P & no D value. It seems to work for a short flight.
Roll/Pitch:
P = 1
D = 48
Yaw:
P = 1
D = 48
It still suffers from accumulated errors (quad doing CW yaw after about 1 to 2 mins of flight) & slight roll but could be countered with the stick. I'll do further tuning after tie down to some safe area.
Yes, I entered the Dec value into the GroundStation but doesn't work for me.
The accumulated errors are pretty normal and you'll never completely get rid of them. I wrote some temperature drift compensation code in the later version (QuadX for the Hoverfly Sport / Open boards) that helps, but with just a gyro there's a limit to how accurately it can track.
I'm surprised that entering "1" works for the P value - Are you putting that in the code as $1_0000, or just 1? (if the latter, that's *very* strange, the former I can see working). Are you using the same sensors, or have you changed any of the sensitivity settings or anything? Just curious.
Yes, the GroundStation software does the shift. (It doesn't have to convert to hex because internally in the program all numbers are stored the same - the hex is just for readability).
And yes, the ITG3200 is the sensor I use, so that should be fine too. :-)
The only thing to check with that board is that the I2C address is the same as the one I use. There are only two possible address values for the ITG3200. If you don't get readings that make sense, change the code to the other address.
There are a couple places it shows up in the code because I didn't use a constant in the older version of the driver. In the file called ITG-3200-pasm.spin, look for two of these lines:
mov i2cDevID, #%11010010 ' Device ID of the ITG3200
My device ID is actually stored as 8 bit, not 7 like the datasheet suggests. When you initiate an I2C read or write, you specify 7 bits for the address, followed by a single bit to tell it whether you're reading or writing, so I store the 7-bit device ID shifted up by one to simplify the driver code.
That means my ID, 11010010, is actually 1101001 with an extra zero tacked onto the end. Your device address is probably 1101000, and you'd have to tack the extra zero on, making your code:
mov i2cDevID, #%11010000 ' Device ID of the ITG3200
Comments
Hi, Jason and Ratronic
Today was my first flight with my Quadcopter
1) he was airborne then makes a looping and crashed into ground
2) 2 propellers are flying
3) But the quadcopter-system after crash is ok
- engines ok
- l3g4200d ok
- laser range finder ok
- gps running and ok
:-)) but its fly....
i think this is normal for my quadcopter developments.
and i think the code must have some improvementsand perhaps a better hardwareFrame ???
only for informations the 2 attachments:
- ppb-rcAxisPidXF46.spin with pst.output
- ppb-rcAxisPidXF46-1.spin flying code no pst
the show must go on...
thanks for your helps in the last months
regards nomad
You have done a great job with this project. Are the videos on the first page of this post with the gyro only and no auto-level? If so your quad seems to hover very nicely. I have read most of this post and I am going to read it again, but have you released your code for the gyro and acc. auto level function? I would love to read though it. I am also building a quad, and after research, trial and error I have realized it is a large task to take on. I have been building one piece of code at a time. Right now I can only run the motors with input from a spectrum transmitter, no gyro or anything. I have purchased the sparkfun ITG3200 AX combo, but I have not tried hooking it up yet. Thank you for doing this work and sharing and helping.
Shawn
Yes, the videos posted here are all using just the gyro, so there's no self-leveling active. I have that code "working", but it's hyper-sensitive to vibration and prone to drifting. I'm trying to figure out if it's excessive vibration in my frame or something wrong in the code.
The core of the self-leveling flight code is dramatically different than that of the gyro-only version, and considerably more complicated. It's based on the DCM code I posted here, though I've made a number of changes to that code to improve the speed and precision. Life has gotten in the way of progress recently, so I haven't had much time to work on it.
The gyro, accelerometer, and compass are all I was concerned with and they are reading fine. I haven't tried it in the air yet, I literally just finished the conversion last night and am waiting for new smaller SMT-Prop PCB's to be delivered to mount it on. This is going to save a lot of weight (and space) over the three seperate sensors I was using before. That is if I can do the SMT soldering without wasting ten boards trying. This will be my first attempt.
So thanks!
Seeker, what did you have to change in Jason's code to get it to work with the v2? I have the same board and have not been able to get any data out of it.
It should be waiting for you in your email.
joysticks. I still have a lot of work to do with the PID settings and getting things scaled properly but thanks to your code I am at the beginning of trying my own self leveling Elev 8.
At least the sticks are correct now but I have more work on getting the sensor outputs adjusted correctly. I notice the most I can get from your scaled PID object is around * .51. using $7f00_0000. Back to playtime!
has wore my arm out. I really look forward to tuning PID's - NOTTTTT!!!
So, I tried the roll/pitch P=40 & D=512. I get responses for roll & pitch. Any clues?
I don't remember what my original values were, so I'll have to check later tonight.
Edit: I just looked at the screen shot from he first post, and my number for P is 2400, D is 2560. Are those the "default" values you mentioned?
Also, just to confirm that the lower section PID refers to YAW?
I'm surprised the default values didn't respond for you at all. Be careful if you're using the GroundStation to enter them - The $9600 value is hex, and has already been scaled up. The comment that follows it shows the number that will be displayed in the GroundStation software (the 2400 part).
The GroundStation code takes the number you enter and scales it up before transmitting to the Prop, so if you enter the $9600 value two bad things will happen:
1) The $ in front will confuse the code that's expecting a decimal number, so it'll ignore the rest.
2) The number will be multiplied by a scale (either 256 or 65536, depending which parameter you're entering).
So if you're using the ground station, enter the numbers you see in the comments on the right. If you're already doing that then I may have a bug in the code somewhere. I generally entered the numbers into the code, because I was constantly tweaking it, and every time I reprogrammed the Prop it'd lose the settings.
Roll/Pitch:
P = 1
D = 48
Yaw:
P = 1
D = 48
It still suffers from accumulated errors (quad doing CW yaw after about 1 to 2 mins of flight) & slight roll but could be countered with the stick. I'll do further tuning after tie down to some safe area.
Yes, I entered the Dec value into the GroundStation but doesn't work for me.
I'm surprised that entering "1" works for the P value - Are you putting that in the code as $1_0000, or just 1? (if the latter, that's *very* strange, the former I can see working). Are you using the same sensors, or have you changed any of the sensitivity settings or anything? Just curious.
As for sensor, I'm using http://www.sparkfun.com/products/10121 from SparkFun. It has ITG3200 so I assumes it is OK?
Just over six months ago, I've never even touch a quadcopter. Now I'm hooked!
And yes, the ITG3200 is the sensor I use, so that should be fine too. :-)
The only thing to check with that board is that the I2C address is the same as the one I use. There are only two possible address values for the ITG3200. If you don't get readings that make sense, change the code to the other address.
There are a couple places it shows up in the code because I didn't use a constant in the older version of the driver. In the file called ITG-3200-pasm.spin, look for two of these lines:
My device ID is actually stored as 8 bit, not 7 like the datasheet suggests. When you initiate an I2C read or write, you specify 7 bits for the address, followed by a single bit to tell it whether you're reading or writing, so I store the 7-bit device ID shifted up by one to simplify the driver code.
That means my ID, 11010010, is actually 1101001 with an extra zero tacked onto the end. Your device address is probably 1101000, and you'd have to tack the extra zero on, making your code:
Hopefully you followed all of that. :-)
http://www.youtube.com/watch?v=3Fj5oIB_jMA&feature=youtu.be
Edit: By the way, my gyro orientation is set at 2 (rotated 90 CW)