Hello everyone, Im new around here but I hope one day I can contribute to trad heli :)

Ive been flying helis for around a year. Ive got a 450 stretch (480 with 6s and 350mm asym blades) which I'm working on for the last few weeks. Currently I run an MSH brain FBL unit, but I wanna try ArduCopter!! Before I get carried away, Ive got a few questions I hope you could please answer..

1. Can anyone give me their experiences flying with the newest code? I aim to have a solid flying heli that will fly similar to an MSH Brain, but with the added benefit of arducopter (self level etc)

2. I'll soon be running a fixed pitch tail to elimiate the tail servo and torque tube. The tail will be directly driven by a brushless motor with a 6" prop and an ESC hanging off the tail channel. I know that a good FBL unit can be set to run this quite easily. Can ArduCopter do the same?

3. How reliable is the self-levelling currently? I know that the MSH Brain I run is very finnicky to set up, but my experience with MultiWii proves it can be very easy



Views: 1479

Reply to This

Replies to This Discussion

Sorry, what's your radio again?

I have theorized that the bulk of the MR guys are using something other than Futaba, so the problem was rare.  But heli guys tend to spend more money on better equipment, so more Futaba, so more problems.

Again, it's not a problem with Futaba.  It works fine driving 8 servos.  It's just when you try to recombine those 8 signals back into one, it's tricky.

I exclusively use FrSky Rx with PPM Sum output, so no problem.

I'm using frsky D8RII with separate wires for each channel (no PPM sum). Ive never had problems with it till I used APM. I assumed it was the pots failing in the radio, but turns out it was just the PPM encoder firmware :)

Wow, that's really weird...  Never heard of a problem with that Rx before.  I used it without PPMSum for a long time with no problem.

Hmmm... not sure why COLYAW would work in the wrong direction.  The function is "parabolic" (well, linear V, really), it's here:

yaw_offset = collective_yaw_effect * abs(coll_out_scaled - throttle_mid);

So can you compile by yourself?

Here's a weird question for you...

Test flying all weekend I noticed that occasionally my heli disarms itself mid-way through the ESC ramp-up. So to re-iterate, I'll arm, flick the throttle switch and it begins to spool up. Then, when its almost up to speed the motor cuts out. When I look at the red light on APM its flashing indicating "disarmed". Its happened about 10 times now, 2 times after the PPM encoder update.

I'm really scared of it happening mid-flight, but it only seems to happen during spool-up.

What could cause this? I was thinking it might be the "wobbling" that happens at spool-up when the blades arent fully straightened out yet - as though APM thinks there is too much vibration and disarms. Maybe?

PS I tried COLYAW and turns out i needed a negative value. I'm running -3 COLYAW and it handles pitch pumps perfectly now. The problem is that the "heli setup" page wont allow negative COLYAW numbers. I got around that by manually going into advanced params and entering it there.

I can compile code in arduino, but is there a guide for doing it with APM? My only compiling experience is with multiwii..

OK, this is easy.  The system disarms if the throttle stick is on the very bottom for some time, I think it's 5 seconds, maybe 10?  So after you arm, and start spooling up, you have to bump the collective stick up just a smidge to get it off the bottom.

It would be virtually impossible to have it happen mid-air unless you were doing something crazy (full negative pitch for 5+ seconds?)  

This is really something that comes from the multi-rotor side. If you have the stick all the way down, the motors will shut off, you freefall... so you're just not going to do that normally.  Therefore, this is actually a safety measure against ground accidents.  If you arm, but leave the throttle down, and forget that it's armed, it won't sit there waiting indefinitely for the throttle to raise, then jump into life. It'll just disarm after timing out.

More stuff for the wiki! :)

Oh, wow, I wonder if Col-yaw does not get reversed when the servo is reversed...?  Hmmm...  I wonder if you have something reversed that should not be...

Ok, if you can compile for multi-wii, this should not be a problem for you.  There's just a few foibles...

