Failed to change to loiter mode -- "Requires position"

My Quad S500 is running Arducopter V4.0.5 using Pixhawk 2.8.4. Changing flight mode has been very normal for the past few years. All of a sudden, without changing any hardware or setting, when airborne, it failed to change to loiter mode from either Stabilze or Alt Hold mode. There is 3D fix with sufficient satellite locked. On the bench, changing to loiter mode has no problem.

The error message from telemetry says “Flight mode change failed … Requires position”. But there was clearly 3D fix and compass was working normally.

Links to the DF log and binary log are here :–
https://drive.google.com/file/d/1m7CZ7ZUc_io-Ij0JVtooOrcZM1goOj74/view?usp=sharing
https://drive.google.com/file/d/1huwusLEQtgp8qJHwj9uIrD8NeVMByIss/view?usp=sharing

Could anyone who is familiar with reviewing log help to see if any clue can be found. Thank you.

You’ve got one motor with vastly different performance to the rest, motor 4. And you can see 1,2 and 3 are sometimes hitting their maximum output.


Reaching maximum output can be OK when it’s expected, like a moonshot or speed run, but you’re keeping a relatively constant altitude and inputting lots of attitude changes. Motor outputs should be centred more around 1500 to 1600 pwm typically.
So you aircraft is a bit overweight, and the battery voltage is not doing you any favours.
Maybe run the all-at-once ESC calibration and check the weight distribution.


The battery voltage is low, like a very low C battery or it’s going bad. You can even see the oscillations at the end where the LED and beeper would have been going off after battery failsafe.
If you think the battery itself is OK and the voltage is good, then do the manual calibration of the voltage sensor. Calibrate at a low voltage where knowing the real value is most important.
Current monitoring is not working - it would be highly desirable to fix that.

image
Vcc is a bit low, you might want to check or replace your power brick, or at least check connectors and measure the 5vdc input at the flight controller. I’ve heard it said the the 5vdc is not very critical because most of the FC internals run off 3.3v anyway - BUT that 5vdc input is also redistributed to the GPS module and other external units too, such as RC receiver and telemetry radio. Add a couple of more connectors into the mix and the poor old GPS is expected to work off about 4vdc instead of 5vdc.
If GPS is good while the FC is plugged into USB, measure the voltage to the GPS then and that’s what you’ll need as a minimum.

image
Number of Sats is only 9, and HDOP is not great - both are theoretically OK for providing a good 3D Fix but in reality you want better. Maybe fixing the Vcc might help. Probably try to measure the 5vdc at the GPS module and see what you get. Sometimes there are just bad GPS days too…

I suggest you set these to help PID and thrust scaling with battery voltage, and the Fence will keep you disarmed until there is a 3D Fix and home can be properly set. You do stand around waiting for longer but it saves that panic and endless walking of a fly-away.
BATT_ARM_VOLT,11
BATT_CRT_VOLT,10.5
BATT_LOW_VOLT,10.8
MOT_BAT_VOLT_MAX,12.6
MOT_BAT_VOLT_MIN,9.9
BATT_FS_CRT_ACT,1
BATT_FS_LOW_ACT,2
FENCE_ACTION,3
FENCE_ALT_MAX,120
FENCE_ENABLE,1
FENCE_RADIUS,400
FENCE_TYPE,3
PSC_ACCZ_I,0.6
PSC_ACCZ_P,0.3
ATC_THR_MIX_MAN,0.5
Check the altitude and radius to suit you local laws, or sanity :slight_smile:

Try this for smoother RC input. You can even go a bit higher, up to 0.3 to suit your taste.
ATC_INPUT_TC,0.2

After all that, I’d run Autotune - the PIDs and many parameters are at defaults and pitch/roll tracking could be a little better.
Here’s a spreadsheet to derive starting values, or connect to MissionPlanner and press Alt A


And the tuning process instructions:
https://ardupilot.org/copter/docs/tuning-process-instructions.html

