UAV DevBoard pilots:This is an update of a previous post.I deleted version 1.6 of AileronAssist firmware and released version 1.7.The reason is that I noticed that the firmware fail safe does not work in version 1.6. Although the commanded return to launch will work just fine in version 1.6, loss of signal return to launch does not. If you turn off your transmitter, and if your radio does not have a fail safe, its not going to be pretty.If you are using a radio with its own fail safe, it does not matter whether you use version 1.6 or 1.7 of AileronAssist. But if you might ever use a radio that does not have fail safe, you should use version 1.7.Previous versions of AileronAssist are fine. It is only version 1.6 that is affected.I never noticed it before, because I no longer use radios that do not have built in fail safe.Also, version 1.8 of AileronAssist, with waypoint processing, was just released. It supercedes both version 1.6 and 1.7Best regards,Bill Premerlani
In the version of the UAVDevBoard code I'm working on, you can easily configure the board to control a delta wing / elevon configuration directly with no separate mixer. If you still want to use the mixer, you can also try remapping the output channels to use the new extra 4th and 5th output channels for elevator and ailerons, since the 4th, 5th, and 6th output channels' pulses are sent in series as opposed to the 1st, 2nd, and 3rd channels' which are sent at the same time.
The drawback is that this new version of the firmware is still in the fairly early testing phase. :) But a few of us are already flying it, so if you're up for helping to test, that would be great! If so, I'd suggest joining the uavdevboard email list which we're using to discuss development and testing, and I can help you get a copy of the development code.
You might want to contact Ben Levitt, he might already have a solution. Also, I will forward your comment along to him. Ben has been working on a myriad of I/O channel combinations.
I think I know what the problem is, though that will not help you get going any faster: Unlike a Tx, which naturally sorts its outputs into time slots, with a separate time slot for each channel, the firmware for the UAV Devboard has a single time slot, once every 25 milliseconds, in which it sends pulses out to all of the servos. In those cases where the receiver of the pulses (such as a servo) receive only one channel, they have no way of knowing or caring what other servos are seeing.
However, in the case of a mixer, that is receiving two channels, I can see how if it has a microcomputer running the show, it might not be happy to receive pulses on two channels at the same time.
Sorry that you are grounded for now. Hopefully we can get you up and running soon.
Goodmorning Billu,
I've got the Devboard wired in the tailless UAV and the pulse widths set in my Tx 3-position switch to activate the three modes of the AA 1.8 code. With servos plugged directly into outputs one and two, the servos respond correctly in manual and stabilizing mode. Unfortunately, when I attach my mixer in the loop between the Devboard and the servos (for elevon control), I get erratic movement of the servos with Tx output. You would think a mixer would work. I thought the Devboard outputs to the servos were the same as Rx outputs and the mixer works fine with just the Rx.
Looks like I'm grounded until the code is developed for different configurations.
Rats------
Bryan,
It looks ok to me. The PICkit2 did a verify of both program memory and configuration memory. That means it read the memory back and compared it with what it was supposed to be. If there had been any discrepancies, the PICkit2 would have reported it.
Best regards,
Bill
Well Bill,
I think I had success with the PICkit 2 that I just got. I used it to program my Devboard and everything went as expected per your excellent instructions. My only concern was the last step when I did the program execute. Instead of seeing the message you showed, I got the following:
As far as I know, this will be the first time the UAV DevBoard is used in a tailless plane.
Once you get the gains set in AileronAssist, stabilized mode should work really sweet.
I am hoping that you can fly your plane in manual mode while you adjust the gains. If so, what I would do would be to start with stabilized mode with zero feedback gains. That is equivalent to manual mode. Then, gradually raise the gains until the plane levels itself promptly when you take your hand off the sticks in the middle of a turn.
If you cannot fly it in manual mode, then what you should do is plenty of ground testing first. (Actually, come to think of it, you should do plent of ground testing in any case.) Make sure the elevon response to pitch and roll in stabilized mode is in the correct direction. Adjust the gains so that the amount of elevon deflection looks about right.
When I was developing AileronAssist for my Goldberg Endurance, I was getting roll oscillations if I turned the roll gains up too high. The interesting thing was the oscillations did not interfere with my control of the aircraft, they were just annoying and scary the first time you see them.
Then, start out with short flights in stabilized mode. Once stabilized mode is working, the takeoffs will be smooth, stable, and straight as an arrow.
Then, when you have confidence in the stabilization performance, go for a full flight.
Regarding the mixing, I do not see any issues. Once again, of course you want to check it on the ground.
One thing to consider early on is the slew rate of the servos that you are using to drive the elevons. The faster, the better. The latency introduced by the slewing of the servos will utimately limit the amount of feedback gain that you can use. The faster the servos, the higher you can go in feedback gain without inducing oscillations.
By the way, I believe that Ben Levitt has extended the firmware to directly handle all kinds of combinations of control surfaces, including elevons. We have not flight tested his modifications yet, but once we do, and we release his firmware, you will not need the mixer, it will be done for you by the firmware.
Let me know if there is anything I can do to help you. I think you will be pleased by the stabilization performance of AileronAssist, it is ideally suited for elevons, particularly since it was developed on an aircraft without a rudder!
But, please do your development in small steps, to minimize risk.
Bill,
Removing the Ruddercntrl.c file did the trick! Now I’m good to go and my goal with your DevBoard is to autonomously fly my tailless plane. I designed the large fuselage volume with a central compartment at the CG to hold the autopilot and you can see the temporary placement of the board constrained and damped in the compartment with a piece of foam cut to shape.
I’m also showing the mixer (in the yellow shrink tubing) that I bought to allow the DevBoard to control the elevons. Do you know of any issues with using an elevator/aileron mixer between the board and the servos? I’m guessing this would be the first time the DevBoard has been used in a tailless plane.
Take care,
Bryan
It just hit me as to what the problem is. AileronAssist does not use rudder control. The file rudderCntrl.c is a vestige from a long time ago that I did not get around to deleting. It is not in the released project, but it is in the zip file.
All you have to do is delete the file rudderCntrl.c from the directory, and remove it from the project!!
Bill,
I just tried a project “make” in MPLAB IDE V7.50 for your latest version - AileronAssistV1.80 and it looks like I’m getting the same errors I got when attempting this with AileronAssistV1.70:
rudderCntrl.c:9: error: 'YAWKD' undeclared here (not in a function)
rudderCntrl.c:11: error: 'YAWBOOST' undeclared here (not in a function)
rudderCntrl.c: In function 'rudderCntrl': rudderCntrl.c:31: error: 'pwrud' undeclared (first use in this function) rudderCntrl.c:31: error: (Each undeclared identifier is reported only once
rudderCntrl.c:31: error: for each function it appears in.)
rudderCntrl.c:35: error: 'ruddtrim' undeclared (first use in this function)
Is there something I’m doing wrong on my end or is there a bug in the rudderCntrl.c file?
Thanks,
Bryan
P.S. I was able to “make” the roll-pitch-yaw demo program in IDE V7.5 without any errors.
Comments
Bryan
In the version of the UAVDevBoard code I'm working on, you can easily configure the board to control a delta wing / elevon configuration directly with no separate mixer. If you still want to use the mixer, you can also try remapping the output channels to use the new extra 4th and 5th output channels for elevator and ailerons, since the 4th, 5th, and 6th output channels' pulses are sent in series as opposed to the 1st, 2nd, and 3rd channels' which are sent at the same time.
The drawback is that this new version of the firmware is still in the fairly early testing phase. :) But a few of us are already flying it, so if you're up for helping to test, that would be great! If so, I'd suggest joining the uavdevboard email list which we're using to discuss development and testing, and I can help you get a copy of the development code.
http://groups.google.com/group/uavdevboard
Ben
You might want to contact Ben Levitt, he might already have a solution. Also, I will forward your comment along to him. Ben has been working on a myriad of I/O channel combinations.
I think I know what the problem is, though that will not help you get going any faster: Unlike a Tx, which naturally sorts its outputs into time slots, with a separate time slot for each channel, the firmware for the UAV Devboard has a single time slot, once every 25 milliseconds, in which it sends pulses out to all of the servos. In those cases where the receiver of the pulses (such as a servo) receive only one channel, they have no way of knowing or caring what other servos are seeing.
However, in the case of a mixer, that is receiving two channels, I can see how if it has a microcomputer running the show, it might not be happy to receive pulses on two channels at the same time.
Sorry that you are grounded for now. Hopefully we can get you up and running soon.
Best regards,
Bill
I've got the Devboard wired in the tailless UAV and the pulse widths set in my Tx 3-position switch to activate the three modes of the AA 1.8 code. With servos plugged directly into outputs one and two, the servos respond correctly in manual and stabilizing mode. Unfortunately, when I attach my mixer in the loop between the Devboard and the servos (for elevon control), I get erratic movement of the servos with Tx output. You would think a mixer would work. I thought the Devboard outputs to the servos were the same as Rx outputs and the mixer works fine with just the Rx.
Looks like I'm grounded until the code is developed for different configurations.
Rats------
It looks ok to me. The PICkit2 did a verify of both program memory and configuration memory. That means it read the memory back and compared it with what it was supposed to be. If there had been any discrepancies, the PICkit2 would have reported it.
Best regards,
Bill
I think I had success with the PICkit 2 that I just got. I used it to program my Devboard and everything went as expected per your excellent instructions. My only concern was the last step when I did the program execute. Instead of seeing the message you showed, I got the following:
Programming Target (9/23/2009 8:16:25 PM)
dsPIC30F4011 found (Rev 0x1003)
Erasing Target
Programming Program Memory (0x0 - 0x1DFF)
Verifying Program Memory (0x0 - 0x1DFF)
Programming Configuration Memory
Verifying Configuration Memory
PICkit 2 Ready
The message never said that the programming succeeded. Is this alright or did I miss a step?
Thanks again,
Bryan
Wow, I am impressed with your aircraft.
As far as I know, this will be the first time the UAV DevBoard is used in a tailless plane.
Once you get the gains set in AileronAssist, stabilized mode should work really sweet.
I am hoping that you can fly your plane in manual mode while you adjust the gains. If so, what I would do would be to start with stabilized mode with zero feedback gains. That is equivalent to manual mode. Then, gradually raise the gains until the plane levels itself promptly when you take your hand off the sticks in the middle of a turn.
If you cannot fly it in manual mode, then what you should do is plenty of ground testing first. (Actually, come to think of it, you should do plent of ground testing in any case.) Make sure the elevon response to pitch and roll in stabilized mode is in the correct direction. Adjust the gains so that the amount of elevon deflection looks about right.
When I was developing AileronAssist for my Goldberg Endurance, I was getting roll oscillations if I turned the roll gains up too high. The interesting thing was the oscillations did not interfere with my control of the aircraft, they were just annoying and scary the first time you see them.
Then, start out with short flights in stabilized mode. Once stabilized mode is working, the takeoffs will be smooth, stable, and straight as an arrow.
Then, when you have confidence in the stabilization performance, go for a full flight.
Regarding the mixing, I do not see any issues. Once again, of course you want to check it on the ground.
One thing to consider early on is the slew rate of the servos that you are using to drive the elevons. The faster, the better. The latency introduced by the slewing of the servos will utimately limit the amount of feedback gain that you can use. The faster the servos, the higher you can go in feedback gain without inducing oscillations.
By the way, I believe that Ben Levitt has extended the firmware to directly handle all kinds of combinations of control surfaces, including elevons. We have not flight tested his modifications yet, but once we do, and we release his firmware, you will not need the mixer, it will be done for you by the firmware.
Let me know if there is anything I can do to help you. I think you will be pleased by the stabilization performance of AileronAssist, it is ideally suited for elevons, particularly since it was developed on an aircraft without a rudder!
But, please do your development in small steps, to minimize risk.
Best regards,
Bill
Removing the Ruddercntrl.c file did the trick! Now I’m good to go and my goal with your DevBoard is to autonomously fly my tailless plane. I designed the large fuselage volume with a central compartment at the CG to hold the autopilot and you can see the temporary placement of the board constrained and damped in the compartment with a piece of foam cut to shape.
I’m also showing the mixer (in the yellow shrink tubing) that I bought to allow the DevBoard to control the elevons. Do you know of any issues with using an elevator/aileron mixer between the board and the servos? I’m guessing this would be the first time the DevBoard has been used in a tailless plane.
Take care,
Bryan
Oops on my part.
It just hit me as to what the problem is. AileronAssist does not use rudder control. The file rudderCntrl.c is a vestige from a long time ago that I did not get around to deleting. It is not in the released project, but it is in the zip file.
All you have to do is delete the file rudderCntrl.c from the directory, and remove it from the project!!
Best regards,
Bill
I just tried a project “make” in MPLAB IDE V7.50 for your latest version - AileronAssistV1.80 and it looks like I’m getting the same errors I got when attempting this with AileronAssistV1.70:
rudderCntrl.c:9: error: 'YAWKD' undeclared here (not in a function)
rudderCntrl.c:11: error: 'YAWBOOST' undeclared here (not in a function)
rudderCntrl.c: In function 'rudderCntrl': rudderCntrl.c:31: error: 'pwrud' undeclared (first use in this function) rudderCntrl.c:31: error: (Each undeclared identifier is reported only once
rudderCntrl.c:31: error: for each function it appears in.)
rudderCntrl.c:35: error: 'ruddtrim' undeclared (first use in this function)
Is there something I’m doing wrong on my end or is there a bug in the rudderCntrl.c file?
Thanks,
Bryan
P.S. I was able to “make” the roll-pitch-yaw demo program in IDE V7.5 without any errors.
-
1
-
2
of 2 Next