Jason is travelling this week, so I'll take the helm for the next software release post. 

UPDATE: the motor remapping thing was confusing everyone, so we took that out and returned to the regular motor mapping. That means that APM 2 users with Hexas and Octos should wait for the next version. APM 1 users should be fine with any frame.  

NOTE: Hexa and Octo users: there have been motor mapping changes that may affect you. Please don't upgrade until we can update the documentation to reflect the changes. This should happen by the end of the day today (Feb 1).

ArduCopter 2.3 is now available in the Mission Planner.  This is the next revision of the ArduCopter 2.2B6 code, which is perhaps the most tested code we've ever released (1288 comments in the thread!)  and certainly in my experience the best code, too. 

The default PIDs are optimized for a 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props, start by turning down Rate Roll P (default is 0.14, so start by turning it down to 0.1. In general tune PIDs in 25% steps).

Now that we've got solid code out there, we can turn to collecting suggested gains for standard frames, and a better guide to how to tune PIDs for your unique setups. 

Here are Jason's note on the latest changes (mostly from 2.2B6)

A dampening term called STAB_D has been refined. A D term for all of the Rate based control loops has been added based on Igor's work. Landing for Baro and Sonar has been refined based on JLN's work. A slightly new approach to Loiter and Navigation is being used to try and linearize the pitch and roll for rate control. It tends to use lower gains, yet has a more assertive response in the air.

STAB_D : This is the gyro accretion dampener. This can remove small wobbles during sharp changes in angle commands. Making this too high can have a negative effect in performance and add a memory effect that can cause temporary loss in control. The in flight tuning is ranged so you are just below that effect.

If you haven't noticed before the control loops are in two stages. The first is a PI stage that converts some sort of position or angle error into a desired rate. These generally do not need to be tuned. They are more of a user preference on how fast you want the copter to perform a motion. 

The second stage is the actual PID loop that needs to be tuned for the copter. This converts the desired rate into a motor command of some sort. I added a D term based on Igor's recommendation to the PI's for each rate controller. These should show up soon in the mission planner for the release. I cannot give you a concrete answer for how to tune the D terms, because they each depend on their function such as alt hold or loiter, etc.

Still, the absolute most important term is always the Rate_P term for each loop. Start tuning here.

The default PIDs are in the what flies great for a stock jDrones/3DR Quad with the purple motors in X mode.

Note the Mission Planner does not yet highlight these D terms on the main tuning page (it will soon), but you can find them and modify them on in the Parameters list.

Autolanding should now work well (see video above) and the Tri servo issue is now resolved. 

The code should now compile with Arduino 1.0 (thank, Randy!), but remember that you need to use the "relaxpatch" version of Arduino in our downloads section

[Update: we've reverted the below. See update at the top of the post]

Important for Octo users:


We've changed some of the motor orders for some more exotic airframes. We'll be updating the docs on the Wiki in a day or two to reflect this. Pat Hickey explains:

As before, the hexa plus APM2 motor setup has changed from the ordering [1, 2, 3, 4, 5, 6] to [ 5, 6, 1, 2, 3, 4 ].

The Octa V layout for APM2 is:
6            4
  2        5
    8    1
      3 7
Motors 1 through 4 spin clockwise, and 5 through 8 spin counterclockwise.
Support for roll/tilt camera control on APM 2 should be coming in the next version. Traditional Heli will also be updating to this latest code as well once we track down a memory issue. 
As always, you can see a complete list of changes in the changelogs.

Views: 54192

Reply to This

Replies to This Discussion

Comparing stock params with maxed out PIDT1 tuned params.


For info the 'tuned' params found below are reluctant to play ball on anything other than a very well balanced, vibration free airframe, or one with a very good APM mount. Vibration seems to be a factor in causing 'the twitches', especially with some Rate_D dialed in. I have improved mine dramatically with my new mount (see earlier) and checking the quad over for any imperfection/imbalance. This has helped me, at least a bit,  to increase Rate_P and Stab_P dramatically with the Rate_D term without the oscillations I would have experienced if using Stab_D instead at these higher levels of P.

 

The two flights in the video are set up on a stock arduquad frame, +mode, jdrone escs 20a and 850kv motors, 10*4.5 props, sanded and balanced (they are cheap though, saving the good ones for the field ;) lots of balancing and vibration damping.

 

Arducopter v2.3 Stock params vs PIDT1 style tuning from Kamakaze UK on Vimeo.

 

Flight One – easy to fly indoors, very smooth, gentle reactions. Stock parameters that come with MP version of 2.3. All I have changed to suit my frame is;

Stab_***_P to 4.2 from 4.5

Rate_***_P to 0.13 from 0.14. This is the point where I lose all oscillations.

Stab_D set as default 0.12

Results: Quad flies really very well – perfect for AP, FPV and just general smooth flying. It seems to me all that anyone would need to do to for a pleasant stable flight with this would be to dial your rate_***_P and stab_***_P in for your frame. I think most of us are really really happy with this release – GREAT STUFF!

Flight Two Default params then...  PIDT1 style tuning.

Stab_D set to zero.

Rate_D at 0.012 (start at 0.004 then work up till you see tiny oscillations at half throttle when tipping it over in your hand.

Stab_P to 7.5, (i could go higher but it becomes too aggressive for my liking – stable but aggressive, i did try 12, but think I need a field...

Rate_P to 0.23 (as high as i can go before oscillations set in (slow over-corrections to stick input is actually a more accurate description) in real life I’d probably come down a bit, but this is a test...

Rate_I of anywhere between 0.08 and 0.120, as long as it’s between 25 – 50% of rate_P it seems to make little difference. Outside this range i have noticed sluggishness.

Results: Still very easy to fly indoor but reacts much more quickly to stick input, external reactions (pushing it with your finger – and I’m hoping wind) and return to level much quicker when you release the sticks. (I’ve had to put a bit of expo on my Tx for the first time on this quad, I’ll be reversing that out in the field though ;)). In the vid I try to push it a bit, but with the tuning it’s quicker than I am in this small space, hence a little blanket tapping with the props at the end (good prop saving tip – blankets everywhere.)  But I think you can see how ninja-like it is. I’m hoping this speed of reaction and stubbornness to stay completely level at mid stick will make my loiter and nav set up a whole lot more straight forward.

It will probably knock it all to cock ;)

Something for your bedtime, if it is your bed time, this is one beautiful video, not mine unfortunately. 

http://vimeo.com/29099102

This sort of caper is why I’m interested in fpv and autonomy and a super stable, reactive platform all rolled into one. I have a very specific purpose in mind for this platform which can involve going quickly through trees all fpv. I need the precision aspect of the tuning described above (or similar) to give me the quick responses needed. Then provided I make it to the other side I can use autonomy to do panoramic shots of the area or track back up the recorded path to demonstrate the route from above the tree tops and then of course to get my baby home.

You know what would be perfect.... the ability to switch between 2 different tuning setups in flight at the flick of a switch... although i think Marco already had this idea. Trouble is when watching MP whilst doing an update of several params its not the quickest. Could there be a second or two where you have stab_d and rate_d and stab_P all maxed out- that would be an impressive wobble, or is it just a delay on displaying the info onscreen?  - anyway only musing for now...

This will be a scary thing to experiment with :)

That build has tuned to walls with airflow beside it.

Out in the open atmosphere it will need different.

This seems like some sort of adaptive tuning.

Agreed, i did have a quick fly in the garden, no wind, its still very nice, but definitely different. I've got myself two very different 'stable' starting points to work from though when i get to the field. And I've got an 8800mah laptop battery now :).

