Synchropter build need help


Today’s log
Things changed:
-Thicker mounting tape

-loosened blades a little and put some oil…
-re-leveled swash
-All servo arms are changed to alum arms (only 2 were alum previously)

Vibration looks much better!
And super stable!

So I redo PID tuning
got kP to ~0.07 but MP won’t allow any lower than 0.08 without forcibly changing it in Full Param list.
Tuning guide said 450 heli will get around 0.04.
What’s wrong here?

SK log also looks much better.
Only 2 spikes passed 4.0 Magnitude
Less than 4 the rest of the battery.

Glad things looked better. It looks like you made a lot of changes. Unfortunately it is difficult to tell what actually helped.

Be careful with this, you want a little friction damping. So I would not apply any more oil.

I didn’t ask before but I assume that the blade tracking was good previously and is still good with these changes. Blade tracking would most likely show in the vertical axis which looks much better in the pixhawk data. I realize that it didn’t show up much in the Skookum data which is odd. I’m seeing in the pixhawk data that your fore/aft vibrations are really high. Please change the LOG_BITMASK parameter to what I suggested in my previous post. I can’t analyze the vibrations in the pixhawk data until I get a higher logging rate.

So did you change the head speed? If so, what is the head speed for this data?

I suspect you meant to say MP won’t allow you to go any higher than 0.08. ultimately you want your P gain to be around 0.2 however helicopters aren’t able to achieve these values because typically they see violent oscillations before they can get that high. The tuning guide is just say that typically 450 helis can’t get the P gain above 0.04. So it is good that you can get yours to 0.07. I saw in a previous entry that you said you got it as high as 0.12 which is really good for a heli with the arducopter firmware. Have you looked at my post Technique to expand roll and pitch rate PID gains without instabilities? I discuss that lowering the Filt_hz parameter could help increase the P gains in pitch and roll but you first must increase the P gain until it starts to oscillate so you can determine the frequency. If you have questions after reading the first part of the post, let me know. The rest of it gets into modifications I made to the code to allow higher P gains.

From my experience, oil flies off right after spool up. That may be enough for blades to find their stretched spot (and hence, balance)

Sorry, completely forgot that LOL.

Haven’t changed yet.
As you said, there were a lot of changes already.

No, I wanted to set it to 0.06~0.07 but the values (in extended tuning tab) won’t go lower than 0.08 (upper limit is 0.30)
One thing I’m a little confused is that tuning guide said> “it gets bad REALLY fast and you could destroy your helicopter!”
But what I got starting at 0.084 was some wobble after fast cyclic input, not anything destructive.
This reason got me to 0.12 last time and what I got was a wobbly hover.

Yes, I did.
I dont1 think I understand all of those.
What I got is that you used filter to attenuate oscillations that are supposed to come from too high PID?

Please keep in mind that I’m just a sophomore.

Thanks for your help anyway

Change your LOG_BITMASK to 397310. Then give me some data for the aircraft in a hover where you can see some wobbling due to a high P gain. Once I determine the frequency, I can give you better guidance on what to set your filters to.

Here
Gave it a cyclic jab and got you a healthy oscillation.
Hope it is enough.
1 1-1-2000 8-01-34 AM.bin (1018.0 KB)

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:

  1. Picked up a PH2.1 without any experience with Ardupilot.
  2. Put it on a frame no one has worked on.
  3. 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 :slight_smile: