Arducopter does not work: what i'm missing?

ArduCopter
1

Hi all,

i’m an old quad copter user. Actually i’ve been into RC since i was kid and now i’m working with commercial UAVs, since “beginning” of it. One of my first quad was powered with a very old apm board. Then i flown basically everything quadcopter related, from FPV racing to large professional UAVs. This premise only to say i’m not exactly a “noob”, even if i’m conscious that everything in this world requires some study and trial.

Then, i’m trying to use recent versions of arducopter (>3.0) into some of my UAVs but i think there’s something wrong.
They simply fly like a nightmare. Bad oscillations, difficult/impossible to make even a basic PID setting, difficult to calibrate compass, etc. They looks to me like an noob experiment turned worse.
Then i simply swap the flight controller, put ANYTHING from a cheap fpv racer board (w/any of the open source software avaiable) to an industrial grade $$ worth flight controller into the same frame, and voila. I can fly beautifully since the first flight with any of them. Then i can make a proper tuning in a matter of 2 or 3 flights, with any of them.

If i put back any Pixhawk with any Arducopter version, then i’m back to a barely flyable thing. Oscillations, some commands not working (no yaw, then it turns by itself, etc) crazy oscillations, crazy behavior, difficulties to flash firmwares, slow and buggy connection with planner, i can go on…
I tried different frames and setups, from the F450 to bigger carbon fiber frames, quad and octo.

I even tried it into a large, 700-class “traditional helicopter” just to see how it would perform on it. I encountered some BASIC design flaws into it which made me give up. Just to mention: it can’t manage large digital servos (they don’t even move) due to inconsistences into OS scheduler and different frquency they require on PWM outputs: end of the game, unless you dig into “very creative and dangerous solutions” to make servo move (!!). Not to mention a very buggy and “alpha-stage development state” configuration console and UI, just to set the correct swashplate mixing and other basic things.

What i don’t understand is that arducopter project has turned since years into a very features rich project, with talented people giving their effort to make it cope with industrial grade products and even implementing advanced things like AI, obstacle avoidance, etc.
It looks like a very mature project, with milions of users and hours flied in thousands of uavs all around the world. I cannot believe it’s a gigantic bluff neither people working on it are stupid or inconscious, but still i cannot understand what i’m missing when i go with it.

Can you give me an advice? A video tutorial where a proper flying configuration is showed maybe?

Thanks!

2

A couple of thoughts. The very nature of Ardupilot being usable on so many platforms and with such a rich feature set tends to mean you must tune it for any particular platform. I can tell you that I have built over dozen Pixhawk/APM based vehicles and my first build would not even fly. Now my builds fly very well without any tuning at all.

A prerequisite for a good flying machine is really good balance. Proper treatment and dressing of the high current power lines etc. Things you probably know.

But also Ardupilot hardware is open source just like the firmware. The different vendors that take that design work and create a product differ greatly in how closely they follow the designs. The quality control of assembly and parts quality varies also. So some problems can be introduced by the marketplace which the ArduPilot project has no control over at all.

So getting parts from a reputable dealer, who you can work with for warranty issues, that sell reliable versions is important. Other flight controller close source manufacturers have complete control over that process but some don’t have any better QC and they cost more.

Just my two cents.

3

Hello,
Your problem are weird as ArduPilot is well mature and should work easily even without any tuning on classic frame.
Did you follow the wiki for making your build ? (First Time Setup — Copter documentation)
Can you provide some log of you problem ? and what are you esc ?

About :

Just to mention: it can't manage large digital servos (they don't even move) due to inconsistences into OS scheduler and different frquency they require on PWM outputs: end of the game, unless you dig into "very creative and dangerous solutions" to make servo move (!!). Not to mention a very buggy and "alpha-stage development state" configuration console and UI, just to set the correct swashplate mixing and other basic things.

What servo are you using ? normal servo are 50Hz frequency like esc and that isn’t managed by the scheduler.
“alpha-stage development state” configuration console and UI" ? What GCS are you using ? Mission planner is mature and mavproxy too. Essential information are directly accessible and more are available for advance user. Can you develop more to help us to improve thing that can be wrong ?

