There’s no need to segregate the gyros like that. You could have 3 gyros feeding data to 3 different estimators.
Yes and No.
The input shaper is still an acceleration limit only on the input but we also use it to limit the approach acceleration after disturbance as the error is closed. So for example if you got a sudden gust from the side that moved the yaw by 10 degrees. The rate loop would respond without constraint to fight it. The Attitude error would build causing an unconstrained (in terms of acceleration) response. But when the gust disappeared and the aircraft moves back 10 degrees. As it approaches zero error the acceleration will be limited. So this will only reduce the chance of overshoot.
Now, as the error increases when the gust first hits. While the Rate PID is not affected the Attitude error builds a little slower once the error grows larger than a particular threshold. So with a large angle error the aircraft doesn’t fight as hard through the FF as it would do without the acceleration limit.
None of this should cause overshoot, it should only reduce it.
Weather or not there is another problem here, this is a big issue. Has anybody measured the thrust curve vs servo position? I have done a lot of linearisation work and in the code and it makes a massive improvement to the PID performance. This is definatly something we should measure!!!
The other thing this may be is the Yaw FF term is too large for that copter. It would result in exactly the response you describe. Easy thing to try…
I agree completely. There has been no engineering or technical justification for removing it. And as I said:[quote=“Leonardthall, post:78, topic:18281”]
I would not advocate doing this unless we can establish the leaky I is not needed or we have a better solution.
[/quote]
This is why I am advocating focusing on the take off portion and dealing with the landing portion later.
We are only talking about locking the I term to zero when the aircraft is armed and releasing it at some stage just before or after takeoff. So there is no[quote=“Rob_Lefebvre, post:90, topic:18281”]
The servos jumping like that doesn’t seem right. And it if happened in flight, due to false ground detection or something, would be pretty bad.
[/quote]
So at no point does this cause the servo to jump in flight. You will see a jump as you arm and never again. And I completely agree, we should never have a change in state cause a twitch in the servos, much less a jump.
I strongly suggest that we do both. I would request that anybody using the leaky I term keep using it when testing the zero I term on startup stuff.
In flight design and decisions come later.
Sorry I can’t get through the rest right now. I will have to do it tonight.
I have tried increasing the FF, and reducing it to zero, and nothing seems to help. I had wondered if the FF being too high, was meaning the tail was being pushed faster than intended, so was being resisted by the Yaw I-term, which then had to bleed off, causing a bounce. But no, doesn’t appear so.
No, not measured it yet, don’t have a thrust testing rig. Well, not one that can get a variable pitch mechanism. Would have to rig something up.
But, it’s very easy to understand. And can even be modeled to some degree with the Momentum Theory.
As you know, thrust is created by accelerating a column of air. The thrust is determined by the change in momentum of the air, which is determined by the mass of air being moved, and velocity. Now, in a steady state hover, there is a torque which the tail rotor must resist. This results in a column of air of X velocity. Now, in order to increase the thrust, it must increase the velocity by increasing blade pitch. However, a 50% increase in velocity, does not give a 50% increase in thrust. The thrust only increases with the… don’t have my notes at home, I think it’s roughly the square root of velocity.
Conversely, if you want to yaw the other way, the direction which requires a reduction in anti-torque thrust, you would be reducing the thrust. And the inverse holds true. A 50% reduction in velocity, does not equate to a 50% reduction in thrust.
Will have to work on this.
I have not done this directly but I think there are two ways you could tackle this. One would be to back out the tail rotor thrust from the power that the engine is producing. You could account for yaw accelerations since thay are measured as well. It would be best to have the pixhawk collect all the data. The only thing it doesn’t get directly is the motor current and voltage. So that may be a little more challenging. The other way to do this is using system identification techniques. We could do frequency sweeps in the yaw axis and then determine the transfer function. @Leonardthall would that be good enough We could take it one step further and determine a state space model. The main thing we would have to do is record the servo out signal and the rates at 50hz.
Can we get those values from power module(s) such as Mauch? Or it’s not accurate enough?
That’s interesting. I had sort of the same problem with my 600 electric. It took a couple days fiddling with it to get it perfect. I shortened the throw on the servo arm so I am using full travel on the servo. And it’s the same tail as my 700, same servo, and I brought the settings for that into the 600 but it was not quite right and still kept rebounding on over-shoot.
What finally really smoothed it out was setting the LPF to 25 Hz. I tried 4, 10, 12, 15, 20. Still had the bouncing no matter what I set the PID’s to. On a whim I tried 22 and it got better. So I figured more must be better and set it at 25. That did the trick.
The servo is a Futaba 9254.
This is what I ended up with.
ATC_ACCEL_Y_MAX , 20000
ATC_ANG_YAW_P , 3.5
ATC_RAT_YAW_D , 0.004
ATC_RAT_YAW_FILT , 25
ATC_RAT_YAW_I , 0.28
ATC_RAT_YAW_ILMI , 0
ATC_RAT_YAW_IMAX , 0.3
ATC_RAT_YAW_P , 0.3
ATC_RAT_YAW_VFF , 0
first off, I perfectly understand very well why you guys don’t like the FBL approach and that tridge might not have done it for the reasons I’ve implied, but that’s my honest opinion, that you’re not going to compete with their acro capababilities. And, Rob, the argument that you can do something with ArduPilot which you can’t do with a high-priced alternative system is really a fallacy, it really doesn’t prove anything about what ArduPilot+FBL could do. Also the gimbal controller argument is a fallacy, I think there is no doubt that DJI gimbals are overall just better than whatever open source alternative, or Solo gimbal. The open source gimbal controller situation in fact proves exactly the opposite of what you wanted to proof (and this so also if you include free gimbal controllers ;)). Interestingly, in the responses I could not see any argument except of the sort “I don’t like it”. I presented my opinion, and I think I have arguments for it beyond “I don’t like it”, and I have not seen any convincing counter argument. Anyway, here you are right, you all are free to do what you have fun with. (topic closed)
Leonard, well, honestly, I am not surprised to hear that type of response, but it is really inappropriate. You make a number of claims for which you have absolutely no evidence for. The fact is this, and if you would bother to go through those old (mostly German) sources you would find that confirmed, the alternative GA250 gyro firmeware yielded a flight characteristic en par with other gyros and FBLs, and some of the testers (few, admittedly) really had heli flying capabilities way above what I guess most if not all of us can do. Also, theoretically they don’t have a basis. In plain words, for instance, this statement “Gives the pilot an unsettled feeling and is both sloppy and over aggressive at the same time.” is nonsense. I’m sorry to be frank here, but this is what it is. My heli flying capabilities had never been excellent compared to what these crazy 3D guys can do, but it was definitely advanced enough to allow a own judgment here.
Btw, the heli tail is indeed very non-linear, obviously. However, that’s why nearly all gyros/FBLs (at least at that time) had left/right, CW/CCW, etc. parameters. Also, these tails usually can be made, by proper installation, less non-linear (a point missed by many at that time), you find one possible recipe in the pdf l’ve linked too. The point is, a “simple” linearization scheme is useful, but there is no need for “rocket science”.
[quote=“Leonardthall, post:82, topic:18281, full:true”]To get really nice feel you need acceleration and jerk limited input shaping and a tight tune. That was when it started to all make sense and feel good.[/quote]LOL. That’s not what is reported.
Anyway. I guess I have said what I think I could contribute.
Have fun,
Olli
[quote=“Rob_Lefebvre, post:44, topic:18281, full:true”]
All of this being said… and this is a bombshell… But more and more I believe the current StabP->RatePID+FF controller structure is just not right. At all. Needs a total tear up.
I’ve long observed that, the most sharply tuned Ardupilot heli, is not as sharp as a hobby FBL controller. It’s good enough to get the job done for UAV use for sure. But it’s not nearly as performant as an FBL. This is very apparent in yaw. …
However, lately I have been playing with the RealFlight/FlightAxis simulator. And I can fly the same heli back to back with a “hobby FBL” and Ardupilot. The same underperformance is visible. Again, particularly in yaw. The Ardupilot control is so, so soft. Even when tuned to the point of oscillation.
…
Something is not right.
Again, it’s plenty good for UAV use. But I wonder how much better they would be with better control.[/quote]
[quote=“Rob_Lefebvre, post:91, topic:18281, full:true”]
The fact is, there’s nothing wrong with Pixhawk/Arducopter that makes it require an external FBL.[/quote]
Excuse me! We went through all those same basic ideas you went through, about the same time you were going through them, while working on the multi rotor control code. I have clearly demonstrated the advantage of the jerk and acceleration limited approach. You can look at this yourself by turning on and off jerk limiting and acceleration limiting in a copter and feeling the difference in a single flight. We did not stop at the simple solutions you suggested because they did not achieve the performance standard we set ourselves.
And when I say we, Rob was a critical contributor to the work we did when we left the simplistic approaches you described behind.
Over aggressive because the lack of jerk limiting through the system causes the target to get ahead of the desired attitude as you leave off.This results in a jerk (surprise surprise) and wobble as you initiate the rotation. Sloppy because as you stop the rotation you get another disturbance as you restart attitude control leading to a sloppy and imprecise control. A 3D pilot may not care about these issues as a jerky start and a notchy stop probably works well with the types of maneuvers they are doing. Quite frankly, your assumption that a 3D pilot is the authority on control and feel demonstrates the narrow performance scope you were trying to address.
You have been frank so I will be too. I can see you have done a lot of work. I can see what you have done because I went through that learning process myself. However, these ideas are obvious and all have problems that compromise their performance. We have progressed pasted these ideas and found better solutions that do not have the clear performance issues of the techniques you suggested.
Olli, it is you that is making inappropriate comments. But I do I agree, you have contributed as much as you are capable.
Leonard, well, honestly, I am not surprised to hear that type of response, but it is really inappropriate. You make a number of claims for which you have absolutely no evidence for. The fact is this, and if you would bother to go through those old (mostly German) sources you would find that confirmed …
Olliw42
Deutschland, Deutschland ueber alles, ueber alles in der Welt …
Ich dachte, das ist lange vorbei!!!
I think the power module information would be accurate enough if it was just for the motor power but unfortunately it includes powering the servos as well. It might work if you power of the servers from another source say an extra battery and then run the motor only off of the power module. The only thing with that approach is that the power used to power the pixhawk would still be included in those numbers. The other thing I found in doing a performance test with a multi-copter was that log data for current was to the nearest integer and we would need to change that to provide some more precision.
I’m actually building a heli up now that will have separate power monitoring on the main and tail rotors.
Only problem is, power doesn’t directly give you thrust. That’s also non-linear. Especially once the tail blades go into stall and just start windmilling. This can DEFINITELY happen when running reduced rotor RPM and standard 30-45° blade pitch.
Can’t we just turn a heli on it’s side with a pivot point under the body and a set of scales being used to prop the tail up with a stick?
But in the steady state, power can be used to determine torque that the tail rotor is using to hold the nose steady and from that we can get thrust
I would prefer to rig up something proper. Never had the time and resources to do it. Might be able to soon.
One only needs to look at the terrible yaw jerkiness of any DJI machine to see an example of how bad the standard/simple PID model is. I can’t believe they still haven’t moved past this.
Yeah, long ago I tried rigging up strain gauges on the tail boom but I just didn’t have the electrical engineering/instrumentation expertise to complete the project. I really think that if you truly want to know response and to capture the impact of dynamics on the ability to control the tail, you want to look at the transfer function.
The power required for avionics is pretty trivial compared to the power used on something like an 800 size heli. I’m seeing steady state around 1-2A on the ground. But then 55-60 in hover. Well… OK, so assuming 10% power goes to the tail rotor, 5.8 would be on the tail, so… I guess the 1-2A would be significant. Huh.
Well, the system I am building, the BEC in the tail motor ESC is only powering the Pixhawk itself, so has a fairly constant, low power draw. The BEC in the main ESC is powering the servos.
Leonard, why did you delete your post? It’s interesting.
In a standard tail rotor the steady state rate is proportional to RPM and Pitch (with some loss). The force is proportional to the pitch^2 and rpm^2 (with some loss)!!!
Yes, I have noticed the same thing. You might see that, I think in AC3.3, there is a term in the PID logging for “AFF”. I added this as I was working on this concept of “Acceleration Feedforward”. We already have Velocity FeedForward (should be angular rate to be clear, but whatever.)
But I also noticed exactly what you just said. In steady state, the propeller is acting as an air screw, and the rate is fairly closely related to the blade pitch and rpm. However, whenever the blades suddenly move, and the “pitch speed” of the propeller no longer matches the existing rate, you get a force.
So what I was playing with, was the concept of taking the derivative of the Commanded Angular Rate Feedforward signal, to get the Commanded Rate Acceleration Feedforward. Then I had another PID term called AFF.
I never finished the work. And the AFF logging term got accidentally added to Master. I think Tridge has removed it now. (which is fine, should never have gone into Master).
You bring up a good point about the power draw of the tail. That would have to be subtracted from the equation. So for the case where you have a separate motor on the tail, that would cure this issue. Then have the power module only hooked to the ESC powering the main rotor motor and power the servos some other way. I think the draw of the pixhawk alone would be negligible and acceptable for this. I would think the pixhawk power draw would be fairly constant and you could just subtract it off.
I am in favor of the system ID approach though.