Comment by Kate Alhola on June 24, 2012 at 4:37am

Redundancy is good idea but tittle bit deeper analysis on failure modes would be useful. About servos, most common failure modes excluding gear tooth damages on bad landings are failure in servo internal brushed DC motor, failure in potentiometer or potentiometer wire got lose due vibration.  Brushed dc motor failure could lead to dead positions or short circuit sucking all electricity from bus. Potentiometer failure causes servo to go one or other opposite end positions and may be draw a lot of electricity. 

Now, when we think this for redundancy and affect of these servo failure modes. If servo draws all electricity from bus, takes electricity out from APM and other servos. You could do separate power feed every servo and even measure current they draw.

The other case, servo trying to drive other end position. If you have two APM's and two servos for same control surface, they just try their best to twist opposite direction and it is not guaranteed that the good guy wins. Ylu need least to be able disconnect faulty servo or whole bus including APM driving faulty servo. The other problem is that there is no way to detect this kind of condition happening. Measuring current for every servo tells that something is wrong but does not tell who is the bad guy. Servos does not provide any position feedback, least the ordinary ones so it makes diagnostic more difficult. Only possible feedbacks are plane behaving wrong way and excess current draw for certain control surface servos. Having position feedback, we least know that this surface does not go to position set by servo control signal. Then we could use some clever algorithm to switch power off from one servo at time to see who is the bad guy.

Having separate control surfaces for both servos does not help at all. Then there may not be excess current warning us but plane just behaves wrong way. I see on picture split elevator ? Now think what happens if one servo driver rudder maximum up position. APM tries to compensate situation to drive other servo more and more down position but without success and no APM knows, who has the bad servo that should be switched off.

If we would like to have redundancy, we need board that drives power to servos independently, that is able to measure current for every servo and also independently switch them off. Then we need some kind of position feedback from control surface. Easiest way may be just hack the servo and get wire from potentiometer out.  

 

Comment by Veikko Vierola on June 24, 2012 at 2:00pm

 @Zachary Eldridge

Think about this servo on the right gives out in flight your system is going to be flaw. I would be put dual servos with that setup. Over two APMS are still over killed. Two servos no so much since they are running on the same signal and one servo fails the other will handle the slack. APM is pretty smart device if that goes down it goes to RTL and failsafe mode automatically.

I have seen many videos where fixed wing gliders fly pretty well with only one aileron. In the picture the plane has dual elevators but only one servo per aileron due to the reason mentioned first.

Comment by Matthew Coleman on June 27, 2012 at 5:08am

@John and Lorenz.  Sorry for the delayed response.  I have been trying to answer this for a long time.

If the autopilot is there to save the aircraft from pilot error, then you need to save the aircraft from autopilot error.  A servo connection failure is detectable at the servo if there are two power routes and two signal paths.  A gps connector failure is detectable at the autopilot, therefore two autopilots is valid.  If these are the most common failures then dual redundancy is makes sense.

To prevent shorts being a problem, you need a fuse box.  An over-current limiter with automatic retry per servo will do this. These are readily available and easy to use.  You may wish to have dual power supplies with an ORing controller feeding the fuse box.  S-Bus has a hub architecture which is suitable for putting an electronic fuse at each servo.  

I2C is completely inadequate for robust data transfer over the distances required.  OpenServo would greatly benefit from a better physical layer.

If I were to build an ultimate system, it would be dual CANbus based with power hubs fed by two individual power feeds.  I wish I had the time to implement this.  It would save me a whole junk of wiring on my latest 11 servo aircraft.

Regards Matt

Comment by Lorentz on June 27, 2012 at 7:59am

@Matthew

Sure I2C is not adequately immune to disturbances, CAN is much more robust.

Too bad that OpenServo did not provide for CAN communication as an option.

Also interesting the electronic fuse option on the servos with the S-Bus architecture.

Regarding redundant control surfaces with independent servos that can be seen in many UAVs:

I was wondering, what if a servo fails (no matter for which reason) driving the control surface to the full extended position ?

Would a second servo + control surface be able to counteract and stabilize the aircraft ?

Is it based on the assumption that a single, fully extended aileron (for example) can be counteracted
 by redundant aileron + aileron of the other wing ?

Comment by Zachary Eldridge on June 27, 2012 at 8:08am

Check this out http://diydrones.com/profiles/blogs/apm2-and-rx-all-in-one less wires to worry about and if you go two apms this helps out with the messy wires. I can see this to work. I have you flown this plane with one aileron before to see how it reacts.

Comment by Matthew Coleman on June 28, 2012 at 1:11am

Lorentz,  

One aileron fully up and one fully down sounds much like airbrakes to me.  If you are stuck with the outer aileron down then you are going to have a very event filled descent.  Most of the events will be tip stalls.

@Zachary,  I have enough trouble with Hitec, nevermind trusting my aircraft to FrSky.

Comment by Andrew Dunlop on June 28, 2012 at 1:59am

@Matthew, agreed, CAN is sufficiently robust to run around a plane (and I2C is not).  But if a CAN servo solution existed or was created, what would be able to drive it?  I can only think of one autopilot that currently supports CAN, and it only sends CAN servo data on a single CAN bus.  This is not to say that I don't support the idea of a CAN servo bus, I do, but I can also see a few hurdles.

Comment by Matthew Coleman on June 30, 2012 at 12:14am

Andrew,  I agree, this is not easy.  There are CAN interface devices available so it is not impossible to implement the full scheme.

There is still much good can be done with a single CAN network. It will support autopilot failures. With some care it would be possible to reduce connector failures also.

Comment by Andrew Dunlop on June 30, 2012 at 6:28am

@Matthew, agreed again, there is much good that can be done with even a single CAN backbone.  I did start down the CAN servo bus road, but as the issues started piling up I've had to put it all to one side to await some clarity.  I'm still waiting...

Comment by Matthew Coleman on July 2, 2012 at 7:09am

Andrew,  I also went down that develop route and got quite far before falling apart.  

The hardware project is here: http://code.google.com/p/rc-servo-interface/

and some standard CAN protocol definition started with the mavlink team.

There were many reasons this project failed that was little to do with CAN and more to do with the available autopilot and its resources.  CAN is still my route to getting many sensors around the aircraft without the wiring problem.

Comment

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page