4

Tail servo is a Torq BL 9188, swashplate are Savox SB-2274. Of course, they have different frequency rates, and APM/Pix (AFAIK) does not set different freq rates per-servo, rather it has one “global” freq rate, which you have to set manually (dangerous, you can burn servos, usually servos/esc use some “standard” freq like 333Hz, 50Hz etc). Last, changing that number seems to not work, i could not make servos moving. Then, connected a crappy Sparky 2 w/openpilot and they work beautifully, responding to any changes of the setup. Same if i connect a chinese clone of a VBar.

I know that there are prerequisites of a good flying machine. That’s why before putting a Pix onto anything, first i fly it with something else: to make sure the basic things are there, rigidity, weight, balance and so on. That makes my story with Ardupilot even more puzzling to me.

About logs, i don’t have them. Next build i will post here for sure :slight_smile: i think i will try again in short time, i ordered a pixhawk 2 for testing the Here+ gps. It will be another occasion to try to understand the system. This time i will try to be as much methodic as i can go

5

I have never change rc_freq on copter but if it doesn’t work there is a problem. I will look at that signal .

6

Steve.Some of the best tutorials are from Painless360 on Youtube.He starts right from the box up to fully tuned.He also has the old APM and newer Pixhawk 2.1 series along with most of the other FCs ever used.

https://www.youtube.com/results?search_query=painless360+pixhawk

I’ve never flown anything other than APM/Pixhawk and only have problems flying when I’ve had a brain fart during preparation.Forgetting to calibrate the radio is fun (and pretty scary with a 960 hexacopter in the air).I essentially set up each copter three times before it goes up,just to check on myself.

It’s maybe worth mentioning that the Arducopter set ups are not the same as a lot of FCs.I’ve heard of plenty of folk struggling to convert DJI to Arducopter before now for instance.Motor layout and rotation are the usual culprits.

@ChrisOlson ls is your man for the trad heli.He makes it look easy.

7

Servo frame rate is a different topic. But if your servos weren’t moving with a TradHeli, chances are the safety button had disabled the output to the servos.

8

I remember i checked it. Normaly i disable the safety switch

9

A lot of the code in Copter was designed around multi’s. So for heli’s the safety button, crash-checking, disarm delay all are normally disabled. Unfortunately, the defaults don’t come that way for heli - they are set to multi-rotor defaults. The other problem with heli is that we dont’ recommend using any of the setup pages. Make all your settings only from the Full Parameter List, because once again even some of the limits that must be applied to multi’s don’t apply to helicopters so you have to force it to accept the param value.

It’s one of things we just “deal with” in TradHeli, but we’re working on making changes to make it easier. The manufacturers of the commercial FBL units you mentioned have an advantage in that they don’t have to deal with multi-rotor frame classes in their software design, so they can make it heli specific.

10

Thanks Chris.
besides not using the standard pages but the full parameter list (which is my preferred way too), how can i setup different frame rates AND different endpoints for each servo? Other than frame rate, tail servo also has different pulse lenght values than “normal” ones, like 760us

11

The frame rate only determines how many times per second the 1 to 2 ms pulses are sent to the servo. The pulses contain the actual position information. For very demanding applications like 3D you may want to increase the frame rate to 333 (or whatever your servos are rated at). But for UAV you will not be able to tell the difference between 50 or 333 (the default in heli is 125), other than the servo will run hotter and use more power at 333.

It has nothing to do with the position accuracy of the servo. One single pulse can sweep the servo full travel and with the default setting the servo is getting 125 of those per second. That is faster than even the fastest .06 second tail servos can do.

If you have 760us centering servos like the BLS 251, 9251, and 9256 you’ll need to switch to standard 1500us centered for ArduPilot/Pixhawk. Plugging one of those into a receiver or a gyro/flight controller not designed for 760us center will burn it out.

