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

Reply to This

Replies to This Discussion

It is.

Sorry, using 'cyclic' as a shorthand for pitch/roll. thought that was reasonably obvious.

If you look at the code, it updates the loiter waypoint whilst in 'loiter_override' which has clear entry and exit conditions. Exit condition is that pitch/roll (ie. cyclic) is centered. If the radio input for those two isn't exactly centred, it looks like it may not exist that mode.

Hi Marco,

yes Gopro on a head strap there great. Yes very stable when I had finished the trimming could not believe how good it was. still to try out the Loiter ect but will try soon and report here.

No, all the rest to default! :-)
I don't know why it flipped, with 2.2 does not have problems? Are you sure?
Have you 
changed something, like the connection of motor?

Is there someone
can filming when you try?

Ok, but if you try with AC 2.2 all is ok?

Johann, forgive me if I'm totally off the mark, but I had something similar - (flipping or extremely unstable on take off). It was solved by powering APM first and then the R/C receiver rather than the other way around.

See if your MP artificial horizon reacts slowly when connected or normal speed, if normal then it's obviously not this. I had an unexplained flip today after flying fine all the previous flights.

Rick, if that is the case, then there is a problem. Jason made a change to the code, as per this comment, " If you fly, you must bring it to a stop to regain loiter. I will also put a 2 second timeout on it too in case you're in wind." i.e. in wind, he is expecting that we hold it static and thus will have sticks not centred. That is a change that I had been requesting for some time, as otherwise the copter pitches to horizontal and is blown back and loiter has to try to regain position - better to start static and have loiter keep position. It is possible that there is a confusion in the code here i.e. that this condition is only if you are already in loiter and fly around. I would expect and want it to be the start condition of loiter. As it happens, on the occasions in the flight posted to the issue, when it was being blown back, my sticks were centred. If even a bit of trim can mess it up (and inconsistently), then the problem is worse in that achieving loiter becomes fundamentally unreliable e.g. on Auto missions.

I have not had any formal feedback from the dev team on the issue, but what I would like to see in terms of functionality is clear:

That loiter when invoked, takes the start attitude of the copter as the start point, to prevent pitch back and blow back in wind (the assumption being that both manual control and Auto will achieve  a static position before invoking Loiter).

Happy that there are entry conditions to regaining loiter after a fly around and Jason's conditions sound sensible to me. It should be clear to all whether loiter will try to maintain that position or regain the original target - my preference would be for the latter as if you want a new loiter position, why not get it static, flick to Alt Hold and then back to Loiter to register the new position.

Marco, I looked at checking my GPS firmware, but am always reluctant to start applying soldering irons to my electronics unless absolutely necessary (am not the best!). Martin from Build Your Own Drones says that it is highly unlikely that I have a unit from old stock due to his turnover of kit. Regards, Bill

Bill, and dev team,

I think Bills´s post serves well to illustrate the importance of providing stringent, thoroughly written, and updated wiki´s.

I understand the difficulties at hand when sharing time between development work like programming, testing / verifying and the documentation. But if you prioritize programming too much on behalf of documentation, well then we have like ten smart developers creating wonderful code that hundreds of users don´t know what to do with.

I know, it is easy for me to make requests. Fix that, update that....

However, spending that extra time on wiki´s may save developer time in the end, time that they otherwise will spend on answering the same questions over and over.

I cant get alt_hold to work on 2.3.

Switch to 2.1 and works ok.

Trying to understand the code I followed the altitude setpoint thorugh some variables until this:

static void set_new_altitude(int32_t _new_alt)
    // just to be clear
    next_WP.alt = current_loc.alt;

    // for calculating the delta time
    alt_change_timer = millis();

    // save the target altitude
    target_altitude = _new_alt;

I cant find _new_alt; in any other part of the program.

Can some one help me on this one?

Where is this variable set ot writen?


_new_alt is passed in from Arducopter.pde, when set_new_altitude is called in the update_throttle_mode().

Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service