Hi Guys,
I notice some strange behaviour during auto missions, my WP_YAW_BEHAVIOR is set to Face next waypoint, it works like its supposed too, but sometimes the autopilot demands a random YAW in the middle of the survey line, as you can see the red square on Des. YAW x Yaw:
The YAW are corrected when the copter passes though next waypoint.
Any advices what im missing here?
Im using Arducopter 4.0.5, with MRO duas compass GPS Module (LIS3MDL by ST and the IST8310 by iSentek)
Did you move the sticks? what deadband are you using in the receiver?
Hello Alexandre,
Yaw command in autonomous flight can be overridden by the pilot during the auto mission. This can happen either in GUIDED mode or in AUTO mode. There are two explanations that I came up with for your problem.
First, assuming your radio RSSI configuration is right and you disabled radio failsafe knowing the radio connection will be lost, then either the receiver has malfunctioned or the autopilot received RC_override message from GCS. I don’t know if one can determine the reception of the RC_override messages from the logs. Can you share further information about your setup? Also, your EKF failsafe action is ALT_HOLD. Given that you intentionally do not thrust the radio and your connection would have been lost during the mission, this configuration seems a bit contradicting. In this configuration, upon EKF failsafe the vehicle will drift with the wind until the battery failsafe is triggered and if your radio trim is wrong or the dead zone is too tight the vehicle could go in any direction.
The second explanation is the radio RSSI values are not right, The RSSI value drops to zero even at 200 meters away from the takeoff location. This much degradation at a close distance seems worse than what you can achieve even with cheap radio like FLYSKY FSi6. Can you share what radio transmitter and receiver are you using?
Going with the second assumption it looks like your radio connection is lost 2 times during the flight.
The behavior of the receiver is not consistent with each other in these two instances. Interestingly channel 8(flight mode channel) did not change during these moments. Although it is well above the flight mode assignment range, channel 8 drops from 982 to 879 multiple times as well.
In the first instance, RC1, RC3, and RC4 drop to 879 us PWM for approximately 0.8 seconds while RC2 stayed at 1494 us PWM. This the part of the flight where your uncommanded yaw behavior occurred.
In the second instance, RC1, RC2, RC3, and RC4 drop to 879 us PWM for approximately 0.1 seconds.
The desired yaw did not change high enough to be noticeable due to the short duration of abnormal behavior.
In either case, you should check your radio transmitter and receiver. RC channel between 9-14 also shows similar problem.
Apart from the radio issue, you have a very high vibration level. They are well above the maximum recommended limit. I am surprised the EKF failsafe did not trigger. You should give the following link a read.
https://ardupilot.org/copter/docs/common-measuring-vibration.html
You also did not configure the harmonic notch filter and you are using default controller gains.
if your ESC does not have telemetry output, you should use the throttle-based harmonic notch filter. Harmonic notch really does make a difference.
https://ardupilot.org/copter/docs/common-imu-notch-filtering.html
After configuring the harmonic notch filter, you should follow the tuning instruction. Since you can already hover you can perform the autotune.
https://ardupilot.org/copter/docs/tuning-process-instructions.html
Emre
Thanks for answering.
You are right, i checked my radio input and for some reason, there’s some spikes commanding the yaw.
Im going to investigate that.
First of all, thanks for your time and effort to help me.
Yaw command in autonomous flight can be overridden by the pilot during the auto mission. This can happen either in GUIDED mode or in AUTO mode. There are two explanations that I came up with for your problem.
You are right, the cause is really an involuntary radio change. I’ll set the AUTO_OPTIONS to ignore pilot YAW input to avoid this situation in the future.
First, assuming your radio RSSI configuration is right and you disabled radio failsafe knowing the radio connection will be lost, then either the receiver has malfunctioned or the autopilot received RC_override message from GCS. I don’t know if one can determine the reception of the RC_override messages from the logs. Can you share further information about your setup?
Yes, i disable my radio failsafe on purpose. We only fly using telemetry (RD900+). The RSSI is configured based on FRSky XM+ instruction manual. We are using FrSky X-Lite as a remote control and the short control distance is no a problem, we dont have an intention to control the aircraft using the radio beyond the line of sight.
Also, your EKF failsafe action is ALT_HOLD. Given that you intentionally do not thrust the radio and your connection would have been lost during the mission, this configuration seems a bit contradicting. In this configuration, upon EKF failsafe the vehicle will drift with the wind until the battery failsafe is triggered and if your radio trim is wrong or the dead zone is too tight the vehicle could go in any direction.
Thanks for advise, since we always flown beyond line of sight based on the telemetry, I set the EKF failsafe do ALT_HOLD to have some time to change the Flight mode to RTL in case of EFK FS occurs. We also fly with geofence and telemetry FS always enabled.
The second explanation is the radio RSSI values are not right, The RSSI value drops to zero even at 200 meters away from the takeoff location. This much degradation at a close distance seems worse than what you can achieve even with cheap radio like FLYSKY FSi6. Can you share what radio transmitter and receiver are you using?
Im using FrSky XM+ RX and FrSky X-Lite S TX.
In the first instance, RC1, RC3, and RC4 drop to 879 us PWM for approximately 0.8 seconds while RC2 stayed at 1494 us PWM. This the part of the flight where your uncommanded yaw behavior occurred.
You are right, that’s the cause for the behaviour. I think it could be related with the RX Failsafe. Im going to double check to ensure it was configured to “no pulses” to avoid this unintentional changes.
Apart from the radio issue, you have a very high vibration level. They are well above the maximum recommended limit. I am surprised the EKF failsafe did not trigger. You should give the following link a read.
You also did not configure the harmonic notch filter and you are using default controller gains.
if your ESC does not have telemetry output, you should use the throttle-based harmonic notch filter. Harmonic notch really does make a difference.
This is my next step! In fact, when i try any modification on the PID values, the copter triggers the Vibration compensation function. That is the reason to leave the PID on default settings until I configure the notch filter.
Thanks again, your well described analysis really helped me!
I’ll keep you updated about the tuning processes.
I didn’t know there is an option for disabling the yaw command. Thanks.
I didn’t use FrSky X-Lite unit before and I am not saying your unit is defective, but I am just surprised with the low communication range. You can try “no pulse”, but the error does not seem to be deterministic even in itself. Just watch out for any anomalies with that receiver.
The vibration level at hover flight is not that high, it becomes very high during the forward flight when the vehicle going against the wind with the lean angle of 20-25 degrees. This can be seen in the following graph, where the pitch angle is about 6-8 degrees vibration level is normal, but when the pitch angle reached 21-24 degrees total thrust required to stay in air increases high enough to cause vibration problem. The thrust differential between the front and back motors did not change too much between hover and forward flight so I assume your center of gravity is close to the propeller rotation plane.
Please keep us updated.