1 Like

Hi Shawn,

Really appreciate your review and the very detailed suggestions. I must admit that I did not put enough effort to make the quad flies better. Following are my response :–

xfacta

      [Shawn](https://discuss.ardupilot.org/u/xfacta)




    December 18

You’ve got one motor with vastly different performance to the rest, motor 4. And you can see 1,2 and 3 are sometimes hitting their maximum output.I forgot to mention between the date I flew the quad (on which the DF log was recorded) and yesterday, I flew the quad again to test the mode change failure, the quad crashed due to 1 ESC (for motor #3, front left) failure. I then replaced that ESC. But it was not motor #4 as suggested. Is motor #4 the lowest light red curve(mean value around 1580) in your graph ? I did not attach the DF log of the crashed flight to avoid misunderstanding, because the Error analysis shows failed GPS test even though I got 3D fix just before takeoff.

By the way, did you use APM Planner V2.0 to graph the log data ?

Reaching maximum output can be OK when it’s expected, like a moonshot or speed run, but you’re keeping a relatively constant altitude and inputting lots of attitude changes. Motor outputs should be centred more around 1500 to 1600 pwm typically.

So you aircraft is a bit overweight, and the battery voltage is not doing you any favours.I was thinking just a brief flight to check the mode change failure, so the pair of flight battery (30C) used was at storage voltage, 3.8v/cell without fully charged.

Maybe run the all-at-once ESC calibration and check the weight distribution.After I replaced the bad ESC, I did the all-at-once ESC calibration, and at the same time, happen to realize(after checking C of G) the pair of battery was placed a bit more towards the front after not flying for couple of months. This may explain the different performance of motor #4 (rear right). But why motor # 2 (rear left) not perform differently ? Since the C of G is shifted toward the front, should the 2 front motors work harder, or the 2 rear motors work less harder to maintain level attitude ?

The battery voltage is low, like a very low C battery or it’s going bad. You can even see the oscillations at the end where the LED and beeper would have been going off after battery failsafe.

If you think the battery itself is OK and the voltage is good, then do the manual calibration of the voltage sensor. Calibrate at a low voltage where knowing the real value is most important.

Current monitoring is not working - it would be highly desirable to fix that.

Vcc is a bit low, you might want to check or replace your power brick, or at least check connectors and measure the 5vdc input at the flight controller. Voltage at power module 5V output connector is 5.34V which inputs to Pixhawk power port.

Incidentally, I also measured the voltages at the BEC connector of ESC , and found out ESC #2 (rear left) has no voltage output. The other 3 BEC output ranges from 5.02 to 5.07 V. I think that BEC is dead. This does not matter, I think, as either 1 of the other 3 BEC supplies 5V to the output rail for powering the receiver thru the RC IN is OK. Pls confirm.

I’ve heard it said the the 5vdc is not very critical because most of the FC internals run off 3.3v anyway - BUT that 5vdc input is also redistributed to the GPS module and other external units too, such as RC receiver and telemetry radio. Add a couple of more connectors into the mix and the poor old GPS is expected to work off about 4vdc instead of 5vdc. Could you elaborate how and where I should add connectors in the circuit to raise the voltage for redistribution ?

If GPS is good while the FC is plugged into USB, measure the voltage to the GPS then and that’s what you’ll need as a minimum. Voltage at Pixhawk GPS port is measured at 4.84V after removing the GPS 6-pin connector.

Number of Sats is only 9, and HDOP is not great - both are theoretically OK for providing a good 3D Fix but in reality you want better. Maybe fixing the Vcc might help. Probably try to measure the 5vdc at the GPS module and see what you get. Though the measured 4.84V at Pixhawk GPS port is lower than 5V, various online spec for uBlox NEO-6M says 2.7 to 3.3V, some say 5V. Anyway, this failure to change to loiter (Requires position)only happened recently without any hardware change, and I have been flying this quad with this hardware configuration for couple of years without problems.

Sometimes there are just bad GPS days too…I tried on 3-4 different days with same result.

I suggest you set these to help PID and thrust scaling with battery voltage, and the Fence will keep you disarmed until there is a 3D Fix and home can be properly set.Could you explain in detail about this ? I never configure Geofence before. You do stand around waiting for longer but it saves that panic and endless walking of a fly-away.

BATT_ARM_VOLT,11

BATT_CRT_VOLT,10.5

BATT_LOW_VOLT,10.8

MOT_BAT_VOLT_MAX,12.6

MOT_BAT_VOLT_MIN,9.9

BATT_FS_CRT_ACT,1

BATT_FS_LOW_ACT,2

FENCE_ACTION,3 — what will the quad do, RTL or Smart RTL or Land ?

FENCE_ALT_MAX,120

FENCE_ENABLE,1

FENCE_RADIUS,400

FENCE_TYPE,3

PSC_ACCZ_I,0.6

PSC_ACCZ_P,0.3

ATC_THR_MIX_MAN,0.5 — good suggestion

Check the altitude and radius to suit you local laws, or sanity :slight_smile:

Try this for smoother RC input. You can even go a bit higher, up to 0.3 to suit your taste.

ATC_INPUT_TC,0.2 Yes, medium of 0.15 was too crsip for me. I have set it to 0.3.

After all that, I’d run Autotune - the PIDs and many parameters are at defaults and pitch/roll tracking could be a little better. Will do Autotune after things are sort out.

While on the issue of P, I,and D, when I was able to change to loiter mode, the quad sometimes loiter in a relatively fix position which I am satisfied, but sometimes it drifts (no parameters changed before), probably under a light breeze. Could it be the accuracy of the GPS, or what parameters I have to set to make it loiter in a relative solid position like DJI models ?

Here’s a spreadsheet to derive starting values, or connect to MissionPlanner and press Alt A. What is the use of this spreadsheet ? I press Alt A after connecting the FC to MP, but nothing happens.

  [Dropbox](https://www.dropbox.com/s/8u9v3ddph6u9u3t/Initial%20parameters.xls?dl=0)

Initial parameters.xls

Shared with Dropbox

And the tuning process instructions:

https://ardupilot.org/copter/docs/tuning-process-instructions.html

Thank you in advance for your marvellous assistance and expertise.

Frankie

Frankie,

Sorry I am not being helpfull, but…
Please do not quote full posts, just small relevant parts and your answers or questions. There is no point of repeating the post, in this way it’s hard to follow and distinguish your reply from a previous post and having to scroll a page or so.
Thx

I used dronee plotter in this case, but I often use APMPlanner and MissionPlanner too.
https://plot.dron.ee/

Maybe the prop on motor 4 is different?? If the ESC calibration is done, the COG is OK and arm twist is not the issue (CW would be fighting CCW motors) - there’s only so many things that can cause such a difference in PWM to the ESCs.
image

If the power brick is actually doing 5.34v that’s good. It’s a bit concerning that you measured 4.8 at the GPS port and 4.8v is reported in logs - that’s a fair voltage drop in the flight controller somewhere.
It’s like you’ve got a cheap clone pixhawk, where they just used an ordinary diode (0.6v forward voltage drop) instead of using the correct Ideal Diode and power distribution system.
Maybe check all wires from the brick for continuity. If it was me I’d also be trying an additional electrolytic or tantalum capacitor across the 5vdc + and - (even in the power brick cable) to see if that allows the internal voltage to stabilise and come up closer to 5.0. Something like 47uF or 100uF
It might be a storm in a tea cup - I’m a bit of a fanatic for the supply voltages. That’s just me, and voltage is one of the first things I look at. Rotating knives flying overhead entirely via cheap electronics and battery power, no wings…

Don’t worry about the ESC BEC voltages, except that:
a) never connect more than 1 ESC BEC to the servo rail +
b) you only need it if you run something from it (eg: servo) - power redundancy is another story
The RC receiver is powered from the main power input, it’s separate from the MainOut and AuxOut servo rail.

Regarding connectors and the GPS, I just meant that from the power brick to the FC is 2 connectors, then another 2 connectors to the GPS unit, all with microscopic wires - plenty of scope for voltage drop or bad connections.

For FENCE_ACTION,3 you can choose whichever option suits you:

0 Report Only
1 RTL or Land
2 Always Land
3 SmartRTL or RTL or Land
4 Brake or Land

For example: upon fence breach, if Smart RTL cant be initiated, RTL will be tried, if that wont work Land will be initiated. Option 1 is probably what most people would choose I guess.
The main idea is you can’t arm and take off, even in Stabilise mode, until there’s a good 3D Fix.

If you can successfully change into Loiter mode and the craft still drifts, then that is your GPS position wandering, indicating a low quality fix. Loiter shouldn’t drift around at all when it’s working properly.
You could try some different GPS settings and see if things improve. Some old GPS receivers seem to get overwhelmed by the number of satellites and constellations these days.
GPS_GNSS_MODE,3 (GPS+SBAS)
or
GPS_GNSS_MODE,67 (GPS+GLONASS+SBAS)

Hi Shawn,

Sorry for the trouble caused to include your original text. In fact, I used large font and different font to make reading easier,

probably it was reformatted after transmission. See attached screenshot for my original text.

Yes, the Pixhawk is a clone. I am aware of this voltage level of Vcc and am not comfortable about it, but thought

it is not too much lower than 5V and may not cause much trouble. Adding capacitor is a good suggestion.

For ESC BEC voltage, since there is no servo connected to output, I should remove the 5V red wires from 3 BEC cable,

leaving 1 BEC to supply +ve voltage to complete the circuit with ground, right ? Pls confirm.

Will replace the relevant connectors to see if Vcc can be raised.

I will also change GPS_GNSS_Mode to 3, see if it works, as my outdated NEO 6M GPS does not support GLONASS. In fact,

my 2 other NEO 6M GPS do not get 3D fix recently. They were working very well 6-9 months ago.

Thank you.

Frankie

Hi Shawn,

For your info, I managed to change to loiter mode when airborne, just by changing the GPS_GNSS_MODE to 3 without

changing any other parameter, using flight battery at storage level. I suspect there is some fundamental change in

the signal from GPS satellites recently. See attached log.

Anyway, the low Vcc is still an issue to deal with.

Thanks

Frankie

(Attachment 2020-12-20 13-39-39 Binary log.bin is missing)

The attachment was too big to upload in my last email. Here is the link to it :–

https://drive.google.com/file/d/1cGiPGwxujwddwgelZBFlzECgbTRsQgja/view?usp=sharing

no access to the log file

Hi All,
My hex Tarot 680Pro with flight Controller Pixhawk 2.4.7 having Copter 4.0.7 gives same error “mode change failed loiter required position” that too before takeoff, as per my observation GPS is not getting signal,but I am not sure it issue with GPS module or Pixhawk or i miss any setting, because I live in village with full GPS signal for mobile.
Earlier i was using below site to analyze log
https://plot.dron.ee/
Unfortunately its not available now, sharing my log file, please find below link.

Set FENCE_ENABLE,1 and wait for the green LED indicating a good 3D fix, then Loiter mode will be possible.
Set GPS_GNSS_MODE,65 to limit the number of constellations, low-end GPS units cant handle more than 2 and update rate slows significantly.

1 Like

Thanks for quick reply , I was just searching for error in document and found AFS_WP_GPS_LOSS, but that parameter looks retired in latest 4.0.7, i was just planning to enable GPS failsafe to alt hold mode.
Also Shawn, i did not get why it crashed and landed?

It’s a bit confusing around that whole “touched the ground, tried to rise, then move and crash” stage.
The quad is in Land mode for that, and you are over-riding with RC input, so behaviour might not be as expected.
Always just switch to AltHold or Stabilise if strange things are happening.

I think general tuning plays a role. Pitch tuning seems very good, but roll needs some work.
ATC_ANG_RLL_P,3.033925 is very low. Try increasing this to 6 (and more in small steps). If you see oscillations then back it off a little. You should be able to get it up as high as the Pitch value of 9.35.
ATC_ACCEL_R_MAX is quite different to it’s Pitch mate too.

Did you start with the Initial Parameters spreadsheet or MissionPlanner Alt A plugin?
Set this before the next flight too:
INS_LOG_BAT_MASK,1
Just do some AltHold hovering and maybe some gentle movements, then land - let’s see that log.

After tuning is fixed, you might want to check and assess your Land params, something like this for a start
LAND_ALT_LOW,700
LAND_SPEED,40
LAND_SPEED_HIGH,80
then set the speed values based on stability
-> LAND_SPEED_HIGH = maximum descent rate with a slight amount of instability
-> LAND_SPEED = descent rate with total stability, but NOT so slow that landing is not detected
You test the descent rates in Stabilise mode, find the fastest safe descent rate (that you like the look of), then check in the log for what it actually was and use that to set LAND_SPEED_HIGH

1 Like

Tons of thanks Shawn @xfacta, Generally i do auto-tuning, I just installed new firmware 4.0.7 and I am trying to auto tune, but as loiter is not working I could not switch to auto-tune, after auto-tune, we have to land and disarm to save auto tuning values, and its difficult to land in alt-hold mode, I always prefer to have loiter for landing.

@xfacta any way to set GPS fail-safe to switch flight mode to altitude hold, again its risky when on mission, its hard to control when it not visible.

May be setting GPS fail safe to Smart RTL can help, again how it will find home location as GPS already failed.
:disappointed_relieved:

RTL or SmartRTL, in fact any of the GPS-assisted modes, wont work if you lose GPS signal (or comms)
Probably get a more up-to-date GPS unit if you are having trouble.

1 Like

Best to have it set to LAND, decreasing speed and you should be flying out of danger so fail safe LAND is what i would advise for GPS fail safe.

Its based of the FS_EKF_ACTION param. I have it set to 1

Thanks , I am not sure whether its GPS module problem or its Pixhawk, once I identify it, i shall replace it.

After auto tune autoanalysis of syslog result is
No of lines 501088
Duration 0:12:14
Vehicletype ArduCopter
Firmware Version V4.0.7
Firmware Hash 0bb18a15
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = GOOD - [+] Autotune 8284-488069

Test: Brownout = GOOD -
Test: Compass = GOOD - mag_field interference within limits (23.53%)

Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERR found: CRASH
Test: GPS = GOOD -
Test: IMU Mismatch = GOOD - (Mismatch: 0.47, WARN: 0.75, FAIL: 1.50)
Test: Motor Balance = GOOD - Motor channel averages = [1574, 1562, 1577, 1556, 1595, 1537]
Average motor output = 1566
Difference between min and max motor averages = 58
Test: NaNs = FAIL - Found NaN in CTUN.DSAlt

Test: OpticalFlow = FAIL - FAIL: no optical flow data

Test: Parameters = FAIL - ‘MAG_ENABLE’ not found
Test: PM = GOOD -
Test: Pitch/Roll = GOOD -
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - No CURR log data

Auto Analysis is out of data and mostly useless.

From your previous log you have an intermittent GPS failure. GPA Delta should be ~200ms and Status should be 3 or 4. Bad module or wiring.

And those PID’s values look bad.
ATC_ACCEL_P_MAX,50541.74
ATC_ACCEL_R_MAX,37265.85

ATC_ANG_PIT_P,9.356553
ATC_ANG_RLL_P,3.033925

Auto Tune did not do well for this craft as configured.