Arducopter 2.8.1 is now in the mission planner and in the downloads area! Remember to do your MP configuration again after loading this code, since it erases your EEPROM and sets it to the new defaults. 

Note: Issues with APM1 user's level feature not working are now resolved.  If you installed 2.8 we highly recommend you upgrade to 2.8.1 as 430 extra bytes of RAM have been freed up which reduces the chance of memory corruption (although we haven't seen any cases of this on the APM2 at least) .

Note #2: this release has not gone out for Traditional Helicopters until they can be tested fully.  Flip and Toy mode have also not been fully tested.

Improvements over 2.7.3:

  • Improved ACRO mode (Leonard Hall)
  • Improved stability patch to reduce "climb-on-yaw" problem (Leonard, Rob Lefebvre, Randy)
  • Rate controller targets moved to body frames (yaw control now works properly when copter is inverted) (Leonard/Randy)
  • Less bouncy Stabilize yaw control (Leonard)
  • OpticalFlow sensor support for APM2.5 (Randy)
  • DMP works again by adding "#define DMP_ENABLED ENABLED" to APM_Config.h You can also log DMP vs DCM to the dataflash by adding "#define SECONDARY_DMP_ENABLED ENABLED" (Randy)
  • Watch dog added to shutdown motors if main loop feezes for 2 seconds (Randy)
  • Thrust curve added to linearize pwm->thrust. Removes deadzone found above 90% throttle in most ESC/motors (Randy)
  • More timing improvements (main loop is now tied to MPU6000s interrupt) (Randy)
  • GPS NMEA bug fix (Alexey Kozin)
  • Logging improvements (log I terms, dump all settings at head of dataflash log) (Jason)

 

Bug Fixes / Parameter changes:

  • fixed skipping of last waypoint (Jason)
  • resolved twitching when no GPS attached (Tridge)
  • fixed loss of altitude if alt hold is engaged before first GPS lock (Randy/Jason)
  • moved Roll-Pitch I terms from Stabilize controllers to Rate controllers
  • TILT_COMPENSATION param tuned for TradHeli (Rob)


Code Cleanup:

  • HAL changes for platform portability (Pat Hickey)
  • Removed INSTANT_PWM (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.

Please note that on this release we've moved the Roll and Pitch I terms from the Stabilize controller to the Rate controller. There's some evidence that says this can lead to flips on take-off if you move the roll or pitch sticks around as you take-off so we recommend you leave these sticks in the middle until you're in the air.

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

Thanks and enjoy!

Views: 127240

Reply to This

Replies to This Discussion

Tony, do you ask me? If yes, then: No, that is not what I want to say. I would be a fool to buy as many APMs and recommend them to my friends, when I think they suck.

Ardobeginner     Oh boy, I think alot is being lost in translation.

Again it sounds like you do not like the APM.

I know what you are trying to say, it just doesn't come out that way.

 

@tony: Good. Good. Let the hate flow through you...

The only reason that you may not be able to get Alt Hold to work on a quad is that vibrations are messing up the inertial navigation. There are two things that you can do here.

1. reduce the filtering of the MPU6k to 20, you may be able to go as low as 10.

2. turn off the inertial navigation and use the raw baro. To make this work you will need to reduce the Alt P to 0.5 and the Rate P to 1, Rate D to 0.

With the inertial stuff turned off you should be able to do as well as the Wii.

I also had a lot of trouble with sonar.

I found I had to use the shielded cable recommended, and earth it as recommended, also, I find that just selecting the model sonar you have does not always give the results expected.

When I found this by testing sonar in terminal I tried other models and got much better results even though it does not necessarily match the one I am using.

Getting rid of any noise from the sonar is the first major step though.

My response was not a reply to you, it was titeuf007.

Your point is valid that maybe there is something in the multiwii code that we could look at.  Any pointers would help.

Actually no. Not every 90 days.

Last multwii was released 7 months ago. 

See for yourself.

http://code.google.com/p/multiwii/downloads/list

Ardobeginner,

     Can you download and post some dataflash logs?  It'll take the guess work out regarding what the issue is.  There's some descriptions on this wiki page on how to download them.  In short you connect to your APM using the Terminal window in the mission planner, then click the Log Download button.  Once it's downloaded you need to get the .log file from the Mission Planner's "logs" sub directory (i.e. the 'log's sub directory of whereer you installed the Mission Planner).

     By the way, I definitely appreciate your testing and reporting issues.  Testing the next release especially with as many changes in it as this release can be closer to "work" than "fun" so to keep your sanity please feel free to go back to 2.8.1 and we can also help you get that one working. 

I finally fixed my motor surging problem with 2.9. It was INS_MPU6K_FILTER; the default ("0", or 46hz?) was apparently too high for my little shaky quad (FW450, NTM 2826-1200, GWS9050HD, 3s2200). Things improved greatly after I reduced the filter to 20hz (and cycled the power).

Before changing lowering INS_MPU6K_FILTER, I ran the gammut of PIDs with little effect. I got all the way out of wack with thr_rate_P=10, and thr_rate_D=0.008 for half way decent stability... thr_acc PID effects were small and vague (I did notice the frequency change with P though). It wasn't until my last flight that I tried the 20hz filter setting. I immediately noticed a huge differece; surging went away, and CR control was much smoother and direct. After seeing the drastic difference, I immediately landed and reverted back to the default PID's to see where it was. Then the CR control finally became very manageable; even gave me the zero CR deadband I was after. Then I started playing with thr_acc_P on ch6, and homed in on the sweet spot around 1.0. Towards the end of that pack it got good enough to see several "100% Naza quality" moments as I was torquing the little quad around my backyard in alt mode.

I wish I had the filter set to 20hz earlier today, before I flew through like 20 packs and ran out of daylight. Hopefully this post will save somebody few Ah worth of tuning. :P

KevinB,

    Excellent, thanks for this.  Your experience will definitely save some future people some time.  We've been debating whether to set the filter to 42hz or 20hz.  With the inertial nav stuff the filtering of accelerometers can make a big difference especially if your props spin at the magic frequency 6000rpm or 100hz to cause aliasing.

Great result Kevin!!!!

This is a classic case of vibrations messing things up. This is a setting that we need to work out how low we can go. I have been flying on 20 for a while now but I have not had time to see how 10 feels.

Basically, the lower we can set this parameter without effecting the roll and pitch response, the better your quad fill fly!

We have been very conservative with this parameter because we don't know how a very small, high powered, twitchy quad will react to a low setting.

If there is anybody out there with a quad like this it would be great if they could have a look at this parameter!

Have just uploaded a video of the flights at

http://www.youtube.com/watch?v=W2hUNZoPttE

Flight logs here as well

Attachments:

Reply to Discussion

RSS

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service