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:
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!
After tuning my quad (http://diydrones.com/forum/topics/arducopter-2-7-2-released?comment...) in the backyard by just changing rateP and stabP (rest on default). Althold worked well in the backyard. I did a test in the field. On althold my quad went 156m up in the air with a constant climbrate of 3m/s. LOL! I never dared to fly that high. At this hight i got slight jitter on my videoline so i switched back to stab mode and landed. I have the whole flight on my groundrecorder with minimosd overlay. The data in osd is correct, because after landing the groundhight is reported as 0m. Back home i adjusted throttle P and alt P from 0.3 down to 0.250. Perhaps my next field test will be better. I don't know what happened for sure but i suspect my mix for the flightmodes 3 position switch with another switch for RTH (set to 30m) inside my transmitter could have been the problem perhaps the rth switch was on and the other one on althold - so in the sum it produced a crazy signal so the apm20 didn't know that i wanted althold. In my opinion the problem is to 95% on my side, but i just wanted to report it because there is a slight chance of a software glitch as well. I will try to read out the log file as well.
I don't know Den.
I read somewhere way back that to <correctly> compile arducopter, you should uncomment that line! Which I have always done(without problems).
//#define CONFIG_APM_HARDWARE APM_HARDWARE_APM2
It will compile with or without but I assumed that being commented out by default was meant for APM1 compilation.
Have also tried as an alternative, uncommenting this line:
I did this with the previous beta versions but that won't compile, some messed up code/syntax, never probed further...
I found the log and analyzed it. Like suspected during the whole flight Alt hold was NEVER ENGAGED - no wonder it didn't work then. The flightmode is recorded correctly because on another flight i can see me switching the flightmodes. So no problem with 2.7.3, just 100% my transmitter mixing fault.
If I edit that line in config.pde
#define DMP_ENABLED ENABLED
then wil cause APM2 start crash.
minomosd must to display actual flight mode
when assign modes - check ppm value must to be in the middle of range
my self-making 5-position digital switch
eagle schematic http://files.msdatabase.ru/modesw/modesw.rar?attredirects=0&d=1
If you have a Dual Core CPU, and your MP is taking 50%, this shows that your MP is using 100% of one core. Very strange.
I'm having loads of problems since the 2.7.3 upgrade and I think the gimbal code might be the source. I have tried uploading the new version from two seperate machines and both seem to upload and verify ok. After upload everything seems fine. All my settings are obviously lost with the eeprom upgrade. I even go so far as to factory reset to ensure default settings.
I then recalibrate radio and enable my optional extra devices etc. Everything is fine up to here.
However, the moment I enable CH6 either for camera pitch control from the gimbal config screen or for P value tuning from arducopter config screen my connection is lost and the com port starts repeatedly dropping in and out within windows. This gives me barely enough time to create a connection to perform another factory reset thus enabling me to re-establish a connection. Its almost as if the APM is dropping the connection. I've tried this with both a USB and 3DR telemetry connection on two seperate laptops.
I'm running an APM2.0 on a 3DR Quad frame with sonar. Unfortunately since I can't subsequently reconnect without factory resetting, I have no logs.
try reload another firmware as example plane 2.6 then erase eeprom and reset params from console and reload arducopter
Thank you very much for your extensive explanation and the cool hardwaresolution. I am using Flysky with er9x FW. My mixer seems to be setup correctly (hitting pwm values in the middle) and i haven't been able to reproduce the problem on the bench or in the backyard. I think i will delete my current mix and redo it. I don't know if the minimosd (connected with RX & TX) custom FW (http://code.google.com/p/minimosd-extra/downloads/list) can "backfire" wrong settings to the apm2, because i've noticed the osd being sluggish with displaying the flightmodes. Seems unlikely.
Thanks for the quick response. I just tried your suggestion but still have the same problem. The second I change the tilt 'Input Ch' on the camera gimbal page to RC6, I get the message "Serial connection has been lost" and I'm back to square one :-(