Arducopter does not work: what i'm missing?

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 ? (http://ardupilot.org/copter/docs/initial-setup.html)
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 ?

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

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

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.

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.

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

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.

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

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

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.

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

“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: …?

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

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.

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.

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

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…

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.

We are professional UAV developers and operators. We have several single-Rotor helicopters in our fleet.

These are high end UAVs not toys. Just as an example the tail servos we use cost £3,500 +VAT for one servo. Yes it is 1500uS centered, all professional grade servos are by default (you can program them if you need to).

We have tested nearly every FC out there. We started with the DJI ACE Waypoint which costs £8,000 we also use the SNAP FC which starts at £50,000 for basic functionality.
If I could justify it, I would rip them all out and UPGRADE them to Ardupilot.

We have at least 10 Helicopters and Multifotors out working daily with Arducopter on Pixhawk, and they are the best system we have ever tested. Nearly weekly we have some issues with the other systems which take time to solve. But with Ardupilot, mostly, theyt just work, and keep on working.
It is the most flexible, versatile system there is, and with this forum the best support compared to any other.

If there is a problem the Dev team or users always solve it.

We are waiting for a Pro Commercial hardware Pichawk, it is ‘coming’, which will make this software / hardware hnds down the worlds best system.

you have to bear in mind the hardware is open and developed for mass use hobbyists, so there are quality issues with some units but this has nothing to do with the Dev team. It is out of there hands.

For quality assurance, use the proficnc Pixhawk 2.1 for now until the Pro system is ready. They are very well built and reliable.

Yes, the commercial grade servos are all 1500uS centered. We will look at implementing 760uS center simply for the fact that some 3D hobbiests get into UAV and want to use their super-hot running tail servos. By far best would be sell them on HeliFreak and buy decent ones. But we have an official feature request for it, so we’ll look at it.