Arducopter 2.0.34 Preview

Hi All, 

I just posted a new experimental version of Arducopter with new PIDs and control laws for Yaw. It's download only for now and I wouldn't recommend trying it unless you can rigorously test it. Please be careful. I've flown this in Stable, Simple, Acro, Loiter, and Alt Hold with no known issues. But you never know! This version is not yet compatible with the mission planner.


What's new:

New PIDs - I rewrote the control laws from scratch to add a PI Rate function. The end result should fly nearly identically to the current version. The nice detail is that we can use NG PID values for easy transition!

Before: ->  After

Stabilize P –> Stabilize P (Use NG values, or 8.3 x the older AC2 value)

Stabilize I –> Stabilize I (Stays same value)

Stabilize D –> Rate P (Stays same value)

–> Rate I (new)


I added a new value – an I term for rate. The old stabilization routines did not use this term. Please refer to the config.h file to read more about the new PIDs.

I added the framework for using DCM corrected Accelerometer rates. Code is commented out for now.

Added set home at Arming.

Crosstrack is now a full PID loop, rather than just a P gain for more control.
Throttle now slews when switching out of Alt hold or Auto modes for less jarring transitions

Sonar and Baro PIDs are now combined into a throttle PID Yaw control is completely re-written.



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

Join diydrones