If you try to use "Trunk" right now, which is Post HAL, you need to use some special version of Arduino or it won't work.  I don't know a lot about that right now.  If you want to compile from my fork, then you just use standard Arduino, 1.0.3 or whatever it is right now.  My fork is based on pre-HAL.

I don't plan to move TradHeli development to Post-HAL until after the multi-rotor guys thrash it more thoroughly and work out any bugs.  This may result in a special 2.9.2 trad-heli-only release.  I've got a few functional things I'd like to get out.  Would love to have help on them.

The only other trick I can think of is that you have to work APM_Config.h for your setup.  You'll see a lot of discussion of that in the giant 2.9 for tradheli thread, near the beginning.

My fork is here:


And you HAVE to use the "2.9" branch of that code.  The "master" branch has a bunch of HAL stuff in it, might not even work. 

I don't recommend anybody try flying this without talking to me.  I try to only put working code in there, but you never know.  Manfred was test flying some of my changes at one point.

Interesting stuff. Yeah i'm not planning on trying anything too hectic to begin with so I'll be sticking with whats relatively 'safe' for now (ie your trunk). So if I was running custom code specific to my heli I'd be putting it in a usercode.pde file? That way new releases wont delete it?

I'm reading up on C++ and GIT so hopefully you wont have to answer 1000's of questions lol. 

You're lucky, because we just moved to GitHub, and it's even easier to use than Google Code was.

I use TortoiseGIT as a simple GUI running on top of GIT.  And I use Notepad++ as a simple editor.  And you compile and upload with Arduino.  Whatever the latest is should work.

And there's a pretty good C++ tutorial here:


Plus the info on Arduino.cc

We don't use Usercode.pde much anymore.  I don't think you could do very much useful things with that, becuase the code base is so complex, it would be super hard to tie anything into that anymore.  I suspect that's a leftover of times long past...

APM_Config is typically where you would handle your build options.  Many things are done with parameters now, but some are still done at compile time, such as frame selection.

I think what I'm going to do in this case, is send you a change to insert into virgin 2.9.1, you can compile that. It'll be a little safer.

Grab the 2.9.1 code here:


When you can get that compiling, let me know and I'll proceed.

Just to let you know, I have not forgotten about this. I've started an advanced technicians course, so will be a little tied up for the next 2 months :( One the upside, it has units on programming, microwave and satellite systems and a RF theory so that will be useful for our cause ;)

Ok, no problem.

And just to cross-post this from HeliFreak so everyone here could see:

Yeah, I plan to fix the code so that it's easy to use a motor driven tail. The beauty of open source.  I believe motor driven tails are the future, at least for UAV applications.

So I already figured out how to do this when winding up, and am preparing to do something so Joly can test it. I'm just waiting until he confirms he's figured out how to compile and upload.

But, I didn't consider what to do when landing, using "throttle hold", or when you want to disarm. And to be clear, when I say "throttle hold" I mean setting Ch8 high, with RSC_Mode set to 2, which is meant to run a governor ESC. Setting Ch8 high tells the APM to start the main motor. Setting it low switches it off.

Clearly, we don't want to shut down the tail motor every time we hit TH. You guys might want to practice auto-gyros, or whatever. So how do we do this?

How about this? Currently, the main motor switches on as soon as APM sees Ch8 go 100 PWM above the min of that channel. I can change that to 800 above for all cases. This should not be a big deal for anybody. I bet most already have the Ch8 going full when the switch is up.

Then, for tail motor rotor guys, I can make it so that when the signal is 400 above min, the tail motor will start. So now, you put Ch8 on a 3-position switch. Down is TH, all off. Put it in the middle, the tail motor will start. Put it up, and the main rotor starts. This allows you to start the tail rotor first, then the main motor. You can also shut off the main motor, wait for it to stop, shut off the tail motor, and disarm.

What do you think? I think it's perfect. 

Please, if you see any holes in the logic, let me know.

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service