Posted by Jason Short on December 18, 2009 at 9:00pm
I finally had some quality time with the Ardupilot Airframe Tester in the air and would like to report, after a few bug fixes and tweaking, I finally have a nice solution.Why this matters and why you should fly it:- It will help you set up your plane properly and give you vital debugging information.- It will help you adjust your stabilization gains- It is a very nice flight stabilizer- It will let you test your Autopilot setup (more on this below)You can read this post to learn about the debugging aspects.What I really wanted to explain is the new Fly-By-Wire mode. It essentially lets you input the relative waypoint location in space, and the plane will try to go there. Now, other than being fun, it is really helpful for debugging and adjusting your gain settings.The new FBW input is proportional and controlled with your radio:Hard right = waypoint is 35° to the right; centered = waypoint is dead ahead; left = -35°Hard up means the waypoint is below you (hey, you can reverse that if you want.) Centered means the waypoint is at the same altitude.While in FBW, the airspeed controller will try and maintain a constant airspeed.Here is the last beta. After this the tester will be final and appear in the download section.Ardupilot_25_Airframe_test_beta4.zipA note about radios - In the header file you can specify radios. Futaba Faast radios can be scanned at 50hz and others at only 25hz. This has to do with how they setup the signals. So there is an option in the header file to use Fubata or other radios. Default is "other." (Spectrum's won't work with the Futaba setting. You need to specify 'other')The events.pde file contains the code for managing your radio's 3 position switch. Instructions are in there as well.The full version of 2.5 should be right around the corner.Jason
Hi Scott, Sorry for the late reply. I had a client in town and a big deadline at work.
I've been working on some new code for the radio input that will allow full radio input during autopilot and I could use some help testing it.
The big issue has always been accuracy vs hardware interrupts vs serial input. If your not familiar with these things be thankful... Anyway I think I have some code that will allow the reading of the radio and reading of the serial input at the same time. I had to heavily filter the input of the radio to do it. (as well as some other tricks) But it should be very fly-able. If this code works out, I can remove all of the current 2.5 workarounds that have been giving me so much trouble.
I will have a flyable version of 2.5 for you tomorrow so you can fly it Sunday if you like. Until then, try this new code out. Be sure to plug in your GPS unit. Don't worry about the lack of nav, the GPS is still outputting serial, which is being read by the Arduino libraries in the Ardupilot. This input is what causes the trouble. Note the behavior of the servos with GPS connected and without. Let me know your results. Are the servos smooth or are they jittery? Can you tell any difference with GPS connected?
I've also added in the Remove Before Fly plug code. This is for in air restarts or reboots. The previous code was a bit unsafe as it over-ridded the failsafe at startup. This code will check for the RBF jumper as required just like the full version.
Jason
I will have time this weekend to do some flying with the new 2.5 Beta code
Currently iam using 2.5 airframe_tester_beta4
If you like I can try out the latest 2.5 with GPS if it availably where and how do I access it?
ah, that all makes sense now, Chris, sorry, didn't know about the toggle reset or the tester not using GPS, was worried I did something wrong...
I should stick to v2.4 for now although I wouldn't mind doing a bit of testing on the full beta as the weather's pretty good here now, ideal for flying. My plane's not an Easystar though.
Are you using the airframe tester for navigation? You should switch to the full 2.5 beta if you want to get GPS lock.
The tester does not use GPS at all. It's mainly to confirm all your systems are up and running and that your gains are set well. If you can fly around in FLY_BY_WIRE mode, with the control stick completely left and right, you should have some decent gains.
The full 2.5 is in the branches folder and is currently being tested by Chris, Jordi and myself. If you are up to it, feel free to test as well. Be sure to understand there are some known bugs that are getting ironed out this week. I'm pretty sure RTL is not functioning because the home location is being set to 0,0,0. This is a minor bug that the new uBlox code introduced, and will be fixed tomorrow.
Graham, that mode toggle reset is a feature, not a bug! We put it in (its in the Attiny failsafe code, not the ArduPilot code) so you could reboot the autopilot in the air if you wanted to.
Hey thanks for the feedback. Look in the header file you'll see pitch_max I think. It's 0.
That limits the elevator for altitude error. You can set that to 500 for 5 degrees.
Flew 4 sortie's today using this beta (beta3 that is), Stabilization works fairly well but there was some drift but there may have been some breeze at higher altitude (it was nearly wind still on the ground). Couldn't check navigation as the code (as is) was setup just for FBW and stabilization.
One strange thing, if the mode switch is switched quickly about 5 times the board resets itself, not that it's a problem as one would never switch that switch like that in flight but not fun if it does reset in the air as the servo's twitch a few times.
At the moment I'm not using the throttle control (or the pitot tube) as I don't want to hand control of that over just yet :) actually my plane doesn't climb much on application of power, it's very neutral that way, does the elevator play any part in altitude correction or is it just for FBW and stabilization?
times.at im Adomino.com Domainvermarktung Netzwerk
times.at: Informationen zum Thema und zu den Bereichen und
Comments
I've been working on some new code for the radio input that will allow full radio input during autopilot and I could use some help testing it.
The big issue has always been accuracy vs hardware interrupts vs serial input. If your not familiar with these things be thankful... Anyway I think I have some code that will allow the reading of the radio and reading of the serial input at the same time. I had to heavily filter the input of the radio to do it. (as well as some other tricks) But it should be very fly-able. If this code works out, I can remove all of the current 2.5 workarounds that have been giving me so much trouble.
I will have a flyable version of 2.5 for you tomorrow so you can fly it Sunday if you like. Until then, try this new code out. Be sure to plug in your GPS unit. Don't worry about the lack of nav, the GPS is still outputting serial, which is being read by the Arduino libraries in the Ardupilot. This input is what causes the trouble. Note the behavior of the servos with GPS connected and without. Let me know your results. Are the servos smooth or are they jittery? Can you tell any difference with GPS connected?
I've also added in the Remove Before Fly plug code. This is for in air restarts or reboots. The previous code was a bit unsafe as it over-ridded the failsafe at startup. This code will check for the RBF jumper as required just like the full version.
Ardupilot_25_Airframe_test_beta_6.zip
I will have time this weekend to do some flying with the new 2.5 Beta code
Currently iam using 2.5 airframe_tester_beta4
If you like I can try out the latest 2.5 with GPS if it availably where and how do I access it?
I should stick to v2.4 for now although I wouldn't mind doing a bit of testing on the full beta as the weather's pretty good here now, ideal for flying. My plane's not an Easystar though.
You guys are doing a great job, well done.
The tester does not use GPS at all. It's mainly to confirm all your systems are up and running and that your gains are set well. If you can fly around in FLY_BY_WIRE mode, with the control stick completely left and right, you should have some decent gains.
The full 2.5 is in the branches folder and is currently being tested by Chris, Jordi and myself. If you are up to it, feel free to test as well. Be sure to understand there are some known bugs that are getting ironed out this week. I'm pretty sure RTL is not functioning because the home location is being set to 0,0,0. This is a minor bug that the new uBlox code introduced, and will be fixed tomorrow.
That limits the elevator for altitude error. You can set that to 500 for 5 degrees.
One strange thing, if the mode switch is switched quickly about 5 times the board resets itself, not that it's a problem as one would never switch that switch like that in flight but not fun if it does reset in the air as the servo's twitch a few times.
At the moment I'm not using the throttle control (or the pitot tube) as I don't want to hand control of that over just yet :) actually my plane doesn't climb much on application of power, it's very neutral that way, does the elevator play any part in altitude correction or is it just for FBW and stabilization?
-
1
-
2
-
3
-
4
-
5
of 6 Next