Cluso - I'd have to check what the *actual* readings are, as my startup routine samples for 2 seconds and uses that as an assumed zero. That said, I know the actual readings are NOT zero, which is why I did the startup code. :-)
The PID code in use is the IntPID routine that you should already have (and if you don't it's attached). My current code reads the gyro values and accumulates them in variables I'll call "angular position". The gyro reads an instantaneous rate, so if you add the "X rotation rate" value to the "X angle value" 200 times a second, you get an estimate of your current X angle, scaled by some factor that's a combination of gyro scale and sample frequency. (I really hope this makes sense).
I'm taking that value and a "desired" value that I'm computing by accumulating the inputs from the remote control, and feeding those to the PID loop. So the "proportional" value is "how far is my current angle from my desired angle", and the "derivative" value is "how far is my desired angular velocity from my measured angular velocity". Sort of.
My P = 12 and my D = 12 (I don't use integral yet). I'm still tuning, but this has given me really good results so far.
Those numbers will only really mean anything in the context of my code, because they're essentially a conversion factor between my accumulated rotation values and the desired throttle output. Since the rotation values are unscaled 16-bit rate values, the accumulated ones tend to get big pretty fast. If your gyro has fewer output bits, you'd need to compensate for it by scaling up my PID numbers accordingly. Does that make sense?
The code for the quad in the video is attached. If you have a hard time following it let me know and I'll go comment the heck out of it and re-post.
I'm about to sign off for the evening, so I'll have to check out your code later, but I'm curious to see where you're at.
Thanks Jason. When you look at my code you will see that it is based on your code and others.
I had hoped to get to try that code this afternoon but something else cropped up so it will have to wait as other things to do.
I think that it might be better to get just positive results back from the rc (0-1000) and from the gyro maybe the same (0-1024) and manipulate them. What are your thoughts?
Nice flight Jason. Are those the Hobby Lobby 400XT motors? I used to buy them on sale for 20 bucks. Only have two left and HL doesn't carry them anymore. (I heard the Esskay factory shut down). I was going to try the 450 size replacement they carry now:
@Jason or any other experts looking at this, in your your rc_receiver_4.spin and rc_receiver_6.spin at the end of your assembly code you have fit mhz with fit 496 after the variables and mhz is defined as 80. What is the purpose of fit mhz?
if_nz mov d4, c1
if_nz sub d4, pe3
if_nz wrlong d4, p1
jmp #:loop
fit Mhz ' Check for at least 1µs resolution with current clock speed
'=================================================================================
pin_mask long %0000_0000
c1 long 0
d1 long 0
d2 long 0
d3 long 0
d4 long 0
p1 long 0
pe0 long 0
pe1 long 0
pe2 long 0
pe3 long 0
FIT 496
Need your help with the next steps for ELEV-8. Specifically, where to place documentation. This isn't the kind of product that lives alone in a PDF - it's got a ton of resources all around it not to mention community involvement, open-source, etc. The Parallax web site wouldn't be the practical place to host the complete set of resources even though it will be the location where you can order a kit.
You may notice that I started a thread for this in the Robotics forum, but I'm having second thoughts about whether or not it's the best place for all of the information to live.
What about WikiSpaces? You see, I won't be the only contributor here. There are many others who could upload various files and tips.
Would like your thoughts on the best place to host this data. We could start on the forums, then move to WikiSpaces, or go straight there today. Think the forum is an acceptable place, and we can let it live here until it outgrows the usefulness of a forum?
We'll be ready to ship in a week so we need to get this part worked out.
Nice flight Jason. Are those the Hobby Lobby 400XT motors?
Yep - I really like these little motors. They're cheap, and they're able to handle more power than they're rated for. I'm sad to hear they've been discontinued, but hopefully the replacements will work well enough. These little guys are also only about 50 grams, which is nice.
TowerPro 18Amp Acro series. They have more programming options than some. It's important to get ESCs that allow you to specify fixed endpoints for the throttle range, otherwise they'll try to adapt to your throttle outputs and screw up the stabilization.
Ratronic: Regarding your question about the FIT keyword, it was intended to verify that the code would be fast enough to run the loop in enough time to ensure a resolution of 1us at the target clock frequency by measuring the number of instructions in the loop and making sure that's less than or equal to the number that can execute per microsecond. I didn't write the code, but that's what I understood it to do.
Thanks Jason, I knew 80 clock cycles @ 80mhz = 1 microsecond - I had never seen 2 FIT's in the same piece of assembly code before and figured FIT 80 between the variables and FIT 496 on the end maybe was some special trick I didn't know about.
Ken: I am not that much into the wiki and certainly not into Blogs/tweets/facebook at all.
We do need to get it out into the wider audience, so I think that there should be a wiki with docs, etc. The wiki is more visible to the "non-prop" audience.
My preference for Elev-8 discussions would be the forums. So the forum and the wiki would require links to each other right at the top.
I think this would give us the best of both worlds (Docs on the wiki, discussions on the forums)
I think that it might be better to get just positive results back from the rc (0-1000) and from the gyro maybe the same (0-1024) and manipulate them. What are your thoughts?
That will work, but if I understand you correctly, you'll be emulating a rate gyro, whereas mine emulates a heading lock gyro. The difference is that a rate gyro suppresses rotation (or tries to achieve a specific rotation value that may be non-zero), while a heading lock gyro attempts to maintain a specific angle / orientation.
By taking samples from the gyro continuously and adding them to a variable, I have the sum total of all the rotations applied to the craft. If the craft isn't moving, the rotations should be zero and so the total should also be zero. If the craft is rotated to the left, then back to the right, the positive rotations will be added to the negative rotations, so the sum should also be zero, because all the samples will cancel each other out (excepting imprecision & drift). A rate gyro can't return you to your original heading - it'll just try to make sure you're not rotating if you shouldn't be.
Both will certainly work to stabilize the thing, but the heading lock gyro should be more stable and require fewer corrections. My original code was just a rate gyro - the heading lock is a noticeable improvement for me.
Jason: Thanks for the info. Aren't the heading lock gyro and rate gyros just the same? The maths calculates the heading lock? I noted there was some maths involved in the Wii Motion Plus driver to return angular calcs and it perhaps these that I require. As I understand it, the ITG3200 is just the combination of the older gyros that are used in the Wii MP.
I will take a good look over your code when I next get a chance to try out my Quad.
Jason: Thanks for the info. Aren't the heading lock gyro and rate gyros just the same?
The math is a little different. The short version is that the rate gyro uses JUST the current and desired angular velocities to make adjustments, whereas the heading hold gyro uses the current and desired orientations. That's the key difference. The orientation used for heading hold is an estimate, computed by summing angular velocity samples over time.
In rate mode, you feed the current angular velocity and desired angular rate into the PID calcs. This means that your code will attempt to correct for undesired angular velocities. This works pretty well, but imagine that your copter isn't perfectly balanced, but instead is a little heavier on the left side. The copter will tilt slightly to the left, the gyro will detect the undesired angular velocity, and the PID will produce an output to stop it. Now that you're not moving, the PID settles down a little, and the weight imbalance causes the whole cycle to repeat. This is called the "weather vane effect" with helis - they tend to weather vane into the wind when using simple rate gyros because they don't know to return you to a set orientation.
A heading hold gyro integrates rate samples over time (sums them together) and therefore has an estimate of your current orientation, not just your angular rate. That orientation is what is fed to the PID loop, along with a desired orientation as your set point. Using the above example again, if the craft tilts slightly to the left, the accumulation of angular rate samples will drift off the set point, and the PID will produce an output to the motors to fix it, tilting the craft back to the right until the accumulated angle value reaches the desired set point again. So it's not just stopping the original rotation - it moves past that, until the craft returns to the orientation you want.
That's excellent video Jason! Also, thanks for the explanation of the rate vs heading lock gyro stuff.
Hopefully, tomorrow I will finish building my ELEV-8 at parallax and do some flying with it using a hoverfly board. I'm sort of testing the build instructions out for them and giving feedback so they can adjust the instructions.
However, the goal (when I get back home) is to use my own board (with the IMU3000 and accell chip which is essentially the same as your setup since I can't use the DMP because invensense is being lame about releasing info for it). I'm going to try using your software (quadx.zip). I should be able to just tweak the code that reads the IGT3200 to instead read the gyro values from the IMU3000 and have it work. I also have some other Gyro and IMU boards (that one from Pololu) that's I might try making alterante drivers for plugging into your code. And of course, I'll share everything.
Ken is motivating me to "get it done". So I should have results one way or the other soon.
Thanks for the explanation. It is pretty much what I anticipated and was easy to follow. The video is great and your copter is very stable. Very impressed indeed.
Oh Santa, I need some more free time please
Roy: I too have a prop board, and a new one coming now I understand a little more about what I want on it. I am using the ITG3200 but for now I am using the Wii gyros which are 2 older gyro chips from invensense. It will be great to see all the prop hardware out there soon - about time - because the prop is so suited to this kind of application.
Unfortunately, I have quite a bit of work on my plate leading up to xmas so I dont expect to be flying until the holidays
I also have some other Gyro and IMU boards (that one from Pololu) that's I might try making alterante drivers for plugging into your code. And of course, I'll share everything.
I bought one of the Pololu boards as well, and I'm porting my gyro/accel module over to the new device. I have the gyro portion reading correctly, so I'm going to put it on a ProtoBoard with some servo connectors and see if I can make another control board that I can just straight swap for my existing one. So far this gyro seems noisier, so I may alter the internals of the code to take gyro readings faster and do some internal averaging or something. The point of all this is that when you're back home and ready to start playing with this stuff, ping me - I may have a working module for the MinIMU-9 by then, or at least can give you a boost in the right direction.
And I love the multi-color LED strips on that quad. I'm going to have to add some more blinkies to mine - it's still kind of hard to tell which way it's pointing. I actually want to machine a "canopy" of sorts with something like a shark fin on it so I can make it easier to tell orientation. Having the GoPro mounted on the front is a big help, but it's not quite enough.
Awesome Jason, thanks. Also, about orientation relative to you, I have been thinking that it should be possible to have the software in the quad keep track of how it has rotated from when you start it, and adjust it's motion based on that. So that if you stay still you can always move the stick in the physical direction you want the quad to move in, and it'll go in that direction. What do you think?
4 - Skids (6:00)
8 - Motor mount plates (6:00)
2 - Main body plates (12:00)
1 -Mini body plate(1:30)
So, ~26minutes of cutting time. Pololu will do cuts for $2.50 per minute, so to cut one quadcopter will cost about $65.00. The delrin will cost approximately $85 for a sheet, that is enough to make four (est.) quadcopters (http://www.mcmaster.com/#delrin-(made-with-acetal-resin)/=f6brff). So, the subtotal is $65.00*4 + $85 = $345, plus 15% for shipping costs so the grand total would be ~$400, or $100 for one quadcopter, Delrin parts only.
So, I have submitted a quote to Pololu and received their response:
Thank you for your interest in our laser cutting service. Your Quote 0J10606 is ready. We actually have the delrin in stock for now, so I quoted you on only the quantity you requested (without filling in extra space). You're only being charge for the material you are using, not the entire sheet. We will begin production of your order after you approve the preview files and order this quote.
QUOTE SUMMARY:
- Cost for cutting your parts: $609.86
- Standard turn time: 5 business days
- Expedited cutting options: We charge an additional 20% ($121.97) per expedited day up to our same-day service.
- Please see your detailed quote at the link below.
The above is for four (4) complete frames, averaging out to $152 per quadcopter. They also gave me a quote on a single frame, and that came out to $177.96. I guess I was a little bit under in my estimate...
Awesome Jason, thanks. Also, about orientation relative to you, I have been thinking that it should be possible to have the software in the quad keep track of how it has rotated from when you start it, and adjust it's motion based on that. So that if you stay still you can always move the stick in the physical direction you want the quad to move in, and it'll go in that direction. What do you think?
I think that's cheating. It has occurred to me too, and as long as you have a compass you could pull it off, but it also assumes that you yourself remain fixed. If you fly it "behind you" and turn to follow it the controls would now be wrong.
The above is for four (4) complete frames, averaging out to $152 per quadcopter. They also gave me a quote on a single frame, and that came out to $177.96. I guess I was a little bit under in my estimate...
If you're interested, I can figure out what my cut times would be and send you a quote. I'm betting it'll be a lot closer to your original estimate.
I think that's cheating. It has occurred to me too, and as long as you have a compass you could pull it off, but it also assumes that you yourself remain fixed. If you fly it "behind you" and turn to follow it the controls would now be wrong.
Well if you can mod your radio, (like I can mine) you could put a compass on your radio and transmit the info up to the quadcopter via one of the extra channels. Then it could compensate for both you and itself rotating.
I think what you're seeing from Pololu is more representative of our true costs as well.
If you're looking for frame-only, we'll offer that too in due course as well (January), but to get started we will have only the full kits to move out the bulk of inventory we've developed for ELEV-8. The first kits should be ready by Monday or thereabouts.
Will you let us know how to order them Monday Ken?
You bet, ratronic. We're working through the details of setting up the pages right now.
Sure 'nuff, HobbyKing has gone out of stock again on ESCs but we have enough to get underway. I'm asking the purchasing manager to increase the orders there to 300+ units for replenishment so we have plenty of spare parts, all the time. If there's one thing I hate, it's supply shortages.
Comments
The PID code in use is the IntPID routine that you should already have (and if you don't it's attached). My current code reads the gyro values and accumulates them in variables I'll call "angular position". The gyro reads an instantaneous rate, so if you add the "X rotation rate" value to the "X angle value" 200 times a second, you get an estimate of your current X angle, scaled by some factor that's a combination of gyro scale and sample frequency. (I really hope this makes sense).
I'm taking that value and a "desired" value that I'm computing by accumulating the inputs from the remote control, and feeding those to the PID loop. So the "proportional" value is "how far is my current angle from my desired angle", and the "derivative" value is "how far is my desired angular velocity from my measured angular velocity". Sort of.
My P = 12 and my D = 12 (I don't use integral yet). I'm still tuning, but this has given me really good results so far.
Those numbers will only really mean anything in the context of my code, because they're essentially a conversion factor between my accumulated rotation values and the desired throttle output. Since the rotation values are unscaled 16-bit rate values, the accumulated ones tend to get big pretty fast. If your gyro has fewer output bits, you'd need to compensate for it by scaling up my PID numbers accordingly. Does that make sense?
The code for the quad in the video is attached. If you have a hard time following it let me know and I'll go comment the heck out of it and re-post.
I'm about to sign off for the evening, so I'll have to check out your code later, but I'm curious to see where you're at.
Jason
I had hoped to get to try that code this afternoon but something else cropped up so it will have to wait as other things to do.
I think that it might be better to get just positive results back from the rc (0-1000) and from the gyro maybe the same (0-1024) and manipulate them. What are your thoughts?
http://www.hobby-lobby.com/450_size_brushless_outrunner_950kv_528688_prd1.htm?pSearchQueryId=2384928
. $20.00 WITHOUT a sale. Just 2mm longer than the 400 size.
What ESC's are you using?
Jim
if_nz mov d4, c1 if_nz sub d4, pe3 if_nz wrlong d4, p1 jmp #:loop fit Mhz ' Check for at least 1µs resolution with current clock speed '================================================================================= pin_mask long %0000_0000 c1 long 0 d1 long 0 d2 long 0 d3 long 0 d4 long 0 p1 long 0 pe0 long 0 pe1 long 0 pe2 long 0 pe3 long 0 FIT 496Need your help with the next steps for ELEV-8. Specifically, where to place documentation. This isn't the kind of product that lives alone in a PDF - it's got a ton of resources all around it not to mention community involvement, open-source, etc. The Parallax web site wouldn't be the practical place to host the complete set of resources even though it will be the location where you can order a kit.
You may notice that I started a thread for this in the Robotics forum, but I'm having second thoughts about whether or not it's the best place for all of the information to live.
What about WikiSpaces? You see, I won't be the only contributor here. There are many others who could upload various files and tips.
Would like your thoughts on the best place to host this data. We could start on the forums, then move to WikiSpaces, or go straight there today. Think the forum is an acceptable place, and we can let it live here until it outgrows the usefulness of a forum?
We'll be ready to ship in a week so we need to get this part worked out.
Thanks,
Ken Gracey
Ken Gracey
Anything is fine with me but my order of preference would be - Blog, Forum, Wiki.
Yep - I really like these little motors. They're cheap, and they're able to handle more power than they're rated for. I'm sad to hear they've been discontinued, but hopefully the replacements will work well enough. These little guys are also only about 50 grams, which is nice.
TowerPro 18Amp Acro series. They have more programming options than some. It's important to get ESCs that allow you to specify fixed endpoints for the throttle range, otherwise they'll try to adapt to your throttle outputs and screw up the stabilization.
Ratronic: Regarding your question about the FIT keyword, it was intended to verify that the code would be fast enough to run the loop in enough time to ensure a resolution of 1us at the target clock frequency by measuring the number of instructions in the loop and making sure that's less than or equal to the number that can execute per microsecond. I didn't write the code, but that's what I understood it to do.
Jason
Edit: 80 instructions = ~4 microseconds
We do need to get it out into the wider audience, so I think that there should be a wiki with docs, etc. The wiki is more visible to the "non-prop" audience.
My preference for Elev-8 discussions would be the forums. So the forum and the wiki would require links to each other right at the top.
I think this would give us the best of both worlds (Docs on the wiki, discussions on the forums)
Yeah, I think there's a "/ 4" missing in there somewhere, but it was correct in spirit.
J
That will work, but if I understand you correctly, you'll be emulating a rate gyro, whereas mine emulates a heading lock gyro. The difference is that a rate gyro suppresses rotation (or tries to achieve a specific rotation value that may be non-zero), while a heading lock gyro attempts to maintain a specific angle / orientation.
By taking samples from the gyro continuously and adding them to a variable, I have the sum total of all the rotations applied to the craft. If the craft isn't moving, the rotations should be zero and so the total should also be zero. If the craft is rotated to the left, then back to the right, the positive rotations will be added to the negative rotations, so the sum should also be zero, because all the samples will cancel each other out (excepting imprecision & drift). A rate gyro can't return you to your original heading - it'll just try to make sure you're not rotating if you shouldn't be.
Both will certainly work to stabilize the thing, but the heading lock gyro should be more stable and require fewer corrections. My original code was just a rate gyro - the heading lock is a noticeable improvement for me.
Jason
I will take a good look over your code when I next get a chance to try out my Quad.
The math is a little different. The short version is that the rate gyro uses JUST the current and desired angular velocities to make adjustments, whereas the heading hold gyro uses the current and desired orientations. That's the key difference. The orientation used for heading hold is an estimate, computed by summing angular velocity samples over time.
In rate mode, you feed the current angular velocity and desired angular rate into the PID calcs. This means that your code will attempt to correct for undesired angular velocities. This works pretty well, but imagine that your copter isn't perfectly balanced, but instead is a little heavier on the left side. The copter will tilt slightly to the left, the gyro will detect the undesired angular velocity, and the PID will produce an output to stop it. Now that you're not moving, the PID settles down a little, and the weight imbalance causes the whole cycle to repeat. This is called the "weather vane effect" with helis - they tend to weather vane into the wind when using simple rate gyros because they don't know to return you to a set orientation.
A heading hold gyro integrates rate samples over time (sums them together) and therefore has an estimate of your current orientation, not just your angular rate. That orientation is what is fed to the PID loop, along with a desired orientation as your set point. Using the above example again, if the craft tilts slightly to the left, the accumulation of angular rate samples will drift off the set point, and the PID will produce an output to the motors to fix it, tilting the craft back to the right until the accumulated angle value reaches the desired set point again. So it's not just stopping the original rotation - it moves past that, until the craft returns to the orientation you want.
The third paragraph on this page explains it in less mathy terms:
http://www.rchelicopter.com/2008/02/13/rc-helicopter-gyro-introduction-rate-gyro-heading-hold-gyro-explained/
I'm not sure how to explain it better than that, but if you implement both and try flying them you'll see the difference pretty quickly.
Check out around 0:30 for hands-off flight, and 4:10 for a nice high aerial shot.
Hopefully, tomorrow I will finish building my ELEV-8 at parallax and do some flying with it using a hoverfly board. I'm sort of testing the build instructions out for them and giving feedback so they can adjust the instructions.
However, the goal (when I get back home) is to use my own board (with the IMU3000 and accell chip which is essentially the same as your setup since I can't use the DMP because invensense is being lame about releasing info for it). I'm going to try using your software (quadx.zip). I should be able to just tweak the code that reads the IGT3200 to instead read the gyro values from the IMU3000 and have it work. I also have some other Gyro and IMU boards (that one from Pololu) that's I might try making alterante drivers for plugging into your code. And of course, I'll share everything.
Ken is motivating me to "get it done".
Oh Santa, I need some more free time please
Roy: I too have a prop board, and a new one coming now I understand a little more about what I want on it. I am using the ITG3200 but for now I am using the Wii gyros which are 2 older gyro chips from invensense. It will be great to see all the prop hardware out there soon - about time - because the prop is so suited to this kind of application.
Unfortunately, I have quite a bit of work on my plate leading up to xmas so I dont expect to be flying until the holidays
I bought one of the Pololu boards as well, and I'm porting my gyro/accel module over to the new device. I have the gyro portion reading correctly, so I'm going to put it on a ProtoBoard with some servo connectors and see if I can make another control board that I can just straight swap for my existing one. So far this gyro seems noisier, so I may alter the internals of the code to take gyro readings faster and do some internal averaging or something. The point of all this is that when you're back home and ready to start playing with this stuff, ping me - I may have a working module for the MinIMU-9 by then, or at least can give you a boost in the right direction.
And I love the multi-color LED strips on that quad. I'm going to have to add some more blinkies to mine - it's still kind of hard to tell which way it's pointing. I actually want to machine a "canopy" of sorts with something like a shark fin on it so I can make it easier to tell orientation. Having the GoPro mounted on the front is a big help, but it's not quite enough.
Jason
So, I have submitted a quote to Pololu and received their response:
The above is for four (4) complete frames, averaging out to $152 per quadcopter. They also gave me a quote on a single frame, and that came out to $177.96. I guess I was a little bit under in my estimate...
I think that's cheating.
If you're interested, I can figure out what my cut times would be and send you a quote. I'm betting it'll be a lot closer to your original estimate.
If you're looking for frame-only, we'll offer that too in due course as well (January), but to get started we will have only the full kits to move out the bulk of inventory we've developed for ELEV-8. The first kits should be ready by Monday or thereabouts.
Ken Gracey
You bet, ratronic. We're working through the details of setting up the pages right now.
Sure 'nuff, HobbyKing has gone out of stock again on ESCs but we have enough to get underway. I'm asking the purchasing manager to increase the orders there to 300+ units for replenishment so we have plenty of spare parts, all the time. If there's one thing I hate, it's supply shortages.
Ken Gracey