Why start in stabilize mode?

I’m assembling a quad using the Pixhawk 2.4.8 loaded with FW 3.6.8 on an F450 frame. My previous experience with quads is limited to flying a Syma X25PRO, and many years ago I flew fixed wing model aircraft, in the old times of glow plug engines and “digital proportional” radios on 72MHz.

I want easy, comfortable, stable, highly assisted flying, mainly for filming. Acrobatics and racing are not in my range of interest.

My question is: Why should I include “stabilize” as one of the flight modes, and start in it? The docs stress this point a lot, but I couldn’t find a really good reason. I feel uncomfortable with the idea of having to keep the copter in the air without much autopilot help, and would much prefer to start in “loiter” mode. If I carefully callibrate the accelerometers and mags on the ground, and have a good GPS signal, what’s wrong about starting in “loiter” mode, and in not even including the “stabilize” mode among the 3 flight modes I will have?

Given that my flying area is full of obstacles (trees and terrain), I was thinking about having “loiter” as the standard flight mode, and “RTL” and “smart RTL” as the other two. Is this workable, or why must I have “stabilize” as one mode?

Loiter is a great mode … , untill you lose GPS or get a GPS glitch.
An “area full of obstacles (trees an terrain)” will almost always have GPS issues.

Stabalize is a fallback mode, so that you just need to fight against the wind, instead of figthing against an invisible GPS signal drift.

1 Like

Hi Manfred @Manfred,

Just like you I am in a way very afraid of using stabilize mode, my hands are a bit shaky (I m 60) and my flying skills aren’t that great either.

However, for the first trials you should engage stabilize mode and start very gently pushing the throttle and watch how the quad reacts i.e does it try to flip to the sides or forward or backwards. The sound of the vehicle. And all that can be detected even before the vehicle leaves the ground.

If you followed all the initial settings instructions including the spreadsheet from @xfacta than I honestly believe you could engage loiter and fly.

Just my 2 Cents
Gal

But you should always have stabilize mode memorized on your radio, this is your last chance of saving big bucks in a worst case scenario as explained by @amilcarlucas

Thanks for the input.

So, if the main problem is the risk of the GPS acting up, requiring GPS deactivation to regain control, would it be acceptable to use AltHold mode instead of Stabilize? This would at least keep automatically controlling one axis - the most important one!

My old fingers are still reasonably steady, but my eyes are no longer very good, and my equally old brain can be a bit slow to react… That’s why I think that Arducopter will do a much better job than I can do. It’s younger and quicker! :rofl:

1 Like

Stabilise is your safety net, which is especially true when you are building and test flying.
In any other mode (except acro) you are relying on sensors to do the guiding.
After you have test flown and tuned your build then you can go the route of checking AltHold works, then Loiter, and you are good to go.
But always have Stabilise as a flight mode for the ‘just in case’ times.

For instance, you mentioned AltHold, but if you have bad vibrations, especially in the Z direction, you craft will likely take off and keep going vertically.
How would you get out of this situation?
Switch to Stabilise.

I fly a large Octo each month at a power station and the winds have on at least 2 occasions overpowered the guided mode (the copter does a full auto mission for stockpile mapping) and I have had to switch to Stabilise to bring it back.

You are asking for advice from experienced flyers and builders.
This is our advice and thats why its in the Wiki.

1 Like

@mboland
@Manfred
I’m another vote for stabilize. I take off in stabilize to a height of approx 10m, recheck that all the controls are working correctly, switch to alt hold while still hovering, and only then switch to loiter. Saves lots of surprises like GPS interference, reversed elevator etc.

1 Like

As everyone else has said, having stabilize is critical as a backup. Can I recommend having the following setup?

Channel “5” (Three-Position): Stabilize, Alt-Hold, Loiter
Channel “6”: RTL
Channel “7”: Smart-RTL

The channel numbers are just there for reference - you can setup whatever channels you want. This way you have control of more flight modes. I rarely use smart-RTL, so I put that switch to Emergency Stop - but that should work for you.

1 Like

Well, that’s exactly why I asked. I will take your advice and include Stabilize in the selectable modes. I will set up a mode switching scheme as proposed by Manav.

I just feel a bit uneasy about having to control the quad myself in 3 axes. I fear that reflexes honed in my times of fixed wing model flying will take over, and I will crash the quad before even having time to think of why it’s moving the way it does…

