That sounds reasonable but then again I am no expert on multicopters and their flight characteristics. I can imagine that a lot of effort goes into making the FBL systems robust enough to handle the many different model helicopters on the market. Well I appreciate the effort you are putting into looking at my notch implementation. As I said before, this may not be the best implementation because it is on the error and not on the gyro. But at the time it was the quickest way for me to get it into the code.
I think there is merit to the mechanics and set up of servo throw but I feel that the same issues have to be addressed on the FBL side to keep their systems robust for most helicopters.
Pitt,
Did you adjust the curves in your radio or in the Pixhawk. Chris advised me to adjust parameters in the Pixhawk to smooth the transition between stabilize and loiter and its worked out like a charm. My radio is linear 0-25-50-75-100, all adjustments to collective I did with Pixhawk parameters.
Tim
Pitt,
I cant recall off the top of my head, I can certainly take a look in the morning when I make it to my workstation and get back to you. Or you could shoot Chris a message im sure, he offered me quite a bit of help setting that up to transition smoothly between loiter and stabilize.
Searching Google doesnāt return anything useful.
All collective related parameters I found are H_COL_MIN, MID, MAX and
IM_STAB_COLX.
My hover PWM (rcou from log) is around 1570.
Pitt,
This is a copy and paste of the information Chris had given me earlier in this thread. I knew the information was here somewhere, this thread is quite large to read through thoughā¦
If you read back through the thread at post #497 on, Chris had explained quite a bit about tuning for loiter & alt hold.
Hope this helps,
Tim
Pittās machine is a tandem with timed rotors, which may introduce some very interesting new features for tuning. Iām quite interested in it because a tandem is hard to beat for heavy lifting work. I have to get to my linux laptop to look at Pittās log and see whatās going on there.
Oh okay, I thought for some reason he had a standard 450 helicopter as well? Yeah I have watched some of his videos and followed his thread a bit, it really is an interesting build!
Pitt, I see you are running a custom build of AC3.4.5. What I saw in the log was that that tone was caused by mode Alt Hold refused. This is likely due to the runup timer not being met. With Trad Heli, when you arm and take off in Stabilize, and try to switch to an altitude controlled flight mode it will be ālocked outā until the time set for the runup is complete. In this case you didnāt do a runup after arming, so it refused to switch modes.
Maybe some other eyes will see something I donāt. Your Z vibes look reasonable and the IMU aliasing looks OK on the Z axis. But Iām wondering about something; you have ACCEL_Z_P set to .3. I would consider that in the normal range for a single rotor heli with a disc loading of 0.7 to 1 lb/ft^2. But I wonder if your machine has a very thrust/weight ratio with tandem rotors? So itās rapidly cycling the collective in Alt Hold? Maybe try turning that down and see if it makes a difference. Really light weight (high thrust/weight ratio) heliās Iāve run that as low as .2
Wasnāt aware of this. Is it an adjustable parameter? I set my ESC gov spool up time to 1.5s delay + 12s ramp, maybe I can set runup timer to this number.
Iām not sure whether to calculate its disc loading as 2-discs or 1-disc of 4-blades and to consider angle offset or not.
FYI
380mm blades + 70mm hole-to-hole grip
12.5 deg tilt (25deg between shafts)
2.1kg in the air (more to add)
It isnāt it kept either ascending or descending at a stick position as if there was no mid-stick region.
It didnāt yoyo up and down.
Yes, thereās two params, H_RSC_RAMP_TIME and H_RSC_RUNUP_TIME that should be set to sort of match. I think if the ramp time is set in your ESC, then only worry about the runup time. Alitude controlled flight modes will not engage in armed state unless the runup time is expired.
I really did not see a reason, other than that, that it would not hold altitude. I guess what I would do is set the runup time to a reasonable value, take off in Stabilize (I never have liked taking off in the altitude controlled modes), increase altitude to say 6-7 meters, and engage Alt Hold. If possible center the collective stick and see what it does and try to gather some data in Alt Hold with the collective stick not moving to see if can figure out why it refuses to work properly. If possible donāt move the cyclic either. Just let it drift with the wind for a few seconds to be able to see the RCOUT on your servo channels to determine if it is the flight controller commanding it to change altitude, or being caused by some other phenomenon. It could even be something like ACCEL_Z_P maybe not being set high enough for your helicopter for the collective to properly respond to a change in altitude.
It is an interesting question on the disc loading. I donāt know about the efficiency of the blades in the overlap area, or how that would be calculated with a timed tandem
So you got me curious to the answer. So I looked it up. Prouty states that it is the net projected disk area that is used to determine disk loading. For a coaxial helicopter, only the disc area of one rotor would be used. In your case, that would be a pretty close approximation.
So Iām not so sure that the ACCEL_Z_P parameter will correlate with disk loading. Chris, correct me if Iām wrong, but isnāt most of your data regarding the ACCEL_Z_P based on 2 bladed rotor systems. I think it will be more closely related to the coefficient of thrust divided by rotor solidity. This is a performance metric that is proportional to the average coefficient of lift for the blade. So what Iām basically trying to say is the fact that you have 4 blades will improve the helicopters ability to produce lift. So you may need a lower ACCEL_Z_P value. Just my thoughts on the subject.
Yes. It was really hard to tell from that log because Pitt tried to arm in Alt Hold and take off in Alt Hold. Iād like to see what it does taking off in Stabiilize, then switch to alt hold and get an idea of why itās not holding altitude properly. I would think if ACCEL_Z_P is too high it would cycle the collective really rapid - that is the only response I have ever seen from it being too high. With a large powerful helicopter it can slam it back and forth into the ground and bounce up and down 10 feet faster than you can blink. LIttle ones usually do a cute little āhop danceā. Pittās appeared to be totally random like it didnāt even engage. But it didnāt indicate that it failed to engage on the first attempt.
Hi Pitt,
I think you should decrease you ACCEL_Z_P a little bit and try again. Please post the log for the flight. You should take off in stabilize and then switch to ALT_HOLD. You should set your IM_* params such that in STABILIZE you can hover at mid throttle. That way when you switch to ALT_HOLD the heli will not be commanded abruptly ascend or descend.
This is why single rotor helicopters are the most popular/common in full-scale. They have the simplest, and lightest powertrain under the largest disk area. Coaxials are at a significant disadvantage (same with intermeshing). The only reason they exist is when you have a use-case where a tail rotor causes a major problem. Or, for very high flight speeds where RBS is a concern.
