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: 58536

Reply to This

Replies to This Discussion

Well, unless you have alt hold on, getting to min throttle, means you better be landing.  Maybe the min throttle is too high and needs to be adjustable.  It really depends on the weight of your quad versus power of the motors.

I've experienced something similar yesterday, I was testing PID tuning in the back yard, and after some time the quad had a brownout. In the past when that happened it would drop half a meter or so and then regain itself without any trouble. This time it dropped and the started flopping around wildly.

I was lucky, but it could have ended badly very easily.

So I think that whatever is causing the effect, it should be a high priority bug fix. For now i would not recommend anyone to fly with RATE_***_D set to non-zero. 

@Dave

This also happened to me when testing stability in hard descends, and it was really scary, but happy it didn´t end with a crash.

so, yes: NEVER PUT THE THROTTLE TO MINIMUM IN FLIGH, until this is solved

Angel

i seem to be missing values for "Pitch IN" in todays logs, has anyone else got this problem or is it just me?

james

Yes, I noticed that too. I've posted a sample log from my first test flight a few pages ago...

Hi Folks,

Got to fly with 2.3! Yippy. Can't wait for the weekend...

Thanks to those involved.

I've skimmed the comments (can't find a way to search them?) so forgive me if this has been covered.

So uploaded 2.3 onto my 3DR quad and took it for a test. I tried the auto land (Mode=Land) and it hovered for a few seconds, started descending slowly and then, from about 4m up, shut down all 4 motors. They were still turning but just about off. The poor thing fell like a rock.

I checked the sonar in MP CLI and it is roughly correct, maybe a few cm off but ok and responds to high changes.

Only thing would be that it was about -2/-3C outside and I had been flying for about 5 minutes. I know people have said it stops working at low temps but... Could there be some way of not being so brutal in shutting down the motors? If the sonar gave back false readings, maybe to continue a slow decent until the motors are off?  Not sure if it already does this and what I experienced was a bug?

Uploaded 2.3 from MP onto APM1, have MB1200 sonar. I since reflashed - would that have killed logs?

Cheers,

Crispin

Am using an APM1 board, but not bothering with the sonar. I have done a couple of auto-landings under 2.3 and while they were not the gentlest of landings, it did land with no damage, so fine by me. Temp was probably about +2C. Unless you really need to be doing stuff at very low level, I honestly would not bother with the sonar - I suspect they are more trouble than they are worth, and after reading all the comments about interference, cold/heat etc. have little or no faith in them. Longer term, the APM2 board is very good even at low level - not using it at the moment as I want to put it on a really small quad where I need the reduced size and lightness so am concentrating on my APM1.

Good luck!. Small quad=bad - see previous post ;)

@Dave C: "Small quad=bad"

Sorry: don´t agree.

I fly from long time ago a small quad (<500gr w/o bat) and is the best quad I have, with same pids than 3DR. If any wants details of my setup please, ask.

Angel

no probs, i thought I'd deleted that less than clear post. I was just struggling with the dji frame, with exactly the same electronics as my ardu frame, and many other variations, motors, props, PIDs etc.

It flew fine with stock tuning (default using stab_d rather than rate_D)

I just couldnt get any rate_d dialed in on this frame, so i went back to the arduframe and all is great again - even better in fact since I also transferred my newly designed vibration mount to the ardu when i gave up with the dji.

I certainly didn't mean all small quads are bad, I'm currently trying to build a frame that will take 3" props :)

Hi Crispin, i'm sorry to read that!  After the crash the APM was still turned on? Are you sure you did not have a bad lipo and just loss power about some like this?
This is something that unfortunately can happen, if the baro or the sonar may have problems in detecting the correct altitude and sending to the code a wrong value (altitude is less than 15cm) is always equivalent to "turn off the motors" when "land" is engaded.
This
could be avoided by implementing the code of the control value of the gyro / accelerometers, the rest when you're on the ground their values not constantly change as when you are flying.
I mean "if altitude is < 15 cm" and "gyro/accell value is < x", and this value are are constant for 1 or 2 second = landed = turn off the motors.
This is a security that I suggested at the time, unfortunately was not taken into account.
I suggest you disable the autolanding until you understand what happened from the log, just increase the value "auto_land" to some like "300000" (5 minutes) and land your quad manually.
I have personally tested the autolanding a lot of time with my little quad to give my impressions, but I immediately put a very high value (1 minute), I always prefer to land manually all my quad, especially the very heavy.
Please report the "problem" in the issues section here:

http://code.google.com/p/arducopter/issues/list

I repeat, not a code problem, but incorrect reading of sensor, now a security would be appropriate why this can not happen to other (imho).

The part of the code that checks if the quad is actually landed (and it is proper for me):

    if(current_loc.alt < 150 ){
        if(abs(climb_rate) < 20) {
            landing_boost++;
            if(ground_detector++ > 30) {
                land_complete = true;
                ground_detector = 0;
                // init disarm motors
                init_disarm_motors();
                return true;

Marco

Hi Marco,

Thanks for the reply. 

Don't apologies for it doing what it did - without you guys, I would have nothing to play with :) This is all part of the fun.

There was no damage to the quad and after the landing, I did a quick check and flew it away again so there was not problem with the lipo (was freshly charged before all of this) and everything was fine.

A question on your code though:

     if(ground_detector++ > 30) {

   land_complete = true;


The minimum value my sonar returns is about 21cm (in reality, floor->sonar is about 10) when it is standing on the floor. Would your code not cause it to stop while still in flight?



I'll post the problem on the list.

Cheers,

Crispin


RSS

© 2014   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service