I'm moving from my flybarless TREX 45 to a Raptor 90 SE with a flybar soon.
I heard that control for roll and pitch is rate based, and we have full acro control, but does stabilize mode also work?
Also, are there any general rules to consider when setting new PID's for yaw? Do the constants generally go up or down? I'll start it from scratch on a test bench, obviously, but the test bench can't handle everything, so if anyone has any pro tips, I'd owe you one.
Hey Chris, wondering if you have any input on this:
As you may know, I've been experimenting with flying waypoint missions at high speed with my helicopter, and have run into a problem. A big part of that problem is that the existing Alt_Hold code doesn't work as well as I would like. So some of that may go away with the improved accel-based alt-hold that Randy and Leonard are working on. But still, there's this issue where at high speeds, the altitude control of the helicopter is more strongly influenced by the "elevator" control than it is by the throttle. The elevator has the ability to completely dominate the Z-rate beyond anything the collective pitch could do. At the same time, beyond a certain speed, continuing to pitch the helicopter forward won't result in more forward speed. Well... it will, but only up to the point that the alt_hold controller runs out of collective pitch and eventually the ground gets in the way. ;)
The issue with altitude being affected by forward airspeed is actually completely different than what happens with airplanes, aerodynamically.
All of the movement of a heli in three space is produced by the thrust from the rotors. To generate forward airspeed, the heli pitches forward, and the forward thrust becomes the dot product of the angle of the pitch to the ground. Basically, the more you pitch forward, the more forward thrust you produce, all the way until 90 degrees, when all of your thrust is being applied in the forward direction.
But as you point out, when you go that far, the ground gets in the way because you've taken all of the available thrust away for counteracting gravity.
The reason pitch plays such a prominent role in fast forward flight actually has nothing to do with aerodynamic changes in the properties of the heli. It's actually caused because the amount of thrust you're commanding from the rotors to generate both forward acceleration and upwards acceleration (against gravity) is far more than you use to maintain a hover.
So when you pull the stick back after you've reached your cruising speed, you're still applying the same thrust, but because all of it is now being vectored straight up, instead of being split between the two, the helicopter will accelerate upwards.
As I understand it, ArduCopter already applies additional collective pitch to compensate for when the heli pitches or rolls, in order to maintain altitude. If it doesn't, it should. The only challenge in our application is that to properly maintain altitude, you have to have a closed-loop model based on knowing the relationship between changing the collective pitch, and the change in thrust that's generated.
Obviously, this varies wildly between applications, so getting an accurate representation would be difficult.
But the bigger problem is the fact that we're running out of variable space in the current application. I'm already limited in applying fuzzy logic because there's not enough room on the parameters list to store the fifty or more variables that we need access to in order to have complete control over the behavior of the fuzzy membership functions. Implementing even more layers of control means having the need to be able to control WAY more variables using MavLink.
And for that, we need to get the ARM-based stuff ported over first. Once ARM is implemented, we can do anything and everything we want. I could put every controller constant in the system on a fuzzy network, and have any controller constant be changed based on forward speed, head speed, or any other variable that we can measure with our sensors.
It's exactly what fuzzy logic was made for.
No, I disagree.
What you are talking about is basically a "simple thruster in vacuum" model, and that is very much how Arducopter currently works. It is sufficiently accurate at low speeds. But it is not an accurate model of the aerodynamics of a helicopter at high speeds.
The actual model as understood at high accademic levels is very very complicated (beyond me anyway). But to attempt to simplify: At high speeds, the rotor of a helicopter acts more like the wing of an airplane. It generates lift based on the angle of attack of the wind hitting the disk.
To put it in practical terms, my helicopter can generate 1-2G of acceleration upwards from hover. However, if I'm flying at 70+ km/h, no amount of collective pitch can maintain altitude if I'm in a 20 degree dive.
I've done this where I'm flying at 70+ km/h, and diving at about a 20 degree angle. I apply full up collective, and almost nothing happens. But if I pull back on the elevator even a little bit causes the heli to skyrocket. Just like an airplane, trading kinetic energy for height.
Another practical example of how the simple thruster model is not accurate for a helicopter, is the fact that it takes *less* power to fly at 50 km/h than it does at hover, even though some amount of the power is being directly forward instead of downwards.
I'm not sure how much fast forward flight you've done, but a helicopter feels much more like an airplane at speed than it does a multi-rotor.
Yes, Arducopter attempts to vary the collective pitch as the helicopter pitches. But it doesn't work at speed. If I use a waypoint target speed of 15 m/s, what happens is that the heli climbs and falls based on how the speed controller is pitching it to attempt to maintain speed. It does exactly as described in the graphic. If it pulls back on the cyclic, or even rolls it to turn, the helicopter rises. This is seen by the alt_hold controller which starts cutting back on power. The result of both of these, trading speed for height, and cutting back on power, results in the heli slowing to about 10 m/s, so the speed controller pitches it forward again. The heli starts falling, and the alt_hold controller can't stop if from falling before it hits the ground.
Now, some of this will be improved with the new Alt-Hold controller, I expect I might be able to fly at 15m/s, but I don't know past that. At that speed, the speed controller cannot simply pitch it at the ground and expect collective to save it.
All of this might be able to be fixed in a crude way by simply having an observer which looks at the results of the Alt_hold controller, and if it's saturated, then it will start constraining output of the speed/attitude controller. But I don't think it's the ultimate solution to the problem.
Or I guess to put it more succinctly: The simple thruster model does not explain why, if I'm flying forward at 70 km/h, with a collective pitch setting that maintains altitude (ie: it's flying at steady state), then I input a control change which *only* changes the pitch while maintaining collective setting, I can produce a downward acceleration of more than 1G.
Ah ok I see what you're saying. To answer your question, yes, a fuzzy controller can be used to modify the way the controllers react to error based on anything in the system that we can measure.
We could modify controller constants and responses based on airspeed, but at least my current rig doesn't have an air speed sensor, so the best thing we could do is just use ground speed, or implement air speed sensors if we need to get rid of the slop.
Yes, lack of measured airspeed is a problem. Ground speed is the best we have at the moment. The problem is the airspeed would need to be airspeed and wind direction. And getting that would probably be difficult on a helicopter due to the large rotor we're under. I would think you'd need a stinger going far forward.
Chris, have a look at this:
The horizontal flight stuff starts on page 22. I'm just reading through it myself.
That's excellent! Once we move to ARM, we will have the horsepower to implement everything in that book.
What we'll do is, when we have a non-linearity in the system based on an external variable, we can pick five points on the graph, and linearize around those points. Then, we can assign those linearizations to their own fuzzy membership functions, and tie the FLC into the system to change any control constants, mixing the values based on which regions we're operating between.
The drawback is, this type of controller is going to be extremely picky about getting system parameters correct. To do this right, we would have to directly model all of the necessary physical characteristics of each heli this was implemented on. Again, for every nonlinear response we introduce, the model has to be tuned for it.
Fuzzy Logic is MUCH easier to tune, so long as the user understands these non-linearities and tunes for one at a time, but not all of our users will be aerospace engineers.
The next step in this cycle to solve that problem would be to create some sort of automatic test bench, where after initial tuning and implementation of the existing linear controller is performed by the user to get a relatively stable setup, the APM can initiate an automatic test protocol that runs a set of waypoints and maneuvers, then evaluates the performance of the controller based on the criteria described in the book. At that point, the computer could choose values to optimize the system, test them, and use a neural network to repeat the process and find an optimal set of parameters.
Obviously, the neural network would be implemented in the GCS. We were doing some research on implementing it in CUDA, using the parallel processing power of high-end video cards to run it more quickly, but it fell through when our CUDA programmer flaked out on us.