One question remains: Why would vibrations make the quad go off vertically? For all I understand, very bad vibrations could make the accelerometer saturate asymmetrically, and thus cause a serious error in the average value it gives. But the altitude hold uses the barometer as main sensor, right? I don’t see how the average output of the barometer could get affected by vibrations.

Anyway I intend to measure the vibrations, and take corrective actions if necessary, BEFORE I try to fly.

1 Like

You basicaly have it right. Acelerometers saturate there limits, typicaly ±16G. The more they saturate the closer the average becomes to zero. This is not a issue in X and Y as we are expecting to see 0G however we expect to see 1G in Z. Less than 1G means falling so the copter used more throttle to counteract, typically making the vibrations worse, and you never see it again. Having said that we now have a vibration fail-safe to try and catch this.

The barometer cant correct because we are not using only the barometer, the vehicle relies on a extended kalman filter (EKF) to combine the readings from all the sensors. Barometer is only accurate to about a foot or so, if we were to use only the barometer the vertical hold would be very loose with lots of drifting up and down. Adding the acceleration allows the EKF to compensate for this. Typically the accelerometers are more trustworthy sensors than the baro hence they are trusted more, the new vibration failsafe tries to spot that vibrations are causing the accelerometers to give bad readings and tells the EKF to stop trusting them so much and rely on the GPS and baro more.

To weigh in on the debate, you should certainly use stabilize as the first test mode for a new vehicle. There a several simulators for quadcopters that could could build your confidence. Using RealFlight you can even fly ArduPilot and get a feel for the various modes and options.

https://ardupilot.org/dev/docs/sitl-with-realflight.html

Peter, I don’t know anything yet about EKFs, but I do know about barometric sensors, accelerometers and such, having designed circuits that use them.

When an accelerometer reads -1G in Z, and zero in the other axes, that doesn’t mean that it’s at a stable altitude. It only means that it’s not accelerating up nor down. But it still might be climbing or falling at a constant rate, even a very high rate. If it reads -0.5G in Z, that doesn’t mean that it’s sinking. It just means that it’s accelerating downward. It could actually be climbing, but decelerating the climb.

Barometers are very reliable sensors for absolute altitude, in the time frame of quadcopter flights, but they are too noisy and thus too unstable to quickly measure very small altitude changes, or to derive stable accurate, fast-responding vertical speed or vertical acceleration information.

So it makes a lot of sense to combine an accelerometer and a barometer, taking the acceleration directly from the accelerometer, the altitude directly from the barometer (with proper compensation for the atmospheric pressure/altitude curve, and a low-pass filter to reduce the noise). The vertical velocity might be be obtained by combining both with some weighting, after derivating the barometer signal and integrating the accelerometer signal.

A GPS is less stable for altitude than a barometer, but is largely free from weather effects, so it can be used for long-term altitude calibration of the barometer. I don’t know really how good the vertical velocity data is, for a modern GPS receiver. The old ones I worked with very quite lousy in this regard, But those used only a few sats for a solution, while modern ones use many sats.

All this long wording is just to support my claim that barometers should not be considered less trustworthy than accelerometers! To know at what altitude we are, several minutes into the flight, an accelerometer is completely useless. Any calculation based on accelerations measured throughout the flight would be extremely inaccurate. Likewise, of course, trying to fully stabilize the altitude just based on a barometer would be a poor approach, because the craft would try to follow the noise on the barometer’s output.

So I claim that if the barometer is duly considered in the calculations, and fully trusted for altitude, the craft should never shoot up and out of sight when the accelerometer is acting up due to vibration.

In a very simple altimeter/variometer I built roughly 20 years ago, using one of the few barometric sensors available at that time, averaging the sensor’s output over one second produced a noise of less than 20cm altitude. With longer averaging, the altitude resolution can be improved to the centimeter level. Uncompensated thermal drift is about -4 meters from switch-on to stabilization of this particular circuit. Altitude oscillations caused by a storm forming eddies around buildings can be as much as 15m, but nobody would fly a quadcopter in such conditions. Between one day and another the weather-induced altitude change can easily be 100m, and this is where GPS comes in…

