Has anyone managed to get proper motor redundancy on hexa with PID tuning?
According to my tests, it seems that attitude control loop is just not strong enough(not enough authority) to correct for the missing motor. I have tested this by removing the prop from one of the motors and trying to lift of while holding the copter in hand. This results in copter leaning around 30deg in the direction of the missing motor.
Now, to make things worse, it seems that the yaw controller overpowers the attitude controller, and if you offset the yaw to the wrong direction, you will get a flip, since the yaw controller adds more power to the opposing motors in an effort to correct for the yaw, and the allready strugling attitude controller wont be able to correct for the setpoint error. Ofcourse, if you rotate the quad to the other way, the quad will level itself.
As for the PID tuning, I have tested raising the attitude controllers Imax (setpoint error, not the rate error) term up to 50, which seems to be the maxinum value, but even this does not seem to be enough to correct for constant offset thats left with one motor missing.
I have also tested lovering the gains on Yaw controller which results on beter stability while disturbing the yaw since the copter is basically then concentrating on keeping itself level, and not keeping the heading, but the problem with this aproach is ofcourse that there is no actual control on the yaw direction.
Does anyone have any different results from these? Any ideas on how to solve these problems? Theoretically it should not be impossible to control a hexa with one motor down (on some cases, its actually ok to lose 2 engines). Simplest solution that comes ty my mind could be to just let the I-term of the attitude error to ramp up until the attitude error gets corrected. This might also result on Yaw contoller functioning somewhat properly with one missing engine.
For reference, the tests were performed running:
-firmware version 2.7.1 (APM1)
-copter itself is custom built 3.6kg Hexa
-rctimer 2836-9 (880kv) motors
-around 60cm from motor to motor
I flew my Octo for the first time yesterday. On two flights I had a prop explode. The Octo flew very poorly but did land. I lost almost all control but it stayed relatively level. I agree that this area needs more work. One note: if this had been my Quad, its life would have been over!!! Twice!!!
For reference, the tests were performed running:
- Firmware version 2.7.1 on APM2
- Custom built 3.6kg Octo
- 11x47 props
- RCTimer 30A ESC's with SimonK
- NTP Prop Drive 28-36 265W (750kv) motors (HobbyKing)
- 2 x 5000mAh LiPo's
- 33cm from motor to motor
- Turnigy 9x - er9x firmware - FrSKY DJT
(I like seeing this type of info on all posts... very helpfull. Thanks Joonas)
You may have more luck using the Rate I term and setting the Attitude I to zero. This is the way I set up my quad and it adjusts for offset center of gravity very well. This is a good reference for doing a tune this way:
I have been reading through the code trying to work up to making a little contribution to the code myself and I did notice this problem. There is nothing in the code to ensure that the copter can correct it's self in pitch and roll when compared to throttle and yaw.
Ideally the Motors control code that combines the pitch, roll, yaw, and throttle would detect when any motor reaches maximum throttle and then begins reducing the yaw and then throttle input to ensure that the quad remains level even if it is rotating in yaw and descending.
It may mean that the quad is not easy to fly but it can be landed gently. Although it could also put the copter into SIMPLE mode if the yaw control was lost for more than 1 second to allow direction control during landing.
There is so much in the code it is hard to get my head around it all so I may be making it sound simpler than it is.
I'm looking at the yaw control aspect of this, and probably the pitch and roll later as I'll be building an Octo with the idea of having redundancy to land while carrying a camera.
You are right that the yaw control can kill the ability of the pitch and roll stabilizers to do their job. This is made worse by my recent yaw fixes, and was identified by Jason. I intend to fix this shortly.
But a further rationalization of the way these are all handled is required.
I made some more tests now by increasing he stabilizeP-Imax to the max value that the planner would allow, but the behaviour did not really change at all.
It seemed as if the motor commands would be saturated by the controllers. I havent yet digged through the code to confirm this but it would strongly seem like there is a hard limit on how high the controller can set the command values.
This is ofcourse logical since the ESC:s only accept limited commands, but it might make it possible for the atitude controller to override the yaw controller if the values would be normalized so that the values would not saturate, and going over the limit on some motor would start decreasing the power on other motors. Easiest solution to this would be to consider motor commands to be between 0..1, and if there is a value that is over 1, say 1.2, then everything would be divided by 1.2, this way the highest value would be 1.2/1.2, making that 1, and everything else would decrease. Ofcourse this is not the most elegant method to implement but illustrates the principle.
Now the downside on this aproach is ofcourse that the highest Imax (or if there is a high gain) will over-ride everything, even altitude, so the copter might start dropping altitude to hold level. On my opinion, this is not a bad feature since in case there is not enough lift, I would like the copter to hold level first and then drop to the ground landing gear first, instead of rotating around randomly and crashing into the ground with accelerating speed.
Have you noticed any differences in the ability to be redundant with the different Hexacopter styles? I would be curious to know how a flat hexa handled vs. a Y6 hexa for example.
I have atleast been told that theoretically, hexacopter shaped like a ship should be able to "survive" loss of any two motors, which circular hexa is not capable of. I am still trying to find if the swiss team has actually published the proof somewhere.
Shaped like a ship?
I believe they had made the proof for that specific copter model.
I am acutely interested in just this area of multicopter research. While I leave the coding up to the developers, and the priorities for the APM direction up to the community, I have developed a few opinions on the subject.
There has been very little discussion of in-flight (or otherwise) failure detection and mitigation in the APM code itself. Most of the community seems to focus on autonomy feature set (navigation, waypoint attainment, etc.). I'm not saying this is inappropriate, it just is what it is. Whether or not there is really enough computing "horsepower" in the current or immediate Arduino platform roadmap to do all of the robotic things and include fault event mitigation is a question. There has been some discussion of "clustering" the APM itself, but frankly, it is rather rare to hear of an APM outright failing versus other components.
The most common catastrophic in-flight anomaly seems to be propeller failure. It is also the most preventable. If your no-load cell voltage (4.2 X "S" number) multiplied by your motor KV yields an RPM greater than your propeller manufacturer's maximum rating, you are begging for trouble. If your propeller otherwise fails without striking an object, then that manufacturer deserves to be considered for a boycott until their QC problems are resolved. Everyone balances their own props, right? Regardless of who you buy from, there is no substitute for verifying the balance of every prop. It's worth it just in the reduction of vibration your APM sensors will have to filter out. It also allows you to somewhat tell if a prop has a hidden manufacturing defect, like an air bubble. If the prop is really out of balance, return it or toss it. If you don't exceed maximum ratings, you verify the balance yourself, and you don't re-use props that have struck something, then they shouldn't fail. Ever.
Without some sort of daemon service polling appropriate sensors to detect the operating status of each thrust unit (motor, esc, and propeller combination), there's no way for the APM to know if an unrequested attitude change is due to air turbulence or a component failure. It seems possible that the APM could infer such a fault mode by some persistent error condition algorithm, but that's all more processing overhead somewhere.
When there is a fault in an electric multicopter thrust unit, I agree with Mr. Lefebvre that yaw control goes to the absolute bottom of the list of priorities. When you crash, it doesn't much matter in which direction the craft is pointing. The idea is to stabilize the pitch and roll attitudes well enough for a safe, controlled descent to the nearest unobstructed landing area, or at least to ditch the ship with the least amount of collateral damage.
As far as the "box" geometry being better for aerodynamic fault tolerance than a circular design, I can only guess that if this is true, it is due to the average distance from the center of mass to the potentially failed thruster. The farther away from the CoM a thruster is, the more leverage it adds or subtracts from the total attitude control authority. I'd like to see what testing methodology the box makers used to make this claim (although I design to a box-like grid pattern myself).
Brad, excellent post, but there are a few issues:
Most of us are using props which do not have RPM ratings. They are cheap pieces of junk of unknown origin, unknown quality, and often unknown manufacturer! Yeah, it's a bit scary. But that's not even the worst problem! Balancing? I haven't bothered to balance because I can't even center the darn things on the spindle, so what is the point? My shaft is 4.5mm diameter, supposedly the equivalent 3/16" diameter, I guess. But not really as that would be 4.76mm. Then, these crappy props don't come with something sensible as a 3/16" bore, or even 1/8" with the intent the user will ream it out to size. No, it comes with a 1/4" bore, and "Adaptor rings". Yes, another tollerance stackup. And, they don't even include a 4.7mm ring. Nope, 5.2, or 4.0. I would install the 4.0 and ream it out, which adds to the cheeziness of everything, but the reamer just spins the adaptor in the bore!
This whole situation is terribly broken, and is another example of how the multi-rotor industry is not mature yet.
Now, a big part of this is the fact that I am using cheap props in the first place. In the 10" size on my little quad, I don't have much choice. On my Octo, 13", I do have a few choices. But for now I chose cheap props until I can at least get it past the "flip on takeoff" stage.
As far as fault detection, I would think that it would be smart to implement something like, if the user is in a manual flight mode, and a unit fails, put yaw low on the priority list, but also switch automatically to simple mode. At least give them a fighting chance.
The difficulty is the fault detection. It's one thing if a motor or ESC fails. But I'm worried what happens if a prop breaks. Vibration would go through the roof, and make it very difficult for the flight controller to function.
do i2c based ESC's make failure detection any easier?
They should, I would think. I don't know really, but I'm assuming we're talking about 2-way communication here. The key is the 2-way.