Agressive takoff in version 4.5.7

I would set all the motor and props to straight/level/aligned (however you want to term it). I think that would be easier than getting them all aligned to plus or minus 3 degrees accurately.
It probably wouldnt be such an issue with an octocopter, but with only a quad I can imagine that yaw changes will skew the direction of thrust and interfere with pitch and roll - and the same in reverse, pitch and roll will interfere unnecessarily with yaw.

Usually yaw authority is not an issue except in a few very specific cases. Yaw is actually the quickest acting of all the axis.

I personally never seen large quad drone without motors rotated to reduce gyroscopic precession from spinning props. I have never really experimented without having them angled, I will have to give that a try or at least minimize the degrees. I’m using.

The motor mixers in Arducopter assume all the motors spin in the same plane, or are at least parallel.
Some brand-name copters have angled motors, some for yaw authority, some upswept arms presumably for some “natural stability” (which is not really true), some like a Phantom are all over the place with each motor at a different angle. Their software will be designed around that.
So far no one has shown that upswept arms makes any real difference (happy to be proven wrong), and twisted motor mounts can aid yaw if it’s really needed !
Otherwise these attributes will hinder tuning and flight more than they fix - that’s my experience so far.

My understanding is gyroscopic affects dont need cancelling, since every second motor spins in the opposite direction to the other - if that’s what you mean. The layout can be important.
Torque from the motors gives us the yaw (not normally the angled thrust) and it is in fact a stronger more immediate force than regular pitch and roll caused by thrust.
Where this standard torque-based yaw falls down is when there’s a requirement for constant yaw or lots of other movements - motor outputs can soon become saturated trying to maintain all of yaw plus altitude and attitude.
Twisted motor mounts to aid yaw really are a benefit where you’ve got an uncooperative payload, and some specialist situations like that. Or maybe low torque motors, or motors that may already be operating near saturation.
There’s some arguments to be had there, like a) why not just upgrade the motors and dont use any twist, or b) twisted mounts give slightly less vertical thrust so are you really gaining anything since the motors will tend to higher output anyway?

That’s my 2cents worth.

I’m gonna try to zero it out and see what happens.

Cool.
The motor outputs in the logs tell the story - the motor mounts are not all twisted by the same amount.

OK, here is the newest log motor adjusted. I did notice less yaw authority, but that can be PID’ed out.

The drone struggles to maintain altitude; in a hover, it will maintain, but flying and turning it loses altitude.

https://www.dropbox.com/scl/fi/5tr8sx8vocr7vkhr5nuqq/log_18_2025-5-5-13-31-42.bin?rlkey=zscyuzr6zqm6hi7wa5cjcexln&st=vgyo7xww&dl=0

Let’s start with these and see how that goes in another flight.

ATC_INPUT_TC,0.22
GPS_AUTO_CONFIG,2
PILOT_TKOFF_ALT,200
PSC_VELZ_P,3
TKOFF_SLEW_TIME,2
TKOFF_THR_MAX,0.9
WP_NAVALT_MIN,2

The copter is over shooting the 1m takeoff altitude so lets try 2m, and hopefully that VELZ param has a positive effect on the altitude control, it was very low.
Pitch and roll are a fraction sub-standard but under control, we might tackle them next if we get the altitude going OK.
We can safely leave yaw to be addressed last, since it actually looks quite reasonable in the log.

Which battery monitor do you have? The current monitor is wrong. It could be quite handy to have that set correctly for diagnostics and even compass calibration.
BATT_AMP_PERVLT

Can’t use this setting GPS_AUTO_CONFIG, as it disables the GPS. I’m using Can GPS.

https://www.dropbox.com/scl/fi/103cantq1mi9xfjart6nv/log_19_2025-5-6-13-49-50.bin?rlkey=grqt52s3h1x8pjraj48t7ewdj&st=wlli3ooa&dl=0

Pitch and Roll attitude control is already quite good.
Yaw is OK - what do you think about yaw? Does it need to respond sharper? or do you find it undershooting or overshooting? Wandering a bit?

Altitude control looks a lot better! Was that your observation?
I would now alter PSC_POSZ_P,0.75 and consider running Autotune.

Sometimes running Autotune can be a “I dont know what’s happening so I’ll get the copter to try and sort itself” and in this case we could continue adjusting pitch, roll and yaw PIDs for the next couple of months - or just let Autotune do it.
I do Pitch and Roll first, in one session if you have enough battery.
I normally do Yaw later if it’s even required.
I find that once pitch and roll is autotuned successfully then other minor issues either go away, or are obvious enough that they are easier to fix. I am fairly certain the altitude issues will be further reduced (it’s not bad now) and yaw may only require a tweak or two.

You may only need to run Yaw autotune, also select the D term option.
Once it’s completed successfully, you may need to increase the ATC_ACCEL_Y_MAX by 10% to 30% if you see undershoot or overshoot.

I see you fixed the battery monitor, that’s great.
Here’s a slight improvement to the compass calibration. Better compass calibration helps everything.