Email me when people reply –


  • Jason, quick question, you mentioned that we can just load 2.0.35 without erase and recalibrating everything and  it should fly normal? Just wanted to ask before I do something stupid


    Seems all values still there after loading 2.0.35 but just wondering if still need to recalibrate everything?

  • Woah you are really fast Jason I am just about to test Loiter and ALT_HOLD but now you have a 2.0.35.
  • From the SVN log:

    Added camera reversing parameters in AP_Var
    Added RTL Throttle Hold set/check
    Added dynamic speed control to slow down as you reach waypoints and RTL Home
    upped Yaw Dead zone slightly.

    Jason, you don't sleep!!
  • Jason, I see that you slightly increase rc4 dead_zone in 2.0.35... maybe a variable in config.h with the possibility to be overwritten in apm_config.h could be useful... I did it to make it easy to modify without touching the code...
  • Developer

    So you don't really need to erase anymore. The firmware fingerprint does the erasing for you when needed. If you load up 2.0.35 you won't have to redo anything. It should fly as is. 

    I added camera reversing but I found a bug in the reversing code. It's minor and shouldn't affect users unless they have a very asymmetric PWM setting. Even, then it would hardly be noticeable. It can be set by the Mission planner, using the parameter list. No GUI yet. We will have to hold off on a GUI untill more camera functionality is defined.

    1 = reversed, 0 = not reversed. Param name is CAM_R_REV CAM_P_REV for roll and pitch. I have not tested it and I'm sure it works.


    If that script works for you, great!


  • As Sasha says, installing a new firmware requires a repetitive number of steps...always the same tedious process. But if you don't do it there is a risk if some EEPROM variables change its position in the new firmware. After loading new code, the safest approach is to erase, reset (to default values) and setup step by step.

    For me another problem is that the setup process requires me to connect the lipo (in APM 2560 USB does not power the servo rail / radio) and the music from ESCs disturb my family (specially during the nights, which is by far the most productive part of the day as all is quiet). In my frame it's not easy to disconnect the ESCs from power....

    To be able to install and configure new firmwares in a fast and quiet way, I have added a custom setup function, that initializes radio min_max with own custom values, flightmodes, enable compass, set my own declination, enables sonar and init accel (level). All in only one command.

    Now, after uploading a new modified firmware, I simply type in CLI:
    reset (reboot APM)
    custom (make sure the quad is leveled and quiet for proper accel calibration)

    And that's all....ready to fly!

    Disclaimer: I don't accept any responsability about the following code. I have tested and it works ok for me, buy maybe this type of initalization can lead to undesired behaviour. I'm not an official arducopter developer and this code is not supported in any way by diydrones community. It's just MY code.

    But if you want to take the risk, just download the new firmware, open setup.pde and modify the following:
    In line 4 add a new pointer to your custom function
    static int8_t setup_custom (uint8_t argc, const Menu::arg *argv);

    In line 29, add a line for the name of the menu option and your new function:
    {"custom", setup_custom},

    And finally, add the following function to the end of the file.YOU WILL NEED TO MODIFY:
    1) The min_max values for each of your radio channels (check the real values using "radio" command)
    2) Your desired order for flight modes
    2) Your specific declination. Mine in Madrid/Spain is -1.61

    static int8_t
    setup_setupja(uint8_t argc, const Menu::arg *argv)
    Serial.println("\n\nJose Angel Setup:");
    Serial.println("\nRadio values before modifications:");

    g.rc_1.radio_min = 994;
    g.rc_2.radio_min = 991;
    g.rc_3.radio_min = 989;
    g.rc_4.radio_min = 1000;
    g.rc_5.radio_min = 1138;
    g.rc_6.radio_min = 1938;
    g.rc_7.radio_min = 1500;
    g.rc_8.radio_min = 1500;

    g.rc_1.radio_max = 2009;
    g.rc_2.radio_max = 2007;
    g.rc_3.radio_max = 2007;
    g.rc_4.radio_max = 2008;
    g.rc_5.radio_max = 1784;
    g.rc_6.radio_max = 1944;
    g.rc_7.radio_max = 1500;
    g.rc_8.radio_max = 1500;

    g.rc_1.radio_trim = 1500;
    g.rc_2.radio_trim = 1500;
    g.rc_4.radio_trim = 1500;
    // 3 is not trimed
    g.rc_5.radio_trim = 1500;
    g.rc_6.radio_trim = 1500;
    g.rc_7.radio_trim = 1500;
    g.rc_8.radio_trim = 1500;

    //save in eeprom

    Serial.println("\nRadio values after modifications:");

    //#define STABILIZE 0 // hold level position
    //#define ACRO 1 // rate control
    //#define SIMPLE 2 //
    //#define ALT_HOLD 3 // AUTO control
    //#define AUTO 4 // AUTO control
    //#define GUIDED 5 // AUTO control
    //#define LOITER 6 // Hold a single location
    //#define RTL 7 // AUTO control

    Serial.println("\nModifying flight modes");
    g.flight_modes[0] = 0;
    g.flight_modes[1] = 6;
    g.flight_modes[2] = 7;
    g.flight_modes[3] = 3;
    g.flight_modes[4] = 2;
    g.flight_modes[5] = 4;;

    Serial.println("\nEnabling compass and setting declination to -1.61");

    Serial.println("\nEnabling sonar");

    Serial.println("\nCalibrating gyro/accel");

    Obviously, after executing the custom command you MUST check in CLI that everything is ok. With "show" command you can check all values (including min_max values for each channel), with "compass" command you can check if your compass is enabled and declination is correct. With "modes" and your radio powered on, you can check that your custom flightmodes order is correctly configured. With test/sonar you can check sonar values.

    If everything is ok, give it a try and have fun!!

    Remember that if you change your hardware (radio, receiver, compass, sonar, apm, escs) you should review and possibly modify this code.

    Don't be too severe on me.... the code could be easily improved using defines and putting the custom values in a separate file for a cleaner code, but this was a quick and dirty test. Maybe some day, I will add a button to the Mission Planner to load a predefined setup...
  • Jason still got question about this...



    Do u know how to make this small changes in firmware without touching everything? i mean do i need to upload from scratch everything in arduino to makes theese changes? and run again APM popup calibration etc?... Or wait till 2.0.35 will come out and then easily change camera gain,and reverse settings but anway will still need re-calibrate even crazy compass :).... ? Thanks

  • Sorry just was funny take off for me lol :) 

  • Ok here's my Success Flight :) All PID's default!

    After first take of it was yawing a lot and i did some manaeuvers landed disarmed (Saved calib) and did this for 2-3 times.
    And yeaah! on 4th take off the yawing is gone! I did some good hovering you can see the video! :)

    My flight time was about 6.30-7minutes on Turnigy 3s 3600mah (not nano-tech) without any cameras or mounts. four batteries used on this field so about 20-25 minutes in air today.

    After i switched off Alt_hold hexa wanted to come down a little fast so i guess i need to make 50% always when switching to alt_hold , anyway alt_hold stays in 50cm-1m corrections, i will post video of alt_hold later.

    I thanked Jason in this video too:))

  • Jason, I'm back from testing and RTL is ok.

    I modified the lines you suggested and also decreased maximum speed to 4 m/s.
    Even with the wind it returned to the launch point. I thought that it would loiter at the home point but I see him fighting with the wind and changing its nose to come back, so I suppose it keeps trying to navigate to the home point indefinitely.

    Alt_hold is not as accurate as last week, I'm not sure if the wind is disturbing the baro... Jason, have you protected the baro with foam or something similar? any picture?

    Next goal is waypoints.... I have to read the wiki and play with Mission Planner to the understand the process.

    Thanks Jason!
This reply was deleted.


Gremsy liked Gremsy's profile
Mar 12
DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
Nov 27, 2022
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24, 2022
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer
Nov 24, 2022
DIY Robocars via Twitter
UC Berkeley's DIY robocar program
Nov 24, 2022
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24, 2022
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup
Nov 20, 2022
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.…
Nov 20, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs
Nov 8, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video.
Nov 8, 2022
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23, 2022
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23, 2022
DIY Robocars via Twitter
Oct 23, 2022
DIY Robocars via Twitter
Oct 19, 2022
DIY Robocars via Twitter
Oct 18, 2022
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13, 2022