There happens to be a lot of smoke and mirrors in servo marketing. One of those scams is the short pulse length 760us servos in an attempt to run higher frame rates because the standard pulse is 1 to 2 milliseconds. By halving it the number of pulses can in theory be doubled. In the end it’s still limited by servo speed. But it sure works on the marketing end because 99% of people don’t know how it works :grinning:

You set the endpoints for your servos with the SERVOx_MIN/MAX values. But those are only to reflect the servo’s actual operational range, usually 1000 to 2000 PWM microseconds. The tail servo endpoints will be adjusted here to prevent binding of the tail linkage. The SERVOx_TRIMS will be used to adjust and level the swashplate and center the tail pitch The endpoint for heli for cyclic max and min collective and cyclic ring will be set with the H_COL_MIN/MAX and H_CYC_MAX parameters. With the H_COL_MAX/MIN set to your desired minimum and maximum collective pitch, the H_CYC_MAX set to your desired maximum cyclic pitch in centidegrees (default 2500).

If it is possible for you, I’ve found QGroundControl is easier to use for setup of a heli because it shows the param values by their name instead of having to enter (or figure out) what the number is for some of the parameters. And it does not have any “hand holding” setup pages that can make unwanted settings to a helicopter. It only allows changing one thing at a time and won’t let you leave the entry field until you either cancel it or actually write the change to the flight controller. I think it is a very well designed ground station and even loading firmware is easier with it. Be aware that when you load firmware there is only two builds now for Copter - the multirotor build and heli build. If you accidentally load the multi-rotor build for a heli NOTHING will work.

1 Like
12

Chris, thanks for reply.

You basically told me that 760us servos are unsupported. I take it as is, but this confirm my thoughts about the arducopter project as higly immature in some basic areas. Pls take it as a costructive concern. I also must point out that nowadays every tail servo which decent performance is 760us, and despite market is full of useless claims, it’s easier to find a good 760us tail servo rather than “adapting” a 1500us one to that task, from my point of view.

Back to pulse and frequency topic, i can see the frequency is not critical (well, maybe could be in a flybar head, but this is my opinion) but the problem is that servo are not moving at all, not a lower performance concern.

13

No, the best tail servos are 1500uS. It would only take a few lines of code to support 760 but there’s no sense to using high frequency narrow band signalling, super power-hungry servos on a UAV.

Please enable logging without being armed and we can take a look at your problem with the servos not responding. There’s a few things that can cause that, including no power to the servo rail.

1 Like
14

“No, the best tail servos are 1500uS” : Chris, sorry but this is your personal opinion vs a de facto industry standard. Which btw is supported by most open and closed source FC project, like Librepilot to mention one. sorry to hear that but i find it very unhelpful.
Also, i cannot understand why it doesn’t make any sense. Normally i take a fully built up helicopter which has its own suggested servos installation, it has been flown (with a FBL system) and its setup is fully proven. Now, i normally take out the FBL FC and put a “fully loaded” FC like pixhawk. Since your advice i would dismantle it, spend money on new gear, and then tune it up, etc. Just because “it make sense” :wink: …?

15

Well, the history of the 760uS servos goes back to Futaba, which invented them to lock users into their ecosystem of using their gyro’s etc. This gets back to an old engineering adage that the best engineered products rarely succeed in the marketplace - the best marketed ones do. So some other manufacturers jump on the bandwagon because with good marketing you can sell beach front property in the Sahara Desert.

The Pixhawk/ArduPilot system is an autopilot, not a FBL unit. Just like your radio receiver, we have no need to support 760uS centering servos. Because we have, if you want, the capability to run a downstream FBL unit handing whatever unique combo of stuff you want to run. Including four-servo swashplates, 760uS servos, dual governors, etc. etc… And have the quite excellent autopilot handle navigation and attitude commands while the downstream FBL unit handles rate control and whatever features you want to run with it. No other autopilot can do that. Take LibrePilot, for instance - it does not even have a rate velocity feedforward feature nor does it support flybar helicopters. And it’s autonomous navigation capabilities don’t work with helicopters at all. I’ve tried it on a Revo and the code would basically have to be re-written from scratch to even come close the functionality of ArduPilot running in a Pixhawk for TradHeli.

