Pitt,
I would love to help you but I’m not sure that I have the time. It would be easier for me to probably work in AC 3.3.3 since that is what I modified for my X-3. Do you have a github repository that you are working from? That would be best if you want me to see what you’ve changed and I can make recommendations. Plus it would be easier for me to work on it when I have time.
Nice animation!!
I don’t have much time either.
So feel free to dig this thread up whenever you’re free.
Let me study git a little more, got confused with terminology.
Update on what I found
is not based on AC 3.3 or at least it no longer is.
Left: AP_State.cpp from AC 3.3
Middle: AP_State.cpp from AC 3.4
Right: AP_State.cpp from PR
notice some differences.
You may be right that this “was” based on 3.3
But
From http://ardupilot.org/dev/docs/where-to-get-the-code.html
"Rebase-based workflow: keeping your code up to date
As you develop, the (original) master branch of the ArduPilot repository is likely to be updated, and you should keep your fork and your local branches up to date. Rebasing allows you to re-apply your changes on top of the latest version of the original repo, making it much easier for the project to merge them."
Question is: Which version I should start with then?
I would suggest that you start with a released version close to when the pull request was last updated. So stick with a released version like 3.4.4. My concern with starting with 3.5 is that the developers changed how the frames are compiled. Since the pull request was last updated for 3.4, I would suggest sticking with a 3.4 derivative version.
Since cherry-pick command doesn’t work, I modified the 3.4.5 code manually and put it here:
https://github.com/Block137/Dual1
Now I can’t compile it.
I got problems with submodules.
“git submodule update --init --recursive” always returns some kind of error like
*** [CHECK_MODULES ] Error 1
fatal: Needed a single revision
fatal: clone of ‘git://github.com/ArduPilot/waf.git’ into submodule path ‘…/ardupilot/modules/waf’ failed
github.com[1: 192.30.253.113]: errno=Invalid argument
Failed to clone ‘modules/PX4NuttX’ a second time, aborting
I get this problem too. Run “make px4-v2” and this should cause it to load all of the necessary submodules. Run it again if it fails the first time. Hopefully it will start building the code at that point once it’s loaded all the sub modules.
Messed up modules…
Deleted old repo and made a new one here: https://github.com/Block137/Dual2
Compiled successfully
Will give it a try tomorrow
Uploaded ok.
Everything is ok except…drunk mixer is back. And I ran out of idea of possible cause.
Log and vid ready.
1 24-2-2017 7-30-10 AM.bin (2.6 MB)
Update:
Did few more tests, here is what I found.
-This symptom doesn’t appear when H_SV_MAN = 1
-It still appears when *H_YAW_SCALER =0 (new parameter)
*When H_YAW_SCALER = 0, the heli can’t yaw. Servos won’t move when yaw command is given.
But pitch/roll still get messed up when I move rudder stick.
Pitt,
I looked at the parameters that were embedded in your log. I think what your are seeing is the lag associated with having a large I term. If you want to do a control check, it is probably best to zero all the PID gain values in pitch roll and yaw and just have FF terms at 0.05 or some value that gives a reasonable response. You can check the control response with the rotors static to make sure it agrees with what you’d expect. Then when you go fly, you will have to tune the PID values. Based on your last flights with the previous firmware, you could start with a low P value that you know was safe so you have some stabilization. Lastly, I would suggest making RC1_DZ, RC2_DZ, RC3_DZ, and RC4_DZ equal 5. The deadzone that is set now will make the aircraft feel very lagged and unpredictable especially when performing precise tasks that required small inputs like landing. Also set ATC_HOVR_ROL_TRM = 0. This parameter is designed to put in a roll angle in stabilize mode to offset the lateral translation due to the thrust of the tail rotor, which you don’t have. Hope this helps!
Looks like I’ve got a big problem now.
Zeroing PIDs and ROL_TRIM doesn’t help.
When PIDs are all 0, swash returns to level even if I’m still holding the stick.
In Acro mode, swash tilt around while holding rudder stick.
Are these normal?
Just wanna make sure it is not using multirotor algorithm.
Ok. Let’s take this one step at a time. I’m fairly confident that your dual frame compiled correctly. The frame type is HELI_DUAL plus you have the first 6 RC_OUT channels working. The tag associated with your log file (9a23aba) is different from the tag on your last commit in your Repository (1c15aeb). Did you make any other changes that you committed locally but did not push to github.com? I’m not as concerned with that but they should match. So that looks all positive.
Before you start this next check set YAW_EXPO = 0 to remove the compensation for control reversal near zero collective.
Now as for the movements of the swashplates. Lets go back to basics. Are you confident that you setup servos for both swashplate correctly. If so then verify with flight mode set to ACRO:
Once think you have it or if you get stuck, take a video as you do this check. Remember, one control at a time. I think the YAW_EXPO is the issue for your last check.
About commit tag, I fixed a few silly mistakes using amend-last-commit so it can’t be pushed. But I applied same fixes on remote but with separate commits.
Servo POS and REV have been set before the video.
When giving 1 control (Ele/Ail/Pit/Rud) at a time it works perfectly. Problem only occurs when I hold rudder away from center and give full cyclic command (full yaw + full roll for example) in any direction.
As for yaw expo, a value of 0 only results in 0 total yaw term, same as 0 yaw scaler (both are multiplied to yaw_out). Cyclics still go drunk when I hold rudder stick at corner.
The fact that you are getting proper behavior with reasonable inputs is a good thing. I’m not familiar with what the control laws do when you are near or on the limits. Make sure you understand the yaw_expo feature. I think It is set for mid collective and lower to account for control reversal. Sounds like that means mid collective would be 0 deg pitch on the blades. I typically set my mid collective up for blade pitch at hover. Since you actually flew this control law design, whatever you did before must have worked ok.
I added yaw reverser myself
What it does is simply multiply the yaw term by a value between -1 and 1, yaw_expo controls how quick it changes between +and- near 0deg collective.
I will try Trad Heli firmware and see if its same.
Edit: some visual aid
https://alliance.seas.upenn.edu/~cis520/dynamic/2014/wiki/index.php?n=Lectures.Logistic
X axis = collective out
A number in front of x is yaw expo.
So control reversal doesn’t occur unless you get into a negative g condition (i.e rotor producing negative thrust) which is not proportional to collective. You can be in 1 g flight in an autorotation and be holding - 2 deg of collective. In your mixer you would actually cause the aircraft to respond either very little or reverse control sense in the directional axis. Typically in manned aircraft of this configuration, they would limit the aircraft from going into a negative g condition to keep from encountering this control reversal.
Let me clarify one thing. What I’ve stated above applies to the directional control scheme of differential cyclic pitch which I believe is what you currently are using for directional control. If you used differential collective pitch for directional control, then this approach would be more applicable.
I’m not sure how this thing works during autorotation but from my understanding, the heli lose yaw control when motor stops and is not uncommon, my Warp360 doesn’t have freewheeling tail rotor for example.
So, disabling yaw during autorotation will be an easy way to go. Unless I get a power failure I’m not doing autorotation anyway.
I was using differential collective but it induced the a very strong lateral motion (so strong that compensation messed things up) so I will be trying differential cyclic (not yet tested).
I’ve been thinking about adding another reverser when throttle is low (autorotating) just in case.
The advantage to using differential cyclic for yaw is that YOU WILL have directional control in an autorotation. The reason RC helicopters with a tailrotor don’t have directional control when the engine stops is typically because they aren’t backdriven by the main rotor. There are some RC helicopter designs that have the tailrotor connected to the main rotor so that when the engine stops the tailrotor continues to spin. I would recommend getting rid of the yaw_expo feature because it limits your yaw control in low collective situations (descent or autorotational descent) and do you really think you’ll be doing inverted maneuvers. I think differential longitudinal cyclic for yaw control is the way to go with this design.
Honestly I really do think about inverted flight lol (who won’t?). Just think how cool it is going to be…IF it could survive perfect condition for blade strike.
By getting rid of yaw_expo do you mean to disable reverser?
Disabling exponential only will results in a nasty behavior when collective is right at 0deg.
Edit: added a simple logic to disable reverser by entering 0 or negative yaw_expo.
Also fixed different commit tags.
Yes. I wanted you to disable the reverser. Or if you do plan on flying inverted, I would make it a function of vertical acceleration and collective instead of just collective. In my opinion, I don’t think you’ll see this nasty behavior at 0° collective with this control scheme for yaw axis.
Disabled reverser.
Doesn’t fix the problem so I made a closer observation.
What is does is really change the phase angle
CCW yaw + nose down = Left roll
CW yaw + right roll = nose up
However this strange movement doesn’t look large enough to cause a crash, let alone noticeable.
So I’ll give it a test once I’m done with exam.
Do you want me to try that filter again?
Please list all critical parameters and values as I reset all parameters to default with this firmware.
