Default behavior is to yaw in direction of travel. The Copter “faces” forward unless a specific yaw command is given in the mission.
Even in this state, the yaw is turned once.
I would expect navigation to look like this, failing any specific yaw/ROI commands (the triangular point indicates the “front” of the Copter):
https://drive.google.com/file/d/1PItmKzHY2nXJ_AW0MLGtwTvqPXMIKTQ-/view?usp=sharing
WP_YAW_BEHAVIOR : 0
It’s currently moving like this.
What flight mode are you actually using?
And the real question is: Do you actually need GPS for Yaw (which is perfectly OK if you do of course), or is it just because compasses are hard to calibrate on big copters?
There’s no known detriment to enabling the compasses either, so you could at least test and see if you get the same behaviour.
4.3.0 firmware touched only i2c.
Change from Loiter mode to Auto mode
Compass correction is difficult because it is a large drone.
Compass correction, and compass motor compensation, is easy with any size craft using Magfit from MAVExplorer.
Magfit
1 Like
Yeah, I already mentioned it too.
I think it would be preferable to use standard (latest stable) firmware too. If there’s some special I2C device added then put in a pull request and get it officially added. Or at least rebase you changes on the latest firmware.
I can confirm via SITL and the latest 4.3.3 stable release that your expectation is correct regarding this parameter when switching to AUTO mode.
During simulation, the Copter never changed yaw when entering AUTO mode from LOITER with WP_YAW_BEHAVIOR=0.
GPS-for-yaw is performing quite nicely on your Copter, providing an adequate heading reference throughout. You’d be well advised to enable a compass for backup, as has been mentioned countless times already here, but it isn’t strictly necessary.
I suspect the undesirable yaw behavior is induced by your custom firmware, either via the custom flight mode(s) or possibly by lacking the latest bug fixes and improvements (again, recommend rebasing).
I’ll upload it to the latest firmware.
Thank you.
Thank you for your answer.
The problem continues to occur.
FC: pixhawk6c
Firmware : arducopter 4.3.3
GPS : f9p
It’s in automatic mode, but it doesn’t look straight at the waypoint path.
I hope the red arrow is frontal.
What is the reason?
Link to video : https://drive.google.com/file/d/1HTN313jo8Ygz_sVfHyxwxsJRj8KBdu_c/view?usp=sharing
Link to log : https://drive.google.com/file/d/1IXHFJtK4fAb_sWMGULAyouMNCoBFY1Yd/view?usp=sharing
Please help me. It’s very urgent. I beg you.
You are stating “urgent” yet there is so much more to do and you dont appear to have tried the suggestions.
Can you list out that mission as a text file? It looks like you’ve got some yaw command at the start which could be the whole problem.
And I think you have the WP_YAW_BEHAVIOR set wrong too, try this
WP_YAW_BEHAVIOR,1 or 3
BUT dont stop there and call it fixed! Continue on to everything below. Many of my parameters listed are what’s known to work or required for safety. You dont want to compromise safety since this copter is apparently too big to even calibrate compasses (via several methods that would work).
Do you have T-Motor Alpha or Flame ESCs?
I would definitely set all these, and DO NOT skip any thinking I dont need that
ATC_ACCEL_Y_MAX,20000
BATT_ARM_VOLT,44.30
BATT_CRT_VOLT,42.00
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2 or 3
BATT_LOW_VOLT,43.20
FENCE_ENABLE,1
INS_ACCEL_FILTER,10
INS_GYRO_FILTER,20
INS_HNTC2_ENABLE,0
INS_HNTCH_BW,17
INS_HNTCH_ENABLE,1 ← set this then refresh params to see the rest
INS_HNTCH_FM_RAT,0.7
INS_HNTCH_FREQ,35
INS_HNTCH_HMNCS,3
INS_HNTCH_MODE,1
INS_HNTCH_REF,0.21
INS_LOG_BAT_MASK,1
INS_LOG_BAT_OPT,4
MOT_BAT_VOLT_MAX,50.40
MOT_BAT_VOLT_MIN,39.60
MOT_SPIN_ARM,0.12
PILOT_THR_BHV,7 ← I believe you have a spring-centered throttle
PSC_ACCZ_I,0.6
PSC_ACCZ_P,0.3
If you have T-Motor Alpha or Flame ESCs set these:
MOT_PWM_MIN,1100
MOT_PWM_MAX,1940
MOT_THST_EXPO,0.4
You will need to use MissionPlanner motor test to verify that MOT_SPIN_ARM actually works for reliably starting the motors and they run smoothly.
Now hover in AltHold for a while for the hover thrust to relearn, dont be surprised if throttle input is required for some time until hover settles down. Now just do some gentle movements of pitch and roll, and do some circles to log plenty of yaw behaviour.
Let’s see the .bin log file after all that.
Use hobbywing x8 motor.
There is no problem with tuning.
There is no problem with safety either.
WP_YAW_BEHAVIOR : 0=Never change yaw
I don’t change the yo according to waypoint.
So these mean nothing to you?
BATT_ARM_VOLT,44.30
BATT_CRT_VOLT,42.00
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2 or 3
BATT_LOW_VOLT,43.20
FENCE_ENABLE,1
And you still need these for those motors
MOT_PWM_MIN,1100
MOT_PWM_MAX,1940 and you still need to test and possibly set MOT_SPIN_ARM and MOT_SPIN_MIN correctly.
MOT_THST_EXPO might have to be something more like 0.7
There is no problem.
So what is it you actually want?
The graphic posted indicates you want the yaw to point along the GPS path, or at least to the next waypoint, and I’m suggesting the fix:
WP_YAW_BEHAVIOR,1 or 3
You could try listing out that mission, or even a screenshot since there is some yaw command first.
And I see a whole bunch of safety and tuning features that would normally be used for anything this size.
Some of the things you have set will give you trouble, or wont work as expected.
EDIT:
I just want to say I’m not trying to argue or fight
I am just very concerned when I see parameters that I know are not going to work for you
Carry on then, good luck.