3D Robotics

ArduCopter 2.3 released

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.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • NO ONE?

    Hi,

          can any of the SW gurus help me to identify the targetalt variable in the CGS with the corresponding one in the APM SW?

    As I can not get sonar to work as fine as in 2.1 I would like to have for testing one fix target altitud value.

     

    I tried already on my desk with some modification of APM SW, but in CGS targetalt continuos to vary following actual altitude in all modes. is targetalt in CGS comming from APM or calculated internally from other values?

     

    Some of my test included fixing values for:

     

    next_WP.alt = XXX; in Arducopter pde.

    _target_ altitude = XXX; in Navigation pde.

    among others.

     

    Any advice is welcome.

     

    Pablo

  • Moderator

    Finally got some onboard video of my quad flying v2.3 in the Kalahari, Sorry it's not GoPro quality and there's no sound. I have some FPV videos too which I'll put up as soon as I can. Looking forward to v2.3.1 for more stability

    rhnb7q.jpg?width=634http://diydrones.com/profiles/blogs/arducopter-in-the-kalahari

  • Developer

    ArduCopter V2.3.1 - The final test before release

    PS: do not emulated my "extreme RTL -> LAND" if you're not sure what you do!
    I'm sorry for the drunk filmer.

    Marco

  • Hi,

          can any of the SW gurus help me to identify the targetalt variable in the CGS with the corresponding one in the APM SW?

    As I can not get sonar to work as fine as in 2.1 I would like to have for testing one fix target altitud value.

     

    I tried already on my desk with some modification of APM SW, but in CGS targetalt continuos to vary following actual altitude in all modes. is targetalt in CGS comming from APM or calculated internally from other values?

     

    Some of my test included fixing values for:

     

    next_WP.alt = XXX; in Arducopter pde.

    _target_ altitude = XXX; in Navigation pde.

    among others.

     

    Any advice is welcome.

     

    Pablo

     

     

  • I tried to lower stabilize D to 0.06 from 0.12 and it seemed to have noticeable less twitches. (3dr frame everything stock)

  • Made good progress on my hexa with 2.3. Let me give a quick overview on my setup. It's a MK hexa frame with its Roxxy BL motors. The frame has maybe 8 crashes on it, it is hacked up quite a bit! Also, this MK sank into 12 feet of water due to a bad cell in the lipo used, so the frame and motors a have been submerged (MK AHRS still works cause they were silicon conformed). So basically, I'm not in the most ideal conditions from a frame & motor standpoint. To make things more challenging, I'm running cheap 20A HobbyKing SS series ESCs, high timing, 8Khz pwm. My thinking is to push the APM as much as possible....

    Since the 2.3 update, I've had a problem with jittery flight, even with soft PID gains. Stiff gains (e.g. default settings) would result in it flipping (duh, it's a hexa not a quad...). Finally got a good set of soft gains, BUT could not lose the "3-5 sec studder" issue, the thing would not stabilize in hover. Kept thinking it was the "damaged" motors, then ESC quality. Upped the ESC pwm to 16Khz, and still had a slight periodic studder in hover. It was just unacceptable compared to my MK. Only thing left was I was running a '+' frame setup.

    So as a last effort from reading all these comments, I switch to an 'x' frame setup. AND looks like I can agree on this (and same applies to 2.3.1 in the git repo, tried it...): '+' mode has issues, and 'x' is the way to go.

    Frame setup is pretty sensitive on this s/w version. The studder in hover is pretty much eliminated in 'x' config. Looking at the code, maybe an something with stab_d and a set of motors directly on the pitch axis (?).

    I'm still tuning to get stiffer gains (for more control), and will post the PIDs. But so far, looks really good now, motors stay within temps, and get about 12-15min on a 2650mah lipo:

     

  • Developer

    ArduCopter: V2.3.1b VS V2.2ß2XP2-PIDT1 - The stability battle in crosswind (APM1)!

    Both version are "fine tuned", tested only in Stabilize... I do not write anything, I leave you to judge... :-(

    Marco


  • Developer

    In this video you will find a full test of the ArduCopter firmware v2.3.1 that I have done with my Quadcopter F450 X frame.
    I have tested successfully the:
    - STABILIZE mode
    - ALT_HOLD mode
    - LOITER mode (GPS position hold)

    I have really enjoyed with the LOITER mode, it was so stable that I am played to do some videos of my self with the on board GoPro camera while I taken photos of my quadcopter in flight...3692357756?profile=original

    Good work to Jason and to the ArduCopter dev team...

    Regards, Jean-Louis

     

  • Developer

    ArduCopter V2.3.1 - My new CLI Motors Test for the incoming release

    Procedure:

    1) Connect usb port to APM, launch the planner and enter the CLI mode (do not connect the main LiPo battery for now!).
    2) Type 'setup' and press <enter>.
    3) Type 'motors' and press <enter>.
    4) Connect the main LiPo battery without disconnecting the USB cable, do not turn on your tx, is not important.
    Wait some second while APM initializes your esc.
    5) The motors will now spin in sequence, each motor will spin for less than 1/3 second at very low throttle and then stop, before the next motor will start after 2 seconds (3 with Y6 and X8).
    Please observe direction of rotation of each motor to ensure it is turning in the expected direction.
    First motor to spin will be the one located directly forward in the case of + configuration, or the first motor to the right of straight forward in the case of X configuration.
    The motor test will then proceed in a clockwise rotation.
    In the case of X8, it will spin the top front-right motor first, then the bottom front-right, and proceed around with the same pattern.
    OctoV will spin the front-right motor first, and then again, proceed clock-wise until reaching the front left motor.
    6) After the test pattern is complete, there will be a 4 second (5 with Y6 and X8) pause before beginning again.
    7) When you are satisfied that the motor pattern is correct, or you wish to stop the test, disconnect the main LiPo battery and then press any key to exit from test.
    Now if you want disconnect the usb port.

    The wiki will be updated with this procedure, though quite simple and intuitive, this will allow you to discover in an instant if you have properly connected to your ESC to your APM 1/2 without using the tx/rx, as well as sense of motors rotation.
    This test is quite safe, so you decide whether to keep the propellers installed or not,
    if you follow the procedure the motors can't start at unwanted high speed.

    Thanks to Max and Robert for their support.
    Here the video of the motors test on my heavy X8.
    If you have suggestions are always welcome.

    Best

      -= Marco =-
    (AC Dev Team)

  • So when are the changes to the motor order for a hex going to be released. a couple of pages back someone said it was done but havent seen a update in MP.

This reply was deleted.

Activity

Jose Araujo liked Jose Araujo's profile
Aug 29
spencer harvey liked spencer harvey's profile
Jul 9
More…