I decided that I wanted to graduate from a thermopile based autopilot to a full IMU based system and the UAV DevBoard looked like it was going to scratch my itch. In the end, I wound up with it on my Multiplex Twister, an elapor foam electric ducted fan rc aircraft. Here's what I've done -One of my motivations starts with the fact that I have flown an FPV Telemaster with an Ardupilot quite succesfully but use it primarily as a failsafe. I did, however, test the waypoint system to confirm it worked. I did have to modify the gains for the aircraft but all in all, I was completely satisfied - that is until the several mornings back in the spring when we had a heavy overcast cloud ceiling where the sky temperature was equal to the ground temperature and the thermopiles couldn't see enough difference to work. (Now that summer is here in full swing, that doesn't look like I'll have that problem again for a while)Once I realized that the red version of the UAV DevBoard came in at a much lower price than the original, I took the plunge. I followed all the instructions, acquired the recommended programmer, and decided the first airplane was going to be my basically stock Easy Star with the only modification being the addition of ailerons. I compiled and programmed the board with the AileronAssist firmware and was pretty amazed by the results when just holding the aircraft in my hands. The DCM algorithm seems to work like a champ. I shook the aircraft pretty agressively, rolled it all around, and then left it propped up against the wall for about fifteen minutes and then came back and leveled it out, and all of the surfaces returned to their trimmed position. Of course, this still doesn't simulate the turning forces on the aircraft so I was going to have to hold my opinion until I actually flew.Just looking at the control surface deflections, I decided I needed more and updated both the roll and pitch gains. Now it was time to fly. Since I was mainly interested in the airplane's behavior in the "stability augmentation" mode I didn't fully test the RTL capability. So when I engaged the system in flight, I quickly discovered that putting a stability augmentation system on an aircraft that is already pretty darned stable turned out to be pretty boring. I could tell it was working, but it wasn't like it had to work too hard to keep a stable airplane level.I then realized that the UAV DevBoard would fit into my Twister with little effort. That would be a much more satisfying endeavor. So I did it, and flew it. When I flipped the switch on, I quickly realized that the gain for the Easy Star was too much for the Twister (since I didn't change it). The airplane started roll rocking with the bank angles getting larger and larger (and the roll rate going back and forth was pretty high) so I quickly turned the system off and brought the airplane in. Hey, at least this was exciting! I was out of daylight so there was no time to change the gain and get back in the air.I knocked the roll gain down (back to the original default value) and when I did get a chance to get back in the air, the wings locked solid when the UAV DevBoard was engaged. I then made what too me was an almost comical discovery - I could only bank the airplane about 30 to 45 degrees (with full lateral stick deflection on the transmitter) and when I added elevator, the airplane would tend to climb while it turned very slowly. I hadn't really thought about the difference in how you turn something like a Telemaster or Easy Star versus a Twister. The Twister moves quickly enough so that I tend to bank 90 degrees and pull on the elevator to get it to come back around. Only banking 30 to 45 degrees makes it difficult to keep in the flight area. I found it entertaining to take an airplane, that although relatively easy to fly is very responsive, and damp out its performance so that it feels sluggish. Since it is a relatively fast airplane, you can't spend much time exploring the control response before it turns into a dot in the distance. So I did a couple of passes with the system engaged, but it was only on long enough to confirm that I didn't have the patience for it to turn around and come back. I wrapped up as the sun set again and landed safely.So - I guess the next step is for me to better decide what I really want the system to do - I'm afraid if I just change the proportional roll gain back up so that it will allow a 90 degree bank angle, I'll get the roll oscillations again. I'll have to think about whether or not a PI control loop will cut it and if not, will a PID system solve the problem.Not knowing when to leave well enough alone, I'd like to be able to add some telemetry and an airpseed sensor so those bring up a question. My understanding is that the spare dsPIC pins that are available are digital and do not support any A/D conversions. If that is true, and if I want to integrate other sensors, I'll need to have another processor do the A/D conversion and send that data to the RX pin of the unused/debugging USART. And when I'm ready to send telemetry, I can use the transmit pin on that USART. That sounds great except...I'm not sure how to make the second USART work. It appears to be set up in the AileronAssist software to write debug data, but if I hook it up to an FTDI cable and monitor the serial port, I get nothing. When I put an oscilloscope on the Tx pin I get nothing. Is there something I'm missing?Regardless, this hobby sure provides me with the ability to tinker, tinker, and tinker some more, which is exactly what I enjoy.
You said, "What might be fun, if I get smart enough to figure it out, is to have the roll stick command roll rate and the pitch stick to control Nz (just like some modern fighters)."
I say, "Go for it!" I think it can be done.
Regarding the Mahony papers, start with, "A coupled estimation and control analysis for attitude stabilisation
of mini aerial vehicles".
Kudos to you and those involved for laying out the hardware and integrating the DCM method - I think I've already gotten my moneys worth out of the board just purely based on the fun I've gotten out of making it work without any changes. I look forward to seeing if I can get smart enough to dig into the firmware and DCM to try some more interesting things.
I'll have to check to see what else I might have done to keep the spare serial port from working correctly as I just checked my code and the bin_out() was NOT commented out. I guess I'll have to figure out the hardware debugger to step through the code to make sure it is being called. This is my first foray into PIC programming but when I tried to run the hardware debugger, it wasn't succesful for some reason that I don't recall. I'll try that again and see if I can get it working.
While I thought it would be a great test of the UAV DevBoard to put it on the Twister, what I didn't think through was that if I stabilized the aircraft in the same way that I was used to for the Telemaster and Easy Star, it probably wouldn't turn very well. What might be fun, if I get smart enough to figure it out, is to have the roll stick command roll rate and the pitch stick to control Nz (just like some modern fighters). So you can see this has really turned into a fun set of unlimited "what ifs" for me. I'll just have to figure out which ones I'm capable of pursuing.
I've downloaded the Mahoney papers and have started through them. I'll have to go through them several times before I'll be able to figure out if I can figure them out. Is there a particular order in which they should be read?
I truly thank you for taking the time to respond and I'll take you up on your offer to contact you if I get stuck, and I'm sure that I will.
One more thing...AileronAssist was written assuming that the plane would not be banked more than 45 degrees.
However, it would be a (relatively) simple matter to extend the firmware to handle any orientation, including 90 degree bank, or upside down. Basically, you can use the DCM to transform the desired response in the earth frame of reference into the plane frame of reference. In that case, a desired turn will automatically map onto the elevator when the plane is banked 90 degrees, and if the plane is upside down, it would reverse the deflection of the elevator for you. Of course, you would also have to control the rudder as well. This is one of the things on my list to do, I am hoping that someone else will get to it first.
I almost forgot...there is another technique that you can use, that I used on my first board a few years ago, and which I am going to apply again, when I get a chance.
In the stabilized mode, you could modify the firmware to "amplify" the control signals coming in from the Rx. Subract the trim values from them, and multiply the result by a suitable gain, and add that to the total control signal for that channel. Then, if you turn up both the "amplification" gain and the stabilization gains, you wind up restoring full control authority to the pilot, while vastly attenuating the effects of the wind.
Best regards,
Bill Premerlani
Mein Job auf Chance in... | Jobs, Berufe und Stellenangebote für die Zukunft...
Meine Chance - Tipps für Bewerbung, Job, Beruf und Zukunft. Zudem Stellenangebote und Umschulung...
Welcome aboard! I hope you will enjoy tinkering with the UAV DevBoard. And thank you very much for reporting you experiences. I was beginning to wonder what the owners of the boards were doing with them, only a few have reported in.
Regarding A/D, alas, there are no spare A/D pins on the board. Sorry.
Regarding the spare serial port, its set at 19,200 baud. Right now, it does not do anything, there is nothing coming out. I used it for debugging, there is a routine bin_out() that I used to debug the binary interface to the GPS, but if you dig into the code, you will see that the call to bin_out() has been commented out. You can use it to do anything you want, it will not interfere with the control and navigation firmware.
Regarding the controls, you are right...I designed them to make a high performance plane behave sluggishly. It is "training wheels" for planes. I have a plane that I buried 5 times last summer, I decided that I needed something to save it. So what I do with the firmware that you see is to help me fly. I use "stabilized mode" for take off and landing, and whenever I get in trouble. Otherwise I fly in manual mode. And I use RTL when the plane gets too far away.
Its my intent that pilots like yourself will take it to the next level, if they are interested. The direction-cosines can be used for much more than what we have done so far. If you are mathematically inclined, read Mahony's papers. What Paul Bizard and I have done so far is only half of what Bob Mahony was saying to do. We have done the "observer" portion only of Mahony's papers, and built simple controls on top of that to get pilots like yourself started. If you also do what Mahony says to do for the controls, then you'll really have something.
In any case, you will probably want to experiment with the gains, or write your own controls. You can do a lot just building on the direction cosines. One thing that I am working on now is using the derivatives of the direction cosines. They are easy to compute using the gyro signals and the direction cosines. For example, the derivative of the pitch direction cosine (rmat[7]) is equal to rmat[8]*omegagyro[0]-rmat[6]*omegyro[2]. I am using this derivative to estimate the pitch rate of the plane, without cross coupling from yaw rate when the plane is banked.
If you have any questions, please contact me. I am rather busy these days, so I cannot guarantee how quickly I will respond, but I will eventually.
Sure - just remember that I'm using Arudpilot software version 1.x and that these are the gains that I currently use for the RTL function and haven't tested them in the waypoint mode. I made several modifications to the control linkage and therefore the old gains I had before (when I did test the waypoint mode) no longer worked well.
Could you please post the PID gains you had for the Telemaster ? I'm in the process of implementing ArduPilot in a SIG Kadet Senior taildragger, so those probably would be better start values than the EasyStar PID gains. Thanks very much.
Comments
You said, "What might be fun, if I get smart enough to figure it out, is to have the roll stick command roll rate and the pitch stick to control Nz (just like some modern fighters)."
I say, "Go for it!" I think it can be done.
Regarding the Mahony papers, start with, "A coupled estimation and control analysis for attitude stabilisation
of mini aerial vehicles".
Best regards,
Bill
Kudos to you and those involved for laying out the hardware and integrating the DCM method - I think I've already gotten my moneys worth out of the board just purely based on the fun I've gotten out of making it work without any changes. I look forward to seeing if I can get smart enough to dig into the firmware and DCM to try some more interesting things.
I'll have to check to see what else I might have done to keep the spare serial port from working correctly as I just checked my code and the bin_out() was NOT commented out. I guess I'll have to figure out the hardware debugger to step through the code to make sure it is being called. This is my first foray into PIC programming but when I tried to run the hardware debugger, it wasn't succesful for some reason that I don't recall. I'll try that again and see if I can get it working.
While I thought it would be a great test of the UAV DevBoard to put it on the Twister, what I didn't think through was that if I stabilized the aircraft in the same way that I was used to for the Telemaster and Easy Star, it probably wouldn't turn very well. What might be fun, if I get smart enough to figure it out, is to have the roll stick command roll rate and the pitch stick to control Nz (just like some modern fighters). So you can see this has really turned into a fun set of unlimited "what ifs" for me. I'll just have to figure out which ones I'm capable of pursuing.
I've downloaded the Mahoney papers and have started through them. I'll have to go through them several times before I'll be able to figure out if I can figure them out. Is there a particular order in which they should be read?
I truly thank you for taking the time to respond and I'll take you up on your offer to contact you if I get stuck, and I'm sure that I will.
One more thing...AileronAssist was written assuming that the plane would not be banked more than 45 degrees.
However, it would be a (relatively) simple matter to extend the firmware to handle any orientation, including 90 degree bank, or upside down. Basically, you can use the DCM to transform the desired response in the earth frame of reference into the plane frame of reference. In that case, a desired turn will automatically map onto the elevator when the plane is banked 90 degrees, and if the plane is upside down, it would reverse the deflection of the elevator for you. Of course, you would also have to control the rudder as well. This is one of the things on my list to do, I am hoping that someone else will get to it first.
Bill
I almost forgot...there is another technique that you can use, that I used on my first board a few years ago, and which I am going to apply again, when I get a chance.
In the stabilized mode, you could modify the firmware to "amplify" the control signals coming in from the Rx. Subract the trim values from them, and multiply the result by a suitable gain, and add that to the total control signal for that channel. Then, if you turn up both the "amplification" gain and the stabilization gains, you wind up restoring full control authority to the pilot, while vastly attenuating the effects of the wind.
Best regards,
Bill Premerlani
Welcome aboard! I hope you will enjoy tinkering with the UAV DevBoard. And thank you very much for reporting you experiences. I was beginning to wonder what the owners of the boards were doing with them, only a few have reported in.
Regarding A/D, alas, there are no spare A/D pins on the board. Sorry.
Regarding the spare serial port, its set at 19,200 baud. Right now, it does not do anything, there is nothing coming out. I used it for debugging, there is a routine bin_out() that I used to debug the binary interface to the GPS, but if you dig into the code, you will see that the call to bin_out() has been commented out. You can use it to do anything you want, it will not interfere with the control and navigation firmware.
Regarding the controls, you are right...I designed them to make a high performance plane behave sluggishly. It is "training wheels" for planes. I have a plane that I buried 5 times last summer, I decided that I needed something to save it. So what I do with the firmware that you see is to help me fly. I use "stabilized mode" for take off and landing, and whenever I get in trouble. Otherwise I fly in manual mode. And I use RTL when the plane gets too far away.
Its my intent that pilots like yourself will take it to the next level, if they are interested. The direction-cosines can be used for much more than what we have done so far. If you are mathematically inclined, read Mahony's papers. What Paul Bizard and I have done so far is only half of what Bob Mahony was saying to do. We have done the "observer" portion only of Mahony's papers, and built simple controls on top of that to get pilots like yourself started. If you also do what Mahony says to do for the controls, then you'll really have something.
In any case, you will probably want to experiment with the gains, or write your own controls. You can do a lot just building on the direction cosines. One thing that I am working on now is using the derivatives of the direction cosines. They are easy to compute using the gyro signals and the direction cosines. For example, the derivative of the pitch direction cosine (rmat[7]) is equal to rmat[8]*omegagyro[0]-rmat[6]*omegyro[2]. I am using this derivative to estimate the pitch rate of the plane, without cross coupling from yaw rate when the plane is banked.
If you have any questions, please contact me. I am rather busy these days, so I cannot guarantee how quickly I will respond, but I will eventually.
Best regards,
Bill Premerlani
heading_max 50
heading_min -50
altitude_max 40
altitude_min -45
Kp_heading 1
Ki_heading 0.01
Kd_heading 0.3
Kp_altitude 5
Ki_altitude 0.001
Kd_altitude 2
Good luck with the Kadet.