Eventually I will have to look into EKFs, and maybe into the Ardupilot code, to better understand what you guys are doing. The reports about quadcopters rocketing up and getting lost because of vibration interfering with the accelerometer, and the accelerometer being trusted more than the barometer even in that situation, ring an alarm bell.

Anyway, I have now set up one switch to select between Stabilize, AltHold and Loiter, and another to override that and go into RTL mode. And I will pay a lot of attention to having low enough vibration, before I try to fly this drone.

I looked into Realflight, but seeing that it is commercial software turned me off. I’m in the process of weaning my computer from all commercial software, in favor of free, ideally open-source software. And if it’s portable, that’s a plus too! But the idea of using a simulator to get a feeling for manually flying a quadcopter is a good one. I will see what I can find.

Arming in Stabilize mode has a big advantage:
Just spooling your props (Not taking off) let you check roll and pitch from your transmitter before taking off in whichever mode you like.

This will certainly avoid castatrophes :wink:

I always take off in position hold or Loiter or sometimes in guided mode… But I always triple check roll and pitch axes before… :slightly_smiling_face:

Cheers
Henri

One other approach that I have used after a couple of rough starts building a hexacopter is to use a much smaller battery than I intend to fly with normally. I usually plan to fly a 4S 5000mAh, but for testing and initial learning I switched down to a 3S 2200. Still lots of power to get in the air, but much shorter flight time. In the event of losing control it limits how far the bird can fly. Rocket like climb rates are tamed.

I am also now a believer in the first flight being in Stabilize. Flying without automation is not so difficult.

Best of luck!
Doug

When I did my first flight ever with a quad, the Syma X25PRO, it started OK but after a minute suddenly stopped reacting to all control input, flew away and crashed into a tree. Wisened by that experience, I did all of the following test flights with the Syma tied to a leash! So it couldn’t fly away again. The worst thing that can happen on a leash is crashing, and with a very lightweight quad like that one, on tall grass, there is no damage. At the worst the the leash gets tangled in a prop.

This method of flying on a leash allowed me to diagnose the problem in the Syma, and fix it: A diode had been badly placed in a crooked position and soldered down with only one end connected. After fixing that, the Syma no longer flew away, and I could release it from the leash. But the only thing the Syma was good for, in the end, was to open my appetite for a more serious quad.

I intend to fly the new one on a leash, too, at least during the first test flight.

At this time I’m still building, setting it up, learning. It will take some more time before I make that test flight. While setting up the OSD I found that my radio doesn’t have an RSSI output. That’s a downer. But then, I don’t plan to do long-range flights, so it should be OK. Otherwise the OSD is looking nice now, with the pieces of information I need nicely grouped by function or area in the 4 corners of the image. The next step now is building a gimbal for the camera. I bought the motors and controller, and will make the brackets.

The worst part so far is the frame. I bought an F450 frame from China, and I find it very heavy, with weak areas in the center plates, and really there are no good places to fix the electronics and the battery. Everything is supposed to be taped, glued, tied, strapped to various parts of the frame…? It’s very primitive. I might end up building my own frame even before the first flight.

Also the motors I got are poorly balanced. They vibrate a lot. I haven’t measured the vibration yet, as it doesn’t make much sense to measure it without the props, but just with my hand on the frame I feel an amount of vibration that I hadn’t expected, when running the motors without props. Looks like there is more work to be done before the first flight.

Regarding the flight modes, it’s pretty much settled: Stabilize, AltHold, Loiter, and a separate switch for RTL. Thanks for all the input on this, all of you! But I still have one doubt: What exactly does the Stabilize mode do with the throttle? From the documentation, I would have thought that with no props I should be able to run the motors from zero to max speed, proportionally, from the throttle control. But obviously this doesn’t happen. Instead the controller does something, which makes the throttle control have no effect beyond mid position. Also there seems to be some slow integration effect, running up some motors and running down others. I suspect that the stabilization system is trying to exactly level the quad before allowing it to take off fully. Is this true? It’s surely fine, I just would like to understand what’s happening there.

1 Like

Hi @Manfred, actually you answered it yourself, no props, motors can’t work correctly.
Your only option is to use MP motor test function on each motor.

Do you mean that this is just torque-mode vibration related to lack of rotational inertia, rather than motor imbalance? That would be good news.
Eventually I will get to trying with props on (and tied down), and do systematic vibration measurements.

1 Like

Maybe before you might want to do CompassMot