I have flown similar params at the field before with b6, it seemed fine but I only had the battery that was in it and was taking it very easy.

I am planning to use this code to build a x8 coaxial quad.  Has anyone been successful with this config?

I would also like to know this... can you set it up as a quad and just use one esc signal for both motors on each arm?

No,

The Esc needs to sense the motors position to work properly and reliably.

yeah i get that, but you split the signal coming from the APM and take that into 2 separate ESCs... should work?

Yet another day and another set of nav/loiter/rtl tests. Today we only had a light breeze so I guess things were much better. I started off by droping the NAV_I term to zero(read on the wiki that it may cause oscillations and that it's better to tune the P values while this one is zero). Got some improvement over the apparent swaying effect I was getting yesterday and today before dropping the term.Then I started lowering the NAV_P (first to 2 from 2.3) term, I believe I got less swaying, but again the same driting(seems to hold well for a couple of minutes then startes to drift). Lowered the NAV_P even more(to 1.6) didn't notice any improvement. Then I lowered the LOITER_P, and as stated by someone earlier in this thread, didn't notice any difference. Again and like yesterday, RTL seems to work quite well(at least when RTLing from a close distance), autolanding actually worked much better than yesterday. I'm attaching a couple of videos of RTL as well as my final param file and logs for the RTL and LOITER attemps.

Can someone please suggest where to go next from there? Is what I'm seeing basically as good as it gets?

 

 

 

 

Attachments:

And here's my param file

 

On a separate note, there is something seriously wrong with logging. My copter is producing something like 40 log enteries, all are empty except for 2-3(luckily the ones that actually had the GPS data) and that's after I started the day today by a reset/erase.

Attachments:

@ Duran DeV: Looking good on the vid on page 23! Do you mind sharing the settings you were using for that video? Thx!

Hi all, I'm quiet new to the arducopter and even the whole R/C stuff (got my 3DR Quad Kit last Friday).

Just learned the lesson only to change one thing at a time. 

Since the last changes I got two problems:

1. When I arm the quad and pull up the throttle sometimes one motor won't start. Thottle back to off, then rising the throttle again, another motor is stuck just asking a little, but most of the times all start quiet well. Its quiet random.

2. After takeoff the quad is smoking for a second or so, after that everything is just fine. Flys very stable also alt-hold and loiter, even RTL.

Things I changed at once:

1. Removed Bulle-Plug due to having problems with cold solder joints 2 times, and soldered wires directly.

2. Updated Firmware to 2.3

3. Loaded Thomas PID Params for the 3DR Quad, which seem really great (thanks), once I'm flying.

As I read in this comment thread, problems with the shaking after takeoff result from the firmware and can be fixed (will try that now as soon i figured out the uploading through arduino software - Is there any tut on that?)

I also redid the ESC calibration, without any improvement.

I don't think its a problem of a ESC/Motor connection as the problem occurs on random Motor.

Has anyone any hint on this?

Every help is appreciated. Thanks in advance.

RSS

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service