COMPASS_OFS_X,174.70499
COMPASS_OFS_Y,-124.96505
COMPASS_OFS_Z,268.83203
COMPASS_DIA_X,1
COMPASS_DIA_Y,1
COMPASS_DIA_Z,1
COMPASS_ODI_X,0
COMPASS_ODI_Y,0
COMPASS_ODI_Z,0
COMPASS_MOT_X,0.015443043
COMPASS_MOT_Y,-0.38918403
COMPASS_MOT_Z,-0.541995
COMPASS_SCALE,1
COMPASS_ORIENT,0
COMPASS_MOTCT,2

GPS_AUTO_CONFIG,2 should just allow updating (saving the settings) for a CAN GPS unit. Maybe yours is not OK with that. Using GPS_AUTO_CONFIG,1 (update serial devices) as per normal just means that arducopter will ask for the settings to be made temporarily every boot. No big deal.

It took three flights, but it only logged one. I did an auto takeoff, and it still launched like a rocket ship. In manual arm takeoffs, it’s smooth.

https://www.dropbox.com/scl/fi/w1447y70fyjggqrnfm18i/log_20_2025-5-7-14-51-28.bin?rlkey=l2q85nwh4a5bzopk2xmmx8ser&st=9c9njb79&dl=0

There’s two flights in that log, I dont see those RC errors at all. That must be in another log. “Main loop slow” looks like a problem - you might want to check if there’s LUA scripts you dont need. Just set SCR_ENABLE,0 if there’s nothing you absolutely need, just to rule out scripting. Maybe RC not found is related, either caused by, or causing, the long loops. I would have rebooted the FC after any warnings and errors like that. If that log does exist it would be very important for us to pass on to be examined.
In the log supplied loop rate is steady at 400Hz and CPU load never goes over 37%, usually around 34% to 36% in flight which is very normal.
Clearly something else was going on but I cant tell from this log.

Let’s go back to the takeoff some more
Try these:

TKOFF_SLEW_TIME,3
TKOFF_THR_MAX,0.6

You could also lower WPNAV_ACCEL_Z but that would also affect altitude changes during auto flight, probably not desirable.

Also just before takeoff in Guided mode the throttle ramps right up to maximum for about 2 seconds but the copter doesnt move at all, as if motors are not spinning. It only starts to lift as throttle is dropping back down to a realistic/low level.
It’s like the ESCs didnt respond to the demand, and there’s a thrust loss warning.
Did you observe this?
I would probably use MissionPlanner motor test to double-check MOT_SPIN_ARM and MOT_SPIN_MIN - beware of doing these tests with props on. I suspect your values are correct and have been working OK for some time - I suppose there was a disturbance in the matrix for this take off.
Do your motors reliably spin up to MOT_SPIN_ARM at every arming?

The loop was slow, probably because the drone was on my bench, not flying. Yes, I do have the VTOL tune lua installed.
When arming, the motors spin correctly, and the ESC responds on demand. I do have the motors set using Mission Planner. Yes, the motors spin reliably when armed.

Thanks again for your help- here are a bunch of logs-
https://www.dropbox.com/scl/fo/y5jeohxla9of2bv2ujc3x/ADGxobWPbYdVqo7gb8mwXQw?rlkey=7g105raq3vfcqpec91965wuc1&st=ets03hm3&dl=0

TKOFF_SLEW_TIME to 10 made it much better, but it is as if there is a weird vertical bounce.

These might sort that altitude bounce:

PSC_ACCZ_I,0.4
PSC_ACCZ_P,0.2

and the second notch filter can be disabled
INS_HNTC2_ENABLE,0

This should help out Yaw a bit without introducing any adverse effects, I noticed there was a fraction of overshoot.

ATC_RAT_YAW_D,0.003
ATC_ACCEL_Y_MAX,18000

Looking good- https://www.dropbox.com/scl/fi/8049k9ecnbk443zrhdyaq/log_0_2025-5-11-13-45-34.bin?rlkey=zok5kk0ivvz0k3787josnvsi5&st=k7u799p3&dl=0

Yeah, it seems all good now. Altitude variations are less than 0.5m and normal considering pitch and roll activity.
Feel free to call out anything else.

One thing I notice is that it loses altitude in loiter when turning.

Try increasing this in small steps until the issue is gone, it doesnt take much so start at 0.1 , default is 0

ATC_THR_G_BOOST,0.1

https://ardupilot.org/copter/docs/parameters.html#atc-thr-g-boost-throttle-gain-boost

Well, I added a radar for terrain following, and it seems to be working. Here are some logs if you care to look-
https://www.dropbox.com/scl/fo/y5jeohxla9of2bv2ujc3x/ADGxobWPbYdVqo7gb8mwXQw?rlkey=7g105raq3vfcqpec91965wuc1&st=8v25rb65&dl=0

Thank you again!

It’s good that the rangefinder altitude is clean - it’s common to find lots of noise and glitches.
Watch out for that if carrying a slung payload - you might need to use an RC switch to disable the rangefinder which is annoying if you rely on it.