As well as this, the 100Hz harmonic notch frequency means that at low throttle the notch isn’t covering the actual frequency. Try changing it to 80 (say) but make sure you keep the bandwidth proportion the same
1 Like
So I discovered my harmonic BW was unintentionally huge (like 50hz) so I dropped that to about 20Hz and lowered it to 80. Surprisingly got that ‘grind’ issue back again. What’s a reasonably good BW and attenuation for HNOTCH and NOTCH filters?
After this point, I tried reducing D and a number of PD ratios but can’t seem to make the wobbling go away (at most I can perturb it). I’ve gone as far dropping my PD balance quite a bit (ie. half my D with the same P). I can see the noise on the roll domain everywhere.
Is the rate loop issue essentially a problem of aliasing? There’s a higher frequency issue that’s aliasing down to the control range and the only fix is to increase the rate loop? I’m still trying to build a concept of the filter/control system and I keep wondering why the filters can’t seem to take care of the aliasing.
I tend to use 2/3. So 50 Hz is fine for as low as 75 Hz.
1 Like
Got it, thanks. And do you use 30db attenuation?
I have to say the strangest thing so far I’ve experienced tuning is that I can get settings where split-S performance (like flip upside down, dive, and slowly pull to level) feels better than flying-in-straight-line or slow descent.
I also had a question about MOT_THST_HOVER. In stability or acro with air mode enabled, is there anything in the SW that changes behavior based off whether above or below it? At most is it calculation in the in ATC_MIX?
I go as high as 80. But there isn’t much difference between 80 and INF when using dB.
MOT_THST_HOVER is only used by ATC_MIX_MAN in Acro and Stab. And as long as MOT_THST_HOVER x ATC_MIX_MAN > 0.5 then you basicly never use it. Other than that it is only used for throttle at mid stick.
Hi Andy,
Had a few questions:
The F405-SE has a MPU6000 and I read on another page that it doesn’t support fast sampling. So I have INS_FAST_SAMPLE = 1 AND INS_GYRO_RATE=1 (2Khz) currently. Is this a don’t-care at the moment? (the thread I’m referencing is this one: Kakute f7 Mini Problems (Or just problems w/ my build..))
And where do I find the notch update rate (first time I’ve heard of this so I want to see where it’s set at right now).
Also asking for future use: on my H743-Slim should I use FAST_SAMPLE and GYRO_RATE = 1. Above thread mentioned about the ICM20602 being noisier but the Slim has dual-gyro ICM20602 and MPU6000 so also curious how I should set that one up.
I also am noticing that the logging comes in at a fixed periodicity. It always logs about 2.11 seconds of data then misses about 0.9 seconds worth of data. Could this point to overloading CPU?
I’ll try again with my HNOTCH fixed up. Regarding your loop rate comment, should I try setting my sched_loop_rate to 800 (it’s 400Hz)?
The only time I had an issue with that was when I ran autotune; it triggered a CRSF failsafe. I’m thinking of giving it a try again.
MPU6000 supports fast sampling on gyros which is all you care about.
On an F427 INS_GYRO_RATE=1 was too much for the CPU - I got worse performance. On a 7" it seems like you are not going to benefit from it much and it may be hurting.
On my 7" build I have swapped the IMUs because the MPU6000 is much less noisy than the ICM20602
Notch update rate can be set via INS_HNTCH_OPTS, but don’t increase it on an F4
Still working on tuning the filters and PIDS, but in the process I stumbled into this interesting behavior at one point.
I normally run a 6S2P 5200mAh 18650 pack but I thought I’d try using a single 6S 1300mAh LiPo to see if there’s some mechanical reason (battery shake) for my vibration. By changing out the battery to a lighter one and not touching any other setting, I instantly got visible shakes in LOS.
I ‘improved’ this by dropping PIDs, but didn’t get to really play with settings.
However, I was reading some posts on forums and found one that suggests this sensitivity to weight may be a sign that motor thrust expo is set incorrectly or linearization is way off. Sound about right?
The reason you tune at your lightest weight is because that tends to be your lowest inertia and therefore lowest PIDs. So it is expected that you would see occilation in your aircraft if you significantly lowered the weight of the battery you are using.
Expo will show occilation at low or high throttle if it is significantly wrong. For a racer the throttle hover is very low already so it is hard to tell the difference at low throttle between expo and the disturbance due to the motors rubbing up against the minimum pwm.
Andy, what do you mean by “Acro is still a stabilized mode?”
Arducopter ver 4.1, Matek H743 Mini, 4" prop quadcopter
The reason I ask is I’ve got Acro setup on a transmitter switch (I’m used to flying Acro with Betaflight firmware). RCx_OPTION = 41.
However, when I’m in Acro Mode with Arducopter, I’m experiencing an unexpected strange behavior that I’ve not had with Acro mode in Betaflight firmware.
With Ardupilot Acro mode, when I do an “aggressive roll while pitched forward and dropping throttle”, sort of like entering a 180 degree turn, the copter feels as though its “snapping back” into an uncommanded position. This is not prop wash (I know what that is). So, I’ve researched the Acro Mode parameters to the best of my ability. I’ve got Acro trainer = 0. I had ACRO_OPTIONS set to Air Mode always ON (thinking this Air Mode was the same as in Betaflight). RCx_OPTION = 41 (Arm/Disarm) on a switch. I understand this enables Air Mode. Per ArduPilot site, Air Mode is explained as “stabilization at idle throttle is fully active.” I’m confused about this “stabilization” term.
Could this be what I am experiencing? What “Stabilization” does this refer to?
Site refers me to ATC_THR_MIX_MAX (throttle vs Attitude Control Prioritization), however, the “attitude control” wording in the explanation I do not fully understand. Does this mean “yaw” only or does it also include the roll/pitch angles? I do not believe I am experiencing a “yaw” issue. It’s more like its snapping back from a roll angle.
The Air Mode I am used to in Betaflight, I believe, temporarily increases the throttle setpoint to allow greater maneuverability during lower throttle maneuvers but (to my knowledge) doesn’t do any self-leveling stabilization.
If this is what i am experiencing, is the only way to eliminate it by Arming with rudder stick instead of switch? Or, is there another parameter(s) I’m mission/failing to set properly. My desire is to not have any “stabilization/self-leveling” at all in Acro Mode. Thank you.
1 Like
By stabilized mode I think it’s meant that the quad will maintain attitude (absolute roll/pitch/yaw angle). But it does not auto level (which is make roll/pitch “zero”)
So I worked around some of the issue with dropping throttle for acro moves by adding a throttle offset on my radio so when I flip a switch for acro, it will also keeps throttle ppm above zero threshold. There’s something in the control loop response that changes at zero throttle in acro but I haven’t narrowed it down
You should bump up mix_man to 2-4 for acro. It dictates how much motor authority (as a % of hover throttle) is given for attitude changes (ie any RPY input). In Betaflight afaik we don’t have such a thing or it’s just really high by default when air mode is enabled. The drawback with it high is when you land it may cause bouncing… Which we definitely do get in Betaflight if you land in air mode =)
We have 3 types of ACRO in ardupilot. Two of them are fully stabilized meaning that the aircraft keeps track of the attitude you should have based on your input. So if you hit a branch the aircraft will snap back to it’s original attitude before it hit the branch. However, if your aircraft tune is a little sloppy you will see this as snapback after a hard mauver as the aircraft was not able to follow your commands. Running a rate only controller the pilot can learn to deal with this.
You can see if this is what you are experiencing by setting:
https://ardupilot.org/copter/docs/parameters.html#acro-options-acro-mode-options
Oh, interesting about the hitting a branch…
So I’ll chime in that I started my arducopter experience with acro + rate loop only enabled and it flew like a drunken pilot because any wind would just push the quad around. I have post trying to “debug” acro because of this =)
I assume you did an autotune?
If you got a bad autotune then there is probably noise or another issue that is making it hard for autotune to make the measurements it needs. Try and run through the manual tune if this is the case.
ArduCopter is used on aircraft from 250 g to 500 kg (and more) and along with a huge range of flight controllers. So we don’t have those nice starting parameters and “standard build” that you get with Beta Flight.
Those are the manual tuning instructions but it is worth reading each line leading up to this part to make sure you haven’t missed anything.
https://ardupilot.org/copter/docs/tuning-process-instructions.html#manual-tuning-of-roll-and-pitch
Not sure if that was for Thomas or me. If for me… I had done an autotune before going to acro with rate only enabled. It felt like it wasn’t able to hold attitude… Like the attitude setpoint would drift around and if there were external forces like wind, it would be much worse.
To me it makes sense to have attitude stabilization, otherwise how would you keep your nose steady? Integrating gyro information is not going to perform as well. Over tuned P may cause snap-backs (in Betaflight, called bounce back)
Sorry, yes. I got my replies mixed up.
The angle stabilization is equivalent to a significantly higher I term. So to fly without it you may also need to increase the I term before you get similar performance.
Oh hmm, I’ll need to give this a shot but I’m not understanding something.
If I’m in rate only mode, then the quadcopter will only track gyro rate (rate of rotation). So if I didn’t give any stick input and an external force were to rotate the quad (lets say I blew on it), there would be a some rate change generated which comes up as rate error.
The PID loop would see this and apply an opposing rate so that the integral of rate X time ends up at zero? Or the rate ends up at zero. But change in angle is integral of rate X time so just correcting the rate without knowing time would mean you can end up at a different angle.