Pitt,
Sorry for the short response yesterday. I was a little rushed. You say you are a sophomore… In college? High School? I think the work you are doing for your age is very impressive. Especially coding up a new frame type and the CAD work you did for your gears. So the data you sent me was helpful however the log bitmask I asked for did not give me what I expected so I’m not sure what happened there. The one I use is 131071. So try that for future flights where you are sending me data. As for your flight, I was still able to see that your oscillations for your instability were at least 4 hz. I think they may be closer to 8 hz. So I would recommend for you to set ATC_RAT_PIT_FILT=4 and ATC_RAT_RLL_FILT=4. This may allow you to increase your P gains a little more before getting the oscillations. Also I saw that you had the D gain at 0.001. I think you should make that zero for now. It only takes a small amount of D gain to make the instability show up. You shouldn’t need the D gain if you are able to get the P gains higher. We can start working on the I gain after you get the P gain set.
Let me know how it goes.
Bill
https://www.dropbox.com/s/gxt99v4lnd94f81/2%201-1-2000%207-31-28%20AM.bin?dl=0
Bad news this time.
Things changed
-LOG_BITMASK to 131071 from 397310
-D gain to 0 from 0.001
-P gain back to knob tuning at 0.07
-RLL/PIT_FILT to 4 from 20
-Some aileron compensation for yaw movement << This caused its own problem
I got a self-amplifying-oscillation and wobble without any increase in P gain at all.
I hope the log captured that, It got dangerous so I landed fast.
So I tried moving param back one by one
1st: D gain back to 0.001, wobble got better
2nd: RLL/PIT_FILT back to 20, Flew stably again
P gain knob remained untouched.
College
Maybe because this is on Pixhawk 2.1?
Actually fhedberg did most of the code.
I’m basically stuck with this version, can’t update to newer firmware.
I’m sorry to hear about the bad oscillations with tre changes I suggests. That is very confusing. One thing I noticed when looking at your log file is the version of firmware you used for the basis of your changes was a development version for Copter-3.4. Typically I will checkout the branch for the released version. Since Copter3.3 was the basis for Fredrik’s code, you should have checked out Copter3.3 branch before merging his changes. I’m not saying that this is why you are having these issues but it does bring the firmware into question. Is your code up on github?
I won’t have time to look at your log until tonight.
I had no idea what was the version at that time. It just works.
IMO I got to this too fast, this is how I started:
- Picked up a PH2.1 without any experience with Ardupilot.
- Put it on a frame no one has worked on.
- Cloned fhedberg’s PR, add a few lines for different yaw method, and compiled right away…
(to be homest, software is my worst skill. Successfully compiled a .px4 file was a huge achievement)
So the code is what you see in that PR.
The 2 files I modified are posted somewhere in PR conversation because I don’t know how to use Git properly and not mess up someone else’s works.
That’s why I’m stuck with this version… 3.4.dev???
I’m surprised you were able to get it to compile. Did you checkout the Dual-Heli branch before you compiled? I’m not sure by cloning his repository that it would have checked out that particular branch.
Based on what you told me and some of the unexplained things with the log file and the aircraft behavior, I’m not sure that I’d continue to use that firmware.
Unfortunately I would suggest cloning the ardupilot repository, checkout the Copter-3.3 branch and merge fhedberg’s commits with that branch. You may want to compile the Copter-3.3 code before merging fhedberg’s commits only to baseline that you can compile the code with no issues. Now there may be another developer (not that I consider myself a developer) that can lead you through the git commands that would get you to that point.
It’s up to you on whether you want to continue. But the behavior you encountered with the changes I suggested is counter to what I would expect.
Pitt,
I think you can still move your code to a released version of Copter. There are a few steps to it and you will have to troubleshoot if you see some compile errors.
First you need to check out the last commit where the Copter 3.3.3 was released.
git checkout acf2e10
This moves the head to that point in the master. Now you need to make a new branch for all of your changes
git branch (new_branch_name)
where (new_branch_name) is the name of your new branch
Now you have to make sure you are on that branch
git checkout (new_branch_name)
Lastly you have to merge fhedberg’s commits for the Dual-heli
So you would use the cherry pick command
git cherry-pick (commit_hash)
where the (commit_hash) is a 7 character alpha-numeric. the first one in is dual heli commits is ffd625b
You will have to get the rest of the commits from his pull request
fhedberg commits for dual heli
Cherry pick them in the order of date in case some changes were made to earlier commits
The 7 character alpha-numeric is listed beside the commit on the right. After that do a “git status” to see that everything was committed. I think the cherry pick should commit them as well.
Then you will have to start compiling and fix compile errors if any occur. Good luck!
Hope this helps.
Following your instruction, I got "fatal: bad revision ‘6fbea5b’ " (6fbea5b is the oldest. Committed on May 31 2015) when using cherry-pick command.
When I tried to change files manually by looking at Files changed from PR, I found that some code lines that is being changed don’t exist in 3.3.3.
For example
“#if FRAME_CONFIG == HELI_FRAME”
Line 121(below “void Copter: :update_using_interlock()”) is changed to “#if FRAME_TYPE == HELICOPTER”
This line doesn’t exist in AP_State.cpp from 3.3.3.
Is there something to do with rebasing?
Pitt,
Sorry that what I suggested didn’t work. Unfortunately I’m not sure I can offer anymore advice on how to get the changes easily incorporated into a released version of Copter. You can continue with your current build but IMO I’m not sure it is behaving correctly.
Most likely I missed something.
If possible, can you try doing those and see if you get the same error?
Since you pointed out the problem with version, I’m starting to have doubt about it too.
From what I see in the PR, most of the changes in files are only to accommodate 2nd Heli style frame. Previously, “#if FRAME_CONFIG != HELI_FRAME” was used as there was only 1 Heli style frame.
So I’ve been thinking of modifying latest release (3.4.4?) by simply replacing Normal Heli mixer with Dual Heli.
But the code stucture is too complex that I’m not sure if AP_Motors are the only files that need to be replaced.
I haven’t had a chance. I wouldn’t recommend moving to 3.4.4 since he originally developed it in 3.3.X. I say this only because there could be other things that may cause problems. I used fhedberg’s PR to add a compound heli frame to 3.3.3. I did it manually and it took me a good 30 hrs but I’m not a trained C++ programmer. Plus I went through all of the files in the ArduCopter directory and looked for all the #IF FRAME_CONFIG statements. Some are =HELI_FRAME and some are !=HELI_FRAME. The motors library is the most challenging. Just follow what he did in the commits from the PR and that should get you there. If you get stuck, you can look at my repository for the Compound heli here. I did this in the released version of 3.3.3. For the most part you may just need to reference how I implemented the motors file. I think there were some things I had to do for the Constructor to make it work.
Finally cleared homeworks. Time to dig this back up.
Long story:
During all the previous tests yaw is accomplished by differential collective and this caused opposing lateral motion side effect (CW yaw = drifting to right). I added roll compensation code but this resulted in weird tilt when turning and difficulties tuning rudder.
So I try changing to differential cyclic approach.
While bench testing, I noticed an undesirable servo reaction when giving yaw input and full cyclic. It looked like phase angle is varying…so “messed up” is a perfect description.
Still happened after I set roll_factor , pitch_factor to 0 (cyclic output disabled).
With yaw input, swash went from fore-aft differential to both tilting outward when giving full cyclic input (roll/pitch_factor set to 0).
Commented out some lines … No fix
Put old firmware back in … Still there (am surprised how I missed that before) <<<Rage Quited at this point
Short story:
Found glitches
Wanna rewrite them all
Questions:
I’m going to use AC 3.5 and try to get away with an easy way by not adding new frame type but modifying AP_MotorsHeli_Single files instead.
Will this work?
Will there be any other file that need to be modified as well?
Yes I am sure the mixing is a bit challenging. When you get to max throw on rudder, I’m sure you may see servo limitations that may cause unexpected swashplate movement.
As for moditying AC 3.5, I wouldn’t recommend modifying software that hasn’t been released. Start with AC 3.4.4 since it was just released. I think your plan would work but you will need to change a few other files and the constructor in the motors file will have to be modified for the additional servos for the other rotor head. I agree that it saves from having to modify a lot of files for the frame change.
I think this is a good time to study ArduCopter code.
By the time I figured things out, AC 3.5 probably have been released (has to be before Here+ GPS ships)
Is it better to start a new topic?
I feel like starting from the beginning.
There’s literally no one that I know (in my country) who knows Ardupilot.
Can you guide me as if I just bought a new computer?
PS. I found that cherry-pick command doesn’t work with commits in pull requests. It works fine on master.
Having fun with animation lately 
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
It was “rebased” onto Master since May 6 2016.
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.