I continue to develop my "full scale" gas powered, variable pitch quad-copter.
After watching the video below at
I realized (more vividly) how vulnerable a quad is to any fault in the control system.
Then I saw his video here --> Redundant flight controls where at around 23:30 in the video he informs that he will use quintuple redundancy. That got me thinking about how I could follow the same approach using multiple independent flight controls to provide redundancy for the control system aspect of the project. His project is different in that he has many outputs (~76 electric motors), but I only have 4 collective "swash plates" that I have to move, so the challenge was to come up with a linkage to connect multiple servos in a way that they won't fight each other, but will also be able to retain control if one of the servo's fails.
Below is an image of the non-redundant setup I'm using for collective pitch.
I struggled quite a bit with many different ideas, but finally arrived at this which I think is elegantly simple.
The servo arm is connected to a rod-end which is screwed into the bottom of the lower (non-rotating) portion of the swash plate. If the angle of the servo sweep is kept reasonable (60 to 90 degrees total) this arrangement does not create too much binding or bending of the servo arm.
Looking back at the first image, you can see that I've connected the servo arms together in an equilateral triangle arrangement, with the rod-end at the center of the triangle. The motion path of the rod-end is exactly the same as it would be with a single servo. Of course, this still needs to work if one of the servos fails. If that happens, lets assume the servo just stops moving, and stays in place (gear friction is greater than the linkage torque so servo doesn't "freewheel").
The issue here is that the rod-end only moves one-third the distance of any given single servo movement. So with one failed servo, the rod-end will only move 2/3 the distance of the remaining two active servos. For this reason, the servos should be adjusted so that they have 50% extra travel (only use 2/3 of their range when all 3 servos working).
Another issue is tuning: The system will have lower gain when one servo fails, so I will need to test the flight stability in both cases (all servo's working, and again with a failed servo) to ensure the PID loops will be able to safely control in both situations.
This design works best if the failed servo doesn't freewheel. I'm don't think it will work if the failed servo doesn't freeze in it's failed position.
The idea here, is that each of these servo's would be controlled by a separate flight controller, so the whole control system would be tripley (word?) redundant. Actually, this linkage concept could be extended to make it 4,5 or even 6x redundant, but only 3 servo's can be directly connected to each other by the "Y" linkage. Beyond 3, I will need to join multiple linkages together.
Below is a photo of my non-redundant collective linkage on my most recent test stand. Getting ready to test the vibration of a 2 cycle engine driving a variable pitch 2 blade rotor.
Always interested to hear comments!
Comments
So I was thinking...
If I use a triple redundant system, it would be feasible to allow one of the 3 controllers to implement integral control.
The potential side effects could be:
This controllers servo's would do more work. With proper limiting though could still ensure that the integral function doesn't interfere with basic PD control. I have yet to build the Y frame for the servo's but now have all the materials.
Chris, Yes, if the broken servo free-wheels, I'm SOL.
Regarding pitch control range, I'm planning to only use the middle 2/3 of the servo's range during normal operation so that extra range on the servo is available to compensate for a non-responsive servo.
Good idea on monitoring the servo current, but I must confess, I haven't selected a flight controller yet. In any case, this redundancy is intended to keep the bird in the air in the event of a malfunction during flight. Each servo will function will need to be verified during pre-flight.
Yes, the motor to propeller drive includes a sprag clutch. I wrestled with the best way to do this. I eventually decided to put them as close to the rotor as possible so that the rotor could free-wheel even if the drive belt became entangled in the pulley or it's axle. With all 4 rotors running at different RPM during autorotation, I will need some help from the controller to keep all the rotors in an acceptable speed range, and keep the bird level.
The good news is I have quite a bit of headroom on rotor RPM. I should be able to easily go 50% or even 100% over nominal RPM without a structural issue. I think the tolerance is much tighter for a full scale helo. (10%).
Someone has also suggested a global monitoring system, that doesn't perform any control function, but simply monitors the health of all the components, and parameters and alarms if a fault is detected.
Thanks for your interest.
Interesting project.
Regarding the coupling of the servos as depicted in the image (top of page)... What happens if one of the three servos breaks in way that allows it to "free-wheel" , no resistance ?
If a servo fails and is immobilized , and just happens to be centered such that there is no offset caused by its' failure , the pitch control range for that rotor, (as you have already mentioned ) , would be reduced. This might be noticeable to the operator and hopefully prompt a timely investigation. I don't know if such a failure would be revealed in the data flash logs, but it would be visible to the human eye during a pre-flight or post-flight mechanical inspection.
If you used the Pixhawks' current monitoring (Amperes) to log the current flow for each of the three servo groups (three Pixhawks) independently . There may be a deviation in the current consumption that might show up in the logged flight data , especially if all three data logs were compared with each other.... That would require splitting the servo power distribution for each of the three groups.
..additionally, during the bench testing , one could establish base values for the expected current (amps). Such logging (with analysis) might also help to detect if a servo is binding or becoming troubled or even an engine/governor is having issues.
Does the motor to propeller drive coupling use a spar-clutch (one-way clutch) for auto-gyration like helicopters (R/C & full-scale) utilize?.
Regards
Chris
I posted a comment on Axel Borg's (AmazingDIYProjects) youtube video wondering how he handled integral control with 5 independent controllers, and....HE ANSWERED! Which is very uncharacteristic for him. He indicated that the flight controllers only use P control. I gain is set to zero. He, the pilot, is the I controller. There are of course some negative consequences (like having to hold the cyclic off center if your Cg and Cl don't line up) but that's a minor nuisance. Thanks Axel for your response!
Axel's response
I just would make sure that you limit the maximum servo position of every servo. I also agree the integral parts could run in different direction, but if you make sure that you have some kind of anti windup for your integrator in a range where it makes sense, you should be fine.
I might shouln't have raised those concerns, just build it and test all possible cases. If you discover than problems then ask here for advice. I am an others are more than happy to help you.
Armin, Yes this is a bit tricky. I was wrong before thinking that PID on the roll/pitch rate control would avoid divergence between controllers. This will be a problem if I use integral control. I wonder how the guy in Amazing DIY Projects handled this. Is it possible his FC's only use P and D control? That would make Him, the pilot, the I controller.
If I went with the P only algorithm, I would probably sense when a servo failed, because I would likely have to hold the stick off-center to level the craft.
So let me think this through. Lets say my quad is a "+" configuration to make it simple.
Lets say a servo on my right rotor fails, and just holds its current position. So far no problem.
Now a wind pushes me to the right. So I add left cyclic. This increases the pitch in the right rotor, and decreases the pitch in the left rotor. But, because only 2 of 3 servos are moving on the right, and 3/3 on the left, I get a smaller increase in lift on the right than the decrease on the left. So my total amount of lift decreases, and I begin to descend. Also, if these rotors are spinning CW, the CCW counter-torque from the right rotor increases less than the decrease in the left rotor. So a net decrease in the CCW counter-torque is experienced, and the craft begins to yaw clockwise.
So if a servo fails (stationary) I will see lift and yaw effects with cyclic stick inputs.
Conversely, I will also likely see pitch/roll and yaw effects with throttle stick inputs.
NOW - What if a servo on the right rotor fails, and say it goes rapidly to minimum position.
The craft will immediately roll right, yaw right, and descend. The roll and yaw axis controllers will respond to the sudden rate change from the gyro, and send a correcting signal, and the roll angle controller will aid this as the roll angle deviates from level. (assuming you were hovering). The craft would be drifting right from the right roll, and this will need to be corrected by the pilot with left cyclic in addition to more throttle, and left rudder.
If the P gains are high, the roll/pitch and yaw controls will immediately help to stabilize the craft in the event of a servo failure. Lift (throttle) will need to be compensated for by the pilot unless the craft is operating in some form of altitude hold mode. With a variable pitch quad, there is an actual throttle output which literally controls the gas engine throttle. This will likely be from a speed controller, or will be linked to a mechanical governor to regulate engine speed.
I was assuming that it would be a cascaded PID. Straight roll/pitch I highly would doubt that it would work reliable, if at all.
The integral part might be actually a port of the solution. In normal operation it might could happen that one integral parts winds up to the higher end and the other one on the lower end. As long if the limits are set somewhat decent set it will not matter. But if one servo fails then the integral part of the others will compensate for that. You will not have the same gain as you mentioned before, but the maybe resulting offset (operating point) can be compensated by the integral parts
Armin,
The algorithm I'm playing with has a roll/pitch angle proportional controller cascaded to a roll/pitch rate PID controller.
If I'm thinking correctly, the separate controllers shouldn't "wind up" their integral term, because the PID loop is working on a "roll rate" signal. I will need to think about this some more, but yes, if they were straight roll angle to PID loop, they would certainly diverge with one PID hitting a high limit, while another hits a low limit. Not good.
I understand. Also additional complexity may not reduce the risk if not done very carefully.
I agree. Your system needs to be tuned towards robustness that it can handle safely one servo / flight controller failure.
You are also right you really need a health monitoring system. Otherwise you could have a failure without even noticing (if you did a great job with the tuning) and you flying around without failsafe without knowing it. The servo OK, but feedback signal error is fine, since the feedback is only for the health monitoring and should force a safety landing. That is unfortunately but you would probably also stop your car if the red warning light for low oil pressure is coming up, eve though it is much more likely that you have a failed sensor or connection to the sensor.
Another thing is to think that theoretically with integrators involved in your flight controllers they could theoretically work against each other. Sorry for bringing all that up.
Armin, I hear what you are saying, and....this project has already gotten more complex than I had originally hoped.
So, my approach at this point is to let the healthy systems compensate for the unhealthy ones. I acknowledge that during a failure, there will be a loss in performance and responsiveness, but enough to safely land.
But you bring up a good question, of how do I even know there has been a failure? My concern with introducing a bunch of feedback signals, is that from my experience, the feedback is just as likely to fail as the actuator, so I am introducing a whole new set of failure modes (servo working OK, but feedback signal error).
You've got me thinking though, and I will need to implement some method to tell me when I've got a problem in one of my control systems so that I know to terminate the flight. Thanks for your input!
-
1
-
2
of 2 Next