T3

Endurance.jpg

Flight testing of "AileronAssist" is complete. This is the firmware that I had in mind when I started out. It controls ailerons and elevator to stabilize neutrally stable aircraft and performs return to launch. I was able to use it to fly a Goldberg Endurance with some confidence and ease. This is an aircraft that I crashed 5 times last summer. I have finally soloed with it, though most of the credit goes to "AileronAssist", to Paul Bizard, and to everyone else who has helped me so far.Above is a picture of my Endurance, with the electronics mounted on top with velcro, just like I tell everyone else not to doThe firmware and documenation is available on the main page for UAV DevBoard. For those of you who have the board and have tried MatrixNav, the next step is to try AileronAssist in a neutrally stable aircraft. I think you are going to like it. Its smoother and more precise than I ever imagined it could be.The weather is good today, I am going to get out of here and go do some flying.Best regards to everybody,Bill PremerlaniPS For those of you waiting for restocking of the UAV DevBoard, the first board off the production line is on its way to me. When it arrives, I am going to do thorough flight testing with it before releasing it. I will make an announcement.
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • T3
    Hi Bryan,

    Is there any chance you plugged in the ICD2 before you installed the drivers? That would cause the error message that you saw.

    If that is the case, windows tried to install the ICD2 when you plugged it in, and failed, because it did not already have the drivers it needed.

    Go into the hardware manager and see if there is an unknown device. If so:

    1. Disconnect the ICD2
    2. Delete the unknown device.
    3. Reinstall the drivers.
    4. Try again.

    There is a backup plan: the ICD2 has an RS232 port, we could use that instead of USB if all else fails.

    Bill Premerlani
  • Hi Bill,
    I've got your UAV devboard and the recommended ICD2. Have followed your very thorough guides and the self testing went fine. Now I'm going through the "Getting started with PIC programming" guide and I'm having my own issues with the ICD2. I'm not able to get the drivers installed. I followed the driver installation guide in MPLAB IDE but in the end I get the message,
    "Windows was unable to install your unknown device" and
    "Windows could not find driver software for your device."
    Also, I couldn't find any driver downloads on the Olimex website.
    Have any ideas on what I can try next?
    Thanks
  • T3
    Hugo,

    Regarding rmatbac.c, you are right, it should not be there. My fault. Sorry. I am glad you were able to figure it out.

    Thank you for reminding everyone about libdsp-coff.a and p30f4011.gld.

    Regarding the ICD2 and MPLAB versions, SparkFun just received a new batch ICD2s from Olimex, which have a design change that is supposed to fix the problem of the ICD2 not working with the latest release of MPLAB. One of the new ICD2s is being tested right now by someone who had a lot of trouble with the one they had, right now it seems to be working ok with 8.x. We will see.

    Also, I bought a PICkit2 from Microchip for $40, just to see. It works just fine for me with the latest release of MPLAB. The only thing is, you have to remove the polarizing tab from the ICSP connector on the UAV DevBoard.

    Best regards,
    Bill
  • Hi all,

    I went through the 'can't connect my icd2' and 'reinstall 7.50' the last few days and I actually got the rollpitchyaw demo up and working... Right now I'm trying to re-project the aileronassist in the 7.50 version and first would like to mention for other to not forget to use library file libdsp-coff.a and to include linker script p30f4011.gld
    When trying to compile and link all the .c and .h files from the zip file, I get link errors which tell me both rmat.c and rmatbac.c contain the same function (imu); when leaving out the rmatbac.c file the compilation actually succeeds. Am I right in suspecting the rmatbac.c file is actually a backup file which shouldn't have ended up in a release version of the code?

    thanks for all the affort so far, really having loads of fun here in the Netherlands....
  • T3
    smguest,

    A simple rate yaw or roll rate control is rather easy, you multiply the commanded rate by a gain, multiply the gyro signal by a gain, subtract, and apply the result to the control surface. But, as you say, the basics are not too complicated, but getting it to work is another issue.

    The next step up is for something like a pitch rate control, in which you cannot use the pitch rate gyro directly. In that case, you use the the direction-cosine matrix to transform the gyro signals into the earth frame. The ultimate control, that might be used to control pitch and yaw while banked at 90 degrees for example, might use the DCM to transform the gyro rate signals into the earth coordinate system, compute the desired response in the earth coordinate system, and then transform the desired deflections in the earth coordinate system back to the plane frame.
  • This yaw turning feedback loop is exactly what I hope to figure out how to do for roll rate for the UAV DevBoard in my Twister. It is just an issue of getting enough time to sit down and focus on the code. The basics don't sound too complicated but I'm sure making it work well is another issue.
  • T3
    John,
    What I will do for yaw stabilization will be to interpret the yaw PM signal from the radio as a desired turning rate, and use the yaw gyro in a feedback loop to achieve the desired turning rate.
    Bill
  • Bill

    As you may recall, i doubled PITCHGAIN earlier....others as per you distribution code. The stabilization seemed quite good, even in gusty conditions. So not sure it needs any further tuning, but if you have suggestions, happy to hear them.

    Thanks for the info on the pitch/roll stabilization only...I should have seen that from the code. If you were to add yaw stabilization what would be your baseline since it would be constantly changing in a typical flight circuit? Would you continuously update a baseline based on average heading over some timeframe?

    I think with yaw stabilization the effects of windy conditions would have been completely eliminated, other than the effect of into/with the wind causing altitude changes at constant throttle. (but I be this gets fixed in your upcoming altitude stabilization code).

    Best,
    John
  • T3
    John,
    Congratulations!
    The next thing for you to do is adjust the control gains, let me know if you want some help with that.
    Regarding the stabilization mode, the firmware does not do anything with yaw in stabilized mode. Yaw is controlled only during RTL. I have had some requests to add yaw stabilization, it would not be hard to do.
    In stabilized mode, right now all it does is improve the pitch and roll stability. Mostly I designed it that way for selfish reasons, to help me fly a plane with ailerons, which I am not very good at. If I let go of the sticks, my plane will level off.

    Bill
  • OK thanks Bill

    Well I did my maiden today. Strong gusting winds. Other pilots at the field were having problems. I took off, switched to Stabilization and she leveled right out, impressed everyone.

    I wasn't able to get a long observation, but it appeared that the Yaw did not lock in well or I need to adjust the gains. But the it would have been a lot to expect in these winds.

    I was reluctant to try RTL since I had to modify the code to only enter RTL on Tx OFF and there is some latency in reacquiring the Tx. In these winds I didn't want to take a chance. I need to bind up my DX7 that has more channels available and go to Bill's original code for RTL so I can quickly switch to Manual if it runs into trouble.

    John
This reply was deleted.