PPRuNe Forums - View Single Post - Future rotorcraft control systems
View Single Post
Old 4th Jun 2005, 18:09
  #9 (permalink)  
Graviman
 
Join Date: Nov 2004
Location: Cambridgeshire, UK
Posts: 1,334
Likes: 0
Received 0 Likes on 0 Posts
Hi Nick,

"...now you are sliding off into the never never land of blade flapping as some kind of stability solution."

Well not really, since i have accepted that my original "understanding" about flap pitch coupling was in error. The gyro just provided an attitude feedback reference.


"The only true solution to stability and control for future helicopters is in electronic systems that are cheap and powerful"

But rely on complicated power hydraulics to implement their control strategies. The biggest single problem area on our "simple" prototype truck is the hydraulics. I'll stick to well thought out mechanisms anyday - especially since a quick visual tells you if it is all there and working.


"Stay with the electronic theme, it is the winner."

As an electronics engineer i agree, as a mechanical engineer i disagree (i should stop studying sometime ). For a smaller R22 type machine the only way would be to introduce (say) a electric power ram, along with associated power electronics and generator. Is it doable? Yes. Is it simple? No.


"Lockheed Cheyenne ... stabilizr bar did not work very well, in fact it needed a good old fashioned electronic stability system anyway."

Well, i'm really more interested in the CL475 light heli, but there is very little documented evidence of how this system worked or performed. It had no electrical or hydraulic complexities to worry about in FMECA design studies though.


"The (AH56) stab bar went unstable at high speed, and caused at least two accidents, one that killed the crew. I'll bet you didn't see that on any marketing web site!"

This is all well documented, but nothing like as well as being involved in that nature of project. I got the impression that McNamara's Defence Procurement Policy and the shortcuts it lead to were as much an issue. Lu could probably fill in the details of the nature of the actual failures, but i gather that disk loading beyond the concept specification was partly to blame. Loss of crew on any program is clearly unacceptable, however, and must be avoided at all cost.

Mart
Graviman is offline