I would not recommend running narrow band servos on a UAV that gets a lot of flight hours. They have 3x the failure rate of 1500uS because they run so hot. They simply do not stand up to 40 minute UAV flights and I’ve personally burned out two BLS9251’s trying it, with a downstream SK540 that I bought for my Velos 880.

But yes, that’s just my opinion. I suppose forged from my experience with it.

Please post that log and we’ll take a look at your servo response problem. I would like to look at the inputs from the RC and the outputs on the servo rail. I can extract the params from your .bin log so no need to post the params.

1 Like
16

ok, tright now i’m using an F450 as testbed for newly arrived Pixhawk 2.1 with Here+ and latest 3.5 quadcopter build.

So far, thing have gotten much better. I can make it fly smoothly. Something is still in the “can be improved” area, but it’s very flyable.

The main issue i see (flight related) is the yaw behaviour: when i input small yaw corrections, acceleration is very slow, hence command is very slow. If i take full yaw, it becames very fast so absolute yaw speed is not the problem, rather the acceleration. I tried to play with ATC_RATE_FF_ENAB and ATC_RAT_YAW_FF, making yaw very responsive BUT making big glitches in altidude holding and also making it not keeping heading but returning to initial heading prior to the input, like yaw heading has a “spring” effect.

17

Take a look at your RC4_DZ. I believe it is set to 15 pwm by default (I think that’s the default in heli without looking). This provides 15pwm on each side of stick center which will require more stick movement to get yaw response at first part of stick movement.

Another thing is your mechanical setup. The mechanical rate is not linear. You can speed up response of any servo by changing the throw on the servo horn. With the servo centered the fastest mechanical rate is on each side of center. As the horn travels the mechanical rate is slowed as it reaches full travel due to the fact that it travels in an arc. So one degree of servo shaft rotation does not translate to the same pushrod travel at center as it does at full travel. If you are using, for instance, a 10mm throw on the servo horn it’s going to be slow on initial acceleration, but will still achieve very high angular rate.

Another thing is your radio setup. Do not use any expo or rate multipliers in your radio or you’ll get exactly what you describe.

Final thing is tuning. Rate P could be low - I’d need to see a log.

Do you have a log showing this effect? There is no feature that returns yaw to a particular heading after an input. A stick input moves the target (or “ghost”) and it will chase the ghost and lock onto the new target after you stop stick input. The yaw on heli’s typically requires more P gain and quite a bit of D gain to make it crisp. So that sounds like a tuning problem.

On the altitude holding, you’re likely inadvertently moving the collective with full stick travel on the rudder. The log will tell me that.

18

Sorry Chris :slight_smile: i think there’s a misunderstanding: the “F450” is a small quadcopter, 450 class. Now i’m making a couple of flights with the two settings to show you logs

edit: here they are:

https://drive.google.com/open?id=1nDee-_WLfF-qVC7wl7l25KPmxN6iXQFY

https://drive.google.com/open?id=1JFGl05OSjPI8dvNq4Gze6XE04DiXAEI6

the first is the slow yaw, second is snappy, bumpy alt and and “sping loaded” yaw :). Difference is ATC_RAT_YAW_FF = 0 in the first, 0.5 in the second

19

Chris, in the meanwhile, i got a little bit more confident with ATC_RAT_YAW_FF (set at =0,25) , ATC_ACCEL_Y_MAX (54000) and ATC_RAT_YAW_P ( = 4,5) and now the thing is way more i used to, yaw is a middle between snappy and solid. Maybe i’m getting closer to my expectation…

20

Ooops! I thought I had seen Trex 450 :hushed:

I’m a heli guy and not real well versed on multirotors. But I’ll look at your log and see if anything stands out. But it would better for one of the multirotor experts to look at it.

Sorry about that. What I do know about multi’s is that in a fast yaw it requires differential torque or “throttle” to make it yaw. So if you use high amount of yaw authority, the throttling of the motors can make it possible to not have enough “overhead” to maintain altitude. But we better let one of the multi guys take a look at that.