Developer

ArduCopter 2.7.2/2.7.3 released

Arducopter 2.7.2 is now in the mission planner and in the downloads area Some positive reports on testing can be found in this discusssion by John Hanson.

Note: just as the release was going out an issue was found re support for the all Camera Gimbals on the APM1s (it doesn't work) and with 3 axis gimbals on the APM2 (2-axis works ok but not 3).  If you're one of these people, please wait for 2.7.3 which will be out shortly. 

 

UPDATE: 2.7.3 is now in the Mission Planner

 

Functional Improvements over 2.7.1:

  • Fast waypoints (Jason) - if the turn angle between two waypoint the copter is less than 60 degrees it does not slow down
  • Navigation improvements and logging including switching to filtered location for distance calculations (jason)
  • Flip improvements - more aggressive and flexible flip code based on attitude instead of timing (Jason)
  • Improved camera control - you can now control any axis (roll, tilt, pan) with any rc channel.  it probably makes most sense that you will use 6 but others are possible too.  Unfortunately these changes required we change the set-up procedure so the mission planner gimbal set-up screen needs to be modified again.  Please refer to the AC_Camera wiki page for how to manually set-up the gimbal (Amilcar)
  • Flybar acro mode for TradHeli (Robert)
  • "Fast gains" - allows strong correction of attitude using accelerometers while the quad is stationary on the ground but relies more on gyros while flying (Tridge, Jason)
  • Baro filtering improvements (Tridge)

 

Bug Fixes:

  • DMP timing fix (Randy) - the MPU6000's dmp unit was inadvertantly turned on and caused timing delays in the main loop- xbee bricking issue (Craig / Tridge)
  • Dataflash fixes (Jason)
  • Engine ticking - was a combination of roll/pitch rate D term being too high and the dmp timing fix above (Randy, Emile)
  • Faster heading correction on start-up - resolves issue with simple mode getting incorrect heading if you took off very soon after start-up (Tridge)


Code Cleanup:

  • Increased maximum number parameters (Tridge)
  • Formatting changes to code (Pat)
  • Replaced "int" with "int16_t" everywhere (Randy)


As per usual PIDs are optimised for the 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.

There is still some question on whether the default Roll/Pitch Rate P (0.175) is high enough (it was 0.185 in 2.7.1) and also some people feel the Throttle Rate should be higher (currently 0.300 but some say 0.330 or even much higher would be better).

Please feel free to report issues you find in the discussion below and/or add them to the issues list.

Thanks and enjoy!

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

Join diydrones

Email me when people reply –

Replies

  • Wow and wow and wow!!! I have been out of the loop for a few months and now I return to find the work has continued and all of the developers here never cease to outdo themselves!! I can't wait to upload the new firmware and get my quad airborne again. I am so glad to have Invested so much time and money into such a worthy project!  Thank you to all the developers, testers, and folks who just fly! 

  • Hi I have an APM2 with onboard GPS. I get a solid blue LED on the GPS modual, but the the blue "c" LED on the apm does not even blick. It is supposed to blick and turn solid when GPS lock is achieved?

    This is backed up by the fact that I do not see a GPS lock on my computer with telem. 

    And I cannot switch to stabilise mode.

    Is there any thing I can change in the firmware of settings?

    Or is it a HW issue?

    Thanks

    EDIT:

    Trouble shooting page shows that I should not power at 6v from external BEC.

    Changed to 5v and it works! Never get over how finiky these things are...

  • I finally got a change to fly on auto today, I was super excited when it seems to fly in a near perfect line from point to point with very slight stops, but when it reached the 2nd last point, it stopped, loitered and started to auto land. It was not the last waypoint and the waypoint was set like all other waypoints I added.

    I repeated the test 3-4 more times, changing the number, position and altitude of the waypoints, and everytime it would stop and begin to autoland at the 2nd last waypoint.

    So if I had 7 WPs, it would land on number 6, 5 WPs land on number 4. Very frustrating!

    Is this some new function that I am unaware of or a bug of some sorts? I didn't have this issue with 2.7.1... 

    Thanks a bunch!

    (Stabalise flies awesome, as does loiter, alt hold has issue with sonar noise but I'm working on that)

    Oh, I'm flying a DJI 450 stock esc, props, motors with APM2, uBlox GPS, XL Sonar, Arducopter 2.7.2, Mission Planner 1.2.11...

  • Had a chance to fly my quad around a bit past weekend, thanks team, loiter seems quite good :-)

  • Today I had a chance to fly my hexa with 2.7.3 and I'm really impressed. Compass auto calibration works- in previous versions, I had to change it manually by -4 deg. Alt-Hold and Loiter works perfect, at least with very light wind.

    There are also some problems:

    Once (per ~10 flights) I had problem with direction in simple mode - after few minutes of flight and some number of rotations the yaw stared to be wrong -  I don't know if it was software or my mistake, I had to analyze logs. Is there any parameter in logs, which is responsible for base direction in simple mode ?

    I have seen some wobbling in fast descent - is it normal or should I tune some PID-s ?

    I still see problem with elevation during yaw change. One full rotation can change elevation by 1~2m.

    Battery capacity monitoring isn't working - I don't know if it is problem with AC,  APM Planner or hardware, but with AC 2.7.1 and previous APM (probably 1.1.94) it was working fine. Now all the time I see 99%.

    Anyway good work!

  • Hello

    Can anyone tell me why this is happening when I only pull throttle. This started happing when I updated the quad to 2.7.1 and my remote to er9x firmware. I took this quad appart so many times to check connections that people think I have ADD. One ESC does get warm but I think it is because he gives power to the APM, and 2 motors makes a click, click noise.

  • Updated Hex to 2.7.3 last week and went for a flight.  Everything went quite well and I came home very pleased.

    Today there was zero wind so I went out for another flight.  My hex got a GPS lock right away and the compass locked with no drift.  I left the ground and my hex hovered solid before I started to ascend.  Suddenly it started to ascend & descend erratically and I started having trouble steering.  It tilted forward and started to take off on me.  The only control I had at this point was throttle so before the hex headed off out of sight I had no choice but to kill throttle and force a crash landing in a field. (breaking 3 blades and an arm)

    This confuses me since it flew so well last week and nothing had changed.

    Here is a link to the flight logs.  I looked them over but have no idea where to look for a possible problem.

    Crash Log (log)

    Crash Log (tlog)

  • Hi all,

    I've had great testing today of 2.7.3, everything seems to work including conditional_yaw.

    The only thing that didn't work was the ROI command in my mission.  Stands for Region of Interest. 

    I was able to hold the yaw position in version 2.7.1 by specifying a ROI.  Now in 2.7.3, ROI seems to be ignored.

    Anybody have any ideas?

    I'm attaching a screenshot of my Log file, you can see the waypoints and the path of the copter.

    Dan Gray

    3Missions.jpg

  • Hello, I'm finally back on track with a new multicopter and I'm happy to see that the project moved a lot further since the old versions I was used to use but I notices a first problem. When I used arducopter it was 2.0.50 version and I had a problem with failsafe not engaging using my radio (HK-T6A from hobbyking). I discussed about it publicly (in this post) and created a firmware for the PPM chip that would recognize the failsafe of my radio but I see that now none of my changes have been imported and I face again the failsafe problem in my new shiny APM2.

    Does anyone know how this can be solved? No one else had this problem?

    The failsafe of my radio (the cheapest 6 channels 2.4 GHz on hobbyking) is:

    - keep last values for channel 4 and 5
    - ground signals for channel 1, 2, 3 and 6.

    This doesn't seem to trigger any failsafe in the APM that keeps remembering the position of all the 6 channels since the last time my radio was in reach. Not good if you're climbing and lose connection as the copter will just get to the moon.

  • Potential issue with ArduCopter 2.7.3 as downloaded (source) today:

    Downloaded sources, configured APM_config.h for APM2 with frame set to HEXA Plus, compiled and uploaded with Arduino 1.0.1 on OS X 10.6.8

    Then proceeded to configure APM via CLI (because I didn't have a Win PC handy).

    Radio calibrated fine, everything worked until the next reboot.

    After reboot, the learned calibration values for RC_min, RC_Trim and DZ were gone for channels 5-7 (min was set to 0, resulting in really wrong value scaling) . Effect is for example that modes come out completely different than programmed.

    I tested a few times: after EEPROM erase, there are sane default values for the radio calibration that survive reboots and power cycles all evening long.

    After radio calibration there are sane values, but after reboot or power cycle channel 5-7 config gets corrupted (might be an EEPROM write issue, but EEDUMP comes back with correctly written values after ERASE and initialization as stated above).

    Obviously I am not going to fly like this when I can't switch modes correctly... I looked through the issues list and there are some recent issues that MAY describe symptoms of this problem. But may also just be my board - works fine with 2.6, though.

    I will try to find out what is going on with the EEPROM writes but there are certainly more qualified people here who actually wrote the code.


    Cheers, Otto

This reply was deleted.

Activity