ArduCopter 2.5 released!

John Campen June 16, 2012 at 9:08am

does this version of MP still require Net framework 3.5? One a new laptop I'm having trouble installing UARTS and the ports aren't showing up in MP

Developer

Randy June 14, 2012 at 5:29pm

2.6 is released! All aboard on the 2.6 release discussion here!

Developer

Marco Robustini June 14, 2012 at 2:59pm

The video of the 2.6 final version is on my youtube channel...
In the description the specs of my quad.

Bests, Marco

John Hanson June 14, 2012 at 2:51pm

I have gone through several batteries on 2.6 Epsilon (quad 10x4.7 apm2 880kv)- so far-

Altitude hold now fixed, can add or remove weight and it holds well. I did increase AH P to .9, rest all default.

Have not seen simple mode problem that was in last version

Loiter was best I have seen lately, maybe 2m drift at worst (low wind)

Yaw seems OK, did not twist on takeoff

The latest stable mode is remarkable. I have not bothered with autotrim, balancing blades, or any of that nonsense and it will hover motionlessly in no wind- even better, it has the best sound I have heard. How they sound in low wind is a big clue to how well it is working.

I did try 12x3.8 blades and the default pids left me with a little oscillation. I tried lowering a bit and it got better, but the 10x4.7 with pids at .18/0/.04 is still the best.

Gustav Kuhn June 13, 2012 at 10:45pm

Over 100 000 views, and many replies.

I'm waiting for my new 2560 board, to join in the fray, but reading about many frustrated builders out there, I'm close to giving up.

I haven't had any funnies on the rather short flight I'm doing, but then, I haven't really done much in the line of nav or position hold lately.

Maybe the code is getting too complicated ?

Cam ship people require basic stability, and maybe nav/rth.

I would be happy with that, I don't need Simple mode or Acro.

Fancy lights and maybe camstab can also be left out, on a big 'copter with professional stab gear, it can have it's own stab electronics.

Not venting, just throwing around some thoughts.

And impatiently waiting for my 2560 board.......

Developer

Randy June 13, 2012 at 9:22pm

ArduCopter 2.6 Epsilon is now available in the downloads area for beta testers. Hoping that this is the final version that will be pushed out to the Mission planner.

A couple of things to be on the look-out for:

a) Please try Simple Mode. The copter should not spin.

b) Empty dataflash for some APM1 users. We have one report of this (from Dean) so I'm interested to see if anyone else has seen this. It's possible that it could be a dataflash hardware problem exposed because of the new method we're using to erase the dataflash.

thanks for your help!

Changes from 2.6-Delta:
   - throttle range improvement (higher min and max) [Jason]
   - improved standard Loiter PIDs [Alan, Heino, Jason, Angel]
   - restored standard yaw control [Robert/Randy]

Improvements over 2.5.5 include:
   - Stability improvements especially during level hover [Jason]
   - MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]
   - dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]
   - Copter LEDs [Robert Lefebvre]
   - RTL loiter stage target set to home to improve final landing position [Jason]
   - flip & acro improvements [Jason]
   - circle mode target improvement for ground station [Jason]

Bug fixes include:
   - UBLOX driver fixes (lock should now be more reliable) [Tridge]
   - enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]
   - proper printing of lat/lon values in dataflash logs [Randy]
   - removed duplicate GPS reads [Jason]
   - resolve flooding of telemetry link with low-battery warnings [Tridge]
   - RTL bug would land if rtl_approach_alt was more than 1 [Jason]
   - WP Radius could not be set larger than 1.3m [Jason/Randy]

-Randy

Rob_Lefebvre June 13, 2012 at 7:00am

Glenn, we're probably going to back out the yaw change that I made. The delay you are seeing is easily understood, and it's fundamental to the way it now operates. I liked the feel, and Duran liked it, both of us have similar goals: Aerial Photography. The yaw is now very predictable, but also slow. It's not going to make everybody happy.

So, I have plans for a new control algorithm that will combine the best features of the old, and the new. I talked with Randy about it last night and he likes the idea. But it probably won't make 2.6 at this point.

Unfortunately all my helis are broken at the moment so I can't test my own code. If anybody wants to try some alpha changes, drop me a PM and I'll send you some patches to plug in. But you have to be prepared to patch in the changes, compile, and then fly something that... may not work at all. ;) It's totally up to you.

Now, in terms of that oscillation, it has nothing to do with your mechanical setup (or not likely, anyway). The problem is what's called "transport lag". Basically, the servo has to *move* before the yaw torque can change, and that takes time. How fast is your servo? Yours seems to be really severe. You need to have a REALLY fast servo for yaw control, mine is 0.06 sec/60°. So I have a change that I already did to the TradHeli that will help the Tri the same way. It's just a little bit of help that doesn't fully solve it.

Although, your oscillation is so bad, I really wonder if your Yaw_Stab_P is just way too high. Did it get worse when you turned it up?

Ayush Gupta June 12, 2012 at 10:19am

Hey guys dont know if its the right place to ask but could someone help me with PID parameters for the following:

DJI F450 Flamewheel Frame

10x4.5 Props

880kv jdrones motors

I have been trying to tune it but it is getting worse so please help!!

Rob_Lefebvre June 11, 2012 at 7:41am

Some notes about yaw control for anybody testing 2.6beta (or gamma or delta... whatever it's called now).

What do you guys think of the new yaw control? I am not sure if you saw it on the dev list or not, but I revamped the Stab_yaw controller. I don't know if it's perfected yet, but it should be much more "predictable". Basically what used to happen is that when the yaw stick was centered, the yaw controller tried to hold the current heading. That's cool. But what wasn't cool was that there were a few reasons behind the scenes that it was not in fact holding the correct yaw heading, particularly for TradHelis. There was a steady state error, but the pilot actually wasn't aware of it. You might think the AC was holding 0° due north. It would look like that to you, but behind the scenes, it was actually trying to hold (just as an example) 5° to the right, there was a constant error.

The problem is with the way it handled yaw commands. Basically, once you touched the sticks, once yaw input was anything other than zero, it would "accept" whatever the current heading is, and then try to yaw at a rate determined by Yaw_Stab_P (not what you'd think!). It was always updating the Nav_Yaw setpoint to what it currently is, and then there was a rate that was sort of added in.

So if you had a 5° steady state error, as soon as you touched the stick, moved it just a bit, it would accept that error as the new target, and so it would offen yaw to face 5°! So you could touch the yaw stick just a bit, trying to push it left, but instead it would move right 5 degrees! This was driving me nuts.

So what I've done is change it so that Nav_Yaw never accepts an error. And the stick input does not go to a rate determined by Yaw_Stab_P. Now what happens is that Nav_Yaw setpoint is always held, even if there's an error, but the Nav_Yaw target moves at a fixed rate determined by stick input. So if you have a 5° steady state error, and you command exactly 90° movement, it moves exactly 90°. It does not accept the error, and then move.

It is very important that you will all need to go and really crank up Stab_Yaw_P. This no longer controls the rotational speed of the aircraft. The rotation speed is hard coded to the stick angle now, and should be about 90°/sec at full stick. You need to crank up Stab_Yaw_P as that allows the AC to keep up with the incoming yaw commands. Basically it should make it sharper. I used to fly with Stab_Yaw at 2.5, and I've gone as high as 7 now with no instability.

It's important to do this as it increases the "sharpness" with which the AC will follow the yaw commands. If Stab_Yaw_P is low, it will be "loose" feeling, and you may even see a bounce-back after you let go of the stick.

On my helicopter, I ended up with really really great yaw control, check it out:

But one very important point to note in all this:

When the stick is all the way down, it accepts whatever the current yaw is. So you can walk around, set it down, arm it, and it will not try to move unexpectedly. BUT! Once you arm it, and then soon as to raise the stick even a little bit, that yaw controller is active. If you are still on the ground, armed and motors running, and you touch the yaw control, it will move the target. It will try to move, but it can't because the thing is on the ground. As soon as you lift off, however, it will yaw to the target.

It's an unfortunate side-effect, but I'm not sure what to do about it at this point.

Also, at present, the maximum yaw rate might be lower than people would like. The rate is hard-coded to be linearly variable with the yaw stick input. In the future, this will probably be a parameter, but just please bear with us we work through this. I tried to set the default to some happy middle ground, which is what you see in my video. Marco has already hacked the code to double the rate, and still wants more! ;)

Now, what's really awesome about all this, is the yaw control with my heli was so completely terrible before, that I had been assuming that it was the compass that was wrong, because the heli was always doing these really weird things. Just seemingly had a mind of it's own and it was all I could do to control it. Now it's rock solid, and I have learned that the compass is actually darn near perfect.

I should also say that be using some of the "best practices", I've managed to get a completely negligible effect from electro-magnetic interference. So it is possible.

Gustav Kuhn June 11, 2012 at 1:47am

Any features I can switch off to make 2.6 fit on a 1280 APM1 board?

Discussions

ArduCopter 2.5 released!

Replies

Activity