One thing that I like about this forum is the way everyone shares information, on other forum I'm a lot more skeptical that people are always trying to talk me into or out of a particular product based on their own biases and not from any actual data and there seems to be far less of that sort of thing here. I hope it stays that way...
You and Owen kind of mention the same thing that there are more important things to consider than just the refresh rate, would you mind explaining what some of those things are in a
way that a layman would understand?
Ok, I'll try, but it'll be hard to make it not sound like an advertisement for Arducopter.
It's also pretty hard to answer this in a simple way, without getting into specifics.
Obviously, the #1 thing is reliability. If the damn thing causes crashes, or you just don't feel confident using it because of crashes others are having, then what good is it? Unfortunately, very few controllers are perfect. We're not, and I wouldn't pretend to say we are.
So failing that, as most do, you're left with the question "what happens when something does go wrong"? And here's where you get drastic differences between controllers in this class. Does it do datalogging? I would never fly anything without datalogging. Period. Then, can you effectively review the datalogs yourself? If you can't find the problem, can you have a discussion with people who REALLY know the system? Can they answer all your questions? Or do they get stuck pretty quickly and stop responding?
At the end of the day, after you have a crash, or you see somebody else with a crash, do you have confidence that the problem really wasn't caused by the flight controller? In my experience, most crashes are caused by external factors, but I can usually show this in a convincing way, and the users are satisfied. I often can say things like "Looks like your rear right motor failed in flight, you can see that here:". A common response is "Gee, I went and checked, and yes I found the motor bell is slipping on the shaft, thanks!"
Then what happens if the flight controller has a problem? Can you talk to the software engineers? Can they show you the error? If they can't show you the error, can you be confident that they really found it? Or, once you are certain that the controller had an error, do they just shut up and you don't hear from them again? Maybe they release a new firmware several months later, with no mention of the issue, and you can never be certain if they found the problem or not?
I personally talked with the ex-employee of one company (who shall remain nameless). He confirmed that company policy was "You never admit the system has an error. Ever." I don't know how anybody could ever have confidence in a system like that.
Let's be frank. These systems are extremely complex. But they're being offered at a price that does not allow for rigorous military-grade reliability testing. Stuff happens. It's what happens after the crash, that determines if the system is trustworthy or not. Are the people writing the software open, honest, transparent, competent, etc?
This also relates to how they talk to you about features. Do they blow smoke up your butt with physically impossible things, such as passing commands at 600Hz or 800Hz (as another one has in the past) when the laws of physics only allow for <500Hz? (on a 1000-2000 uS PWM signal) Does it sound like they are making things up as they go? Does everything they say seem to indicate they are trying to sell you something? Can you ask them *any* depth of question, and they answer in a clear, understandable way? Or does every answer seem to be "It's better and more expensive, because the knob goes up to 11." Do their answers seem to come from the engineering department, or the marketing department?
For example, this is why these fast refresh rates are impossible. A Pulse Width Modulate signal, means that the signal exists as a time-width pulse. It's just a square wave that turns on, and then off. With width of the on-time, is the strength of the signal. For 40+ years, the standard signal has had a width from 1000 microseconds, to 2000 microseconds. 1000 means effectively "zero". 2000 means "maximum". Now, 500 Hz, means 500 cycles per second, or 500 square waves per second in our case. 1 second, divided by 500 signals/second, means that every signal would take 0.002 seconds, or 2 milliseconds, or 2000 microseconds. This is why you can't run faster than 490Hz. 490Hz is 2040 microseconds. You're trying to push a square wave signal, that is up to 2000 uS long, and you need some "off time" between pulses, to mark the end of the signal. The signal can't just be on 100% of the time, that's not a signal, that's just DC voltage. 490Hz updates, means that you have a window of 2040 uS to fit your 1000-2000 uS signal. That means if you have 2000uS pulse-width, you have 40 uS to "mark" between pulses.
Hopefully I've now explained why this is impossible. Then you'd have to ask yourself, why would anybody market something as having a 600Hz update rate, when it's impossible for the flight controller to update the signal that fast?
This is the biggest stuff to me.
Now that that is out of the way...
You come down to features. Obviously the system has to do what you want, and at a price you can afford. Only you can determine that. You also have to consider if the system has more features than you need, and if this just leads to too much complexity for you. Some people only need a really basic system, and don't want to be confused by stuff they won't need.
And then you get into the nitty gritty of the flight experience. How well does it fly? Can you put it on a sporty machine and have fun? Can it also fly a camera ship nice and smooth and stable? If not, why not? When I see controllers with very low angular rate limits, or low angle limits, if it can't handle being upside-down... I wonder what they have going on inside there. You may not ever want your camera ship to go upside-down. But you have to ask why the flight controller can't handle it? Does the controller freak out if you turn it too fast? Why?
What happens if you lose a motor in flight, and the aircraft initially flips or spins before the controller can respond. If the flight controller freaks out soon as it's upside down, or turns too fast, can it still save the aircraft?
I take a dim view on controllers that have a 150 deg/sec rate limit, or 30 degree angle limit, etc. I just wonder what's going on inside there.
This is totally becoming an advertisement now, so I'm not sure I should continue...
I would love to go in-depth on a feature-by-feature basis, but it's almost impossible as I can't compare and contrast how different features work, because nobody has any inside information on these other systems. I could go on to talk about Earth-Frame to Body-Frame control rotations, etc. but we don't know if the other systems do this or not.