Thanks for the feedback. The helicopter now “feels” good, but that doesnet mean its actually good in terns of autopilot ability i guess?
Should i back off VFF a tad, swap to 10hz and try to get P up a bit more? I looked through quite a few of the logs and following Bill’s method for frequency, i come up with alot of repeating 5hz patterns? I certainly could be mistaken though?
It seems to do okay as it is in forward flight, i only had the space to get to 40-50mph or so before hitting the brakes. I also did the same run in reverse for backwards flight and it flew as expected.
Its hard to get a really good feel for it as its limited I’m assuming by the accellerometers to only so mant degres of bank angle. All i do know is it doesent seem to suffer from slow behavior, when i jab the sticks hard it banks down very quickly and if i rock it back and forth quickly it does it quite crisply and i can get the blades to “bark” not unlike any of my 3d machines, its just limited to X degrees of bank
I guess it would just be easier if the Pixhawk flies good auto missions the way it is set up now, but I’m fully expecting further tuning.
A thought, so ive heard from many sources Pixhawk tends to get swamped with 3d flight, like flips and rolls tic tocs or whatnot, so i was thinking. In “stabilize” it is using accellerometers, and gyros if i understand correcrly? Does it use them in every flight mode? What im getting at is this, at times the EKF blows up for X reason and as Chris points out, with a flybar its not an issue because the flybar stabilizes it and you can fly around manually without issue.
Im drawing off my FBL experience and this is what ive found, all but 2 of the newest ones suffer from the accelerometers losing their orientation in hard 3d flight, but its a non issue as you can just flip out of the bailout or stabilized mode and fly manually on gyros alone.
Could Pixhawk be setup to revert to using “only the gyros” if other sensors get swamped? I guess that would equate to a manual mode as i assume if it acts like other controllers in that mode of operation you have to be able to actively pilot it as their are no bank angle limits or self leveling etc.
Is that what acro is supposed to be? Or does every mode with pixhawk use accels?
Keep in mind i have no desire to use Pixhawk for 3d personally, i think its more of a what happens if a bearing lets go in the air and starts producing alot of vibrations that confuse Pixhawks accels or something to that effect? A gyro only mode that requires manual piloting would be a good failsafe i think? Or does this already exist within Pixhawk?
Tim
My point of pulling back the P gain before raising the FILT parameter to 10 hz is to keep the aircraft from getting bad oscillations. I hate for him to just change it to 10 hz and have an Oh Crap moment because its oscillating so badly. Just want him to be careful when changing the FILT parameter especially if he is using it to attenuate oscillations for higher P gain.
Bill, i dont know if you have time to look, or have looked at the latest logs, but im wondering if 5hz is indeed where im having problems? And if so then without a notch filter the best i can hope to do is keep it a 4hz to alleviate?
Tim
As you’ve said, you can’t get the P gain as high as you did with FILT at 4. So going to FILT = 10 will not help getting a higher P gain. The reason FILT =4 is helping you is the fact that your oscillatory frequencies are above 4 hz. If you set FILT to 10 hz, it would have very little, if any, affect on a bad oscillation at 5 hz. Remember that FILT is the Frequency below which the low pass filter is allowing to pass through. Now it is not a direct cut off at the FILT frequency. It’s attenuation effect ramps up as the frequencies go beyond the cut off frequency. [quote=“timbaconheli, post:536, topic:16800”]
A thought, so ive heard from many sources Pixhawk tends to get swamped with 3d flight, like flips and rolls tic tocs or whatnot, so i was thinking. In “stabilize” it is using accellerometers, and gyros if i understand correcrly? Does it use them in every flight mode? What im getting at is this, at times the EKF blows up for X reason and as Chris points out, with a flybar its not an issue because the flybar stabilizes it and you can fly around manually without issue.
[/quote]
So the EKF uses accelerometers and possibly gyros too to determine attitude. And yes it is using attitude to control the aircraft in every mode because everything goes through the attitude controller (for Flybar_mode=0). So if the EKF blows up then there is not much you can do. The only way you might be able to save your heli would be to tune it with the ATC_ANG_ PIT_P and ATC_ANG_RLL_P to zero. This will cause the attitude controller to rely more heavily on the PID rate controller to capture the attitude in all modes but if the attitude solution is lost, it would allow you to switch to acro mode without the bad attitude solution impacting it. This was discussed some by Rob and Leondard in the unusual swashplate behavior topic.
I looked at some older ones last night. It appears the roll oscillation is around 5.5 hz. I have not seen a case where I could see a bad oscillation in pitch. You might have to raise that P gain by itself to see what the frequency is in pitch.
Bill,
Thanks for taking a look at the log. I will bump the P gain up on pitch and see if i can get an ossicilation to present itself there.
Im glad you also see the issue at 5.5hz and it confirms in looking at it the right way then. Is it possible to use your notch filter in 3.5? How is the filter profiled? A very tight V response or more of a parabola? Im farmiliar with audio filtering but not so much in other applications. So your notch will attenuate the target frequency and let everything else through correct? Is it possible to stack filters? Ergo, use a notch to stomp out the specific low frequency instability and use another filter to roll off everything above 20hz or similar?
I remember from my pro audio days though, stacking filtering lead to some unwanted effects, some of them quite weird and unexpected. Would the Pixhawk behave similarly?
I had a conversation with someone who is part of the FBL design world and although he would give no specifics, he confirmed getting good behavior from thier units came down to well designed filtering. I have a unit im using from that company, and as a test i put on some severly unbalanced tail blades on one of my beater helis and it vibrated like crazy, the tail was a blur. I tried to take off and it ossicilated like crazy on all axis, keep in mind with a good tail this heli flew awesome. I put it down and got into the FBL unit and ticked the box for “advanced signal processing” and tried again. It flew awesome again even though it was vibrating like an aerial construction compacter. It also had no issues with reaponse, felt just as crisp as it did before. I checked the vibe logs and the entire flight was above the “clipping” threshold, it looked like a big fat solid line vs a graph with peaks and valleys, it was swamped, but still flew great.
This tells me that their success comes down to some fancy filtering, which as i said, they hold onto withan iron grip. The FBL in this test was mounted with one layer of VHB tape and it was strapped down with a velcro strap.
From my understanding, pretty much every flight controller available uses the same basic sensors, so performance comes down to software/firmware and how well it is designed.
So in short, im more than interested in attempting to implement a notch filter, in theory it sounds like what the doctors ordered?
Im assuming the instability im having is somehow related to vibrations and turing them into a feeback loop? Am i right with that thought, or way off base?
What are my other choices? Moving the controller, or attempting to change the frequency of the vibration profile?
I see Chris is a proponent of reducing the macanical rates of the heli and using that as a way of increasing the gain in the Pixhawk. Ive played around with that with other helis and seen the results of increasing or decreasing servo arm throw thereby changing the mechanical rates. With the way this Trex is set up, i would have to completely change the servo arrangement and go direct to swash and use shorter servo arms as im as far in on the Align arms as i can go with the push pull setup?
Anyways, im just thinking out loud here.
Tim
No you are correct, it is a feedback instability. Yes, the only other way to combat this is to try and change the frequency in which you would want to raise it to get it out of the frequency response of the servo, which I imagine is pretty high. I’ve seen feedback coming through at 8 hz.
I’m no expert on filtering. I know enough to be dangerous and I managed to find a discrete filter that did the trick. I think it is more of a “v” like rather than parabola. Sounded like Leonard was looking to implement one with a few more knobs that allowed the user to adjust depth and width of the notch. I only have one knob that adjusts both and I’ve hard coded it. I’ll see what I can do in the next week. It shouldn’t take long to implement if the developers haven’t modified the PID controller since 3.4.6. Just so you know I won’t have flown this software before you so it will definitely be considered beta but I think it is pretty low risk since I’ve moved it from 3.3 to 3.4 with no issues.
At the present time the ArduPilot software does not do that, Tim. I lost a shoe in the clutch once and made an emergency landing in a grass waterway when all the vibration and EKF alarms went off on my ground station. And I got a EKF Velocity Variance once pushing the helicopter to really high speed in Auto, which kicked it out of auto into Alt Hold. It did not lose its attitude solution with the velocity variance. It did when the shoe broke in the clutch.
So there is just no way around it at the present time for FBL. The thing some people have done is to put an external FBL unit on the helicopter, they use Flybar Mode for direct pass-thru in Acro, and turn off all the rate PID’s like I do with flybar and let the FBL unit do the stabilization part. While the autopilot just sends attitude commands to the FBL unit like a human pilot would, or like it does with my flybars. I think that is the electronic equivalent of using a mechanical flybar, but I do know much more of the details beyond that.
The other thing you can do if you want reliability is put a regular Pixhawk in it and use AC3.3.3. There was a few bugs in 3.3.3 too, but EKF2 seems to not have produced a higher level of reliability over the old EKF used in 3.3. It’s like twin engine airplanes vs singles - you’d think twins are inherently safer and yet the NTSB crash statistics show twins have far higher fatal crash rates than singles do, just because there is twice as much chance of something going wrong. I’ve never personally seen where this EKF “lane changing” actually works. If one IMU is screwed up and it switches, the other one is usually more screwed up, it results in a huge attitude change and the thing crashes. I wish there was a way to turn it off completely because I wouldn’t use it if it could be turned off. Flew APM’s before EKF came along and never had an issue. Who cares if they’re .33 meters less accurate or something? They worked and remain in my book one of the best flight controllers ever put in any model aircraft, along with the software they ran which was much simpler, and more thoroughly vetted and tested.
The more complicated you make something, the more chance it will have problems.
Chris,
I totally get where you are coming from. In my case, on one hand i like the idea of using todays current controller and with fbl, on the other, all of the what if’s have me on edge. I suppose looking at it logically, so far vibe levels have been a non issue as far as the EKF is concerned. I have the instability issues, but hopefully through some filtering that can be solved. In reality, if it flies okay in loiter and through auto missions i would be happy with what i have, although i would still feel better with higher P gains.
I thought long and hard about having an FBL in the mix as a backup, but along with not wanting to get into fancy vibration mounts for the controller and such, i did not want to add complexity and more failure points to the mix.
I don’t know if its possible to write the code as such that in the event of an EKF failure it would revert to just using gyros, but it seems to me that would be more than a worthwile addition to the code!
My goal is a system that can be easily repeatable through the use of off the shelf model kits, and FBL Trex 700 & 800 kits are as easy to come by as a glass of water and parts support is everywhere. That is the logic i used when picking my platform.
I hope no major issues arise when im trying my first auto missions, time will tell.
Tim
Bill,
I appreciate the help. I totally understand the beta nature of all of this. I guess getting down to brass tacks, im using a new, untested flight controller along with beta software on a platform no one else has used “heli” with the Pixhawk 2.1 so its par for the course i guess. Lol. Im sure it will come down to getting back to baby steps and breaking out the concrete blocks and the wooden dowels until it has been tested some.
Tim
We would need to verify this but I do believe if you wanted to use Acro as a back up which would only use gyros for stabilization then set the ATC_ANG_RLL_P and ATC_ANG_PIT_P to zero and tune your heli. It should remove the autopilot reliance on attitude and in theory prevent a crash due to EKF problems, if you can recognize the issue and switch to acro in time.
If I’m not mistaken, I think those are the Stabilize P gains. I don’t think it will even fly in Stabilize with those zero’d out. But I may be wrong on that.
Chris,
If those are indeed the stabilize P gains, what gains am I tuning when I adjust ATC_RAT_PIT_P etc.? Is that a different part of the controller? What would be helpful is a flow chart showing the progression of the signal through the controller and how different modes like loiter and stabilize affect the signal path.
Does something like that exist?
Tim
Those gains are for the rate controller. Which are sent to the attitude controller. Which is ultimately used by Loiter and Auto (as well as all the other modes).
Bill, I would have to test that with a smaller cheaper helicopter like my little 500 to see what that does with those zero’d out. And how you would even go about tuning it.
Tim,
Leonard had posted on my Technique to expand P gains discussion. This was meant to show the changes for revamping the filter scheme but it also show the attitude controller and the PID rate controller. You’ll notice in the attitude controller there are the ATC_ANG_XXX_P params which help the attitude controller better close the loop on angle. The ATC_RATE_XXX_P are in the PID rate controller. http://discuss.ardupilot.org/uploads/default/original/2X/8/89a18ccdd723620db0efe1a5f5b8d5a3dd37a11c.png
Chris,
It would require different PID gains and probably more aggressive to get the holding power the current design has with non zero ATC_ANG_XXX_P params.
Bill,
I guess i missed that chart. So the lower chart with 1st and second order LPF along with the Notch filter and Feed Forward, is that Leonards proposed addition for the next release?
If so, to the layman, it looks as though there are alot more filtering options to be had which could be a very good thing?
I guess with the option of filtering, you could choose to use it, or just leave it wide open and move on?
I have used a notch filter with quads to great effect getting rid of pesky wobbles that the standard LPF wouldent alleviate.
On another note, weather looks good tomorrow, with light wind so… I think im going to pack the 800 up and swing over to the field at some point and flip the magic switch and hope for the best… Hopefully it just holds altitude well and then loiters nicely…? Figure a larger space is best for that test, and some altitilude…
Question, if GPS or barometer goes nuts and it starts to fly away at some point, will flipping the switch back to stabilize immediatly give me control back regardless of GPS signal or barometer/compass status?
Tim
I don’t know when he planned to release this filter scheme. We had this discussion before 3.4.4 was released. I thought we might see it in 3.5 but no dice.
Yes, stabilize does not use those to affect control.
I tried to take off and it ossicilated like crazy on all axis, keep in mind with a good tail this heli flew awesome. I put it down and got into the FBL unit and ticked the box for “advanced signal processing” and tried again. It flew awesome again even though it was vibrating like an aerial construction compacter. It also had no issues with reaponse, felt just as crisp as it did before. I checked the vibe logs and the entire flight was above the “clipping” threshold, it looked like a big fat solid line vs a graph with peaks and valleys, it was swamped, but still flew great.