i running apm2.6 with latest "stable" 3.0.1 firmware. I use latest MP 1.2.83 to make my settings. In moment my copter fly very stable in stabilised mode. Today i decide to test other flight modes. At first i tried AltHold. Switching into this mode nearly cut off my motors. See graph on top. Of course i have corrected the THR_MID parameter as shown on the ardurcopter homepage. My value here currently is at 428 for 6kg take-off weight.
Some words about the copter. It is a hexa for heavy playload. Today the take-off weight was 6kg. max take-off weigh is 8kg and min is 4,5kg. Currently I have mounted 6 t-motor 4012-400 with 15x5 carbon props at 6s(22.6v).
I have less vibrations on apm and gps/compas module because motors and props are very balanced. The Apm is mounted with all other electronics on a separate rubber isolated layer. Also this layer hold the separate battery for powering the apm and other electronics. this mean this layer brings a lot of mass against the mainframe with their heavy main batteries, motor mounts and esc s. This is generally god against vibrations.
My accel log:
simple hovering is between 70 and 90 seconds in log file. all other is starting landing and some throttle tests.
So i try to find the problem in main settings. And here especially for THR_ALT_I / P.
MP defaults and currently unchanged settings for THR_ALT_P and THR_ALT_I are
THR_ALT_P = 1.0
THR_ALT_I = 0.0 .
Did i have to change this setting? Is this the problem? Currently i am unsure because the wiki only talk about 2.x firmwares. http://code.google.com/p/arducopter/wiki/AC2_AltHoldMode
The same is happening to me - see my recent posting 'motors cutting out when testing'.
I have been upgrading firmware for years and have the latest MP 1.2.83 and am trying -r4.
I never had this problem with"stable" 3.0.1 firmware.
Maybe it is some setting in MP 1.2.83 ??????????
If I switch back from either Alt hold or Loiter to Stabilize then all seems OK????
Not game to fly until this is resolved
i am new on arducopter. so i have no experience with older/other versions. Maybe here is a problem with MP and parameter values. maybe it is possible that MP get all parameter from APM at connecting but forget to set some local vars to the correct values. later if you upload parameter some are wrong. for example THR_ALT_P and THR_ALT_I. only an idea:).
My copter is so heavy, so i have no headroom left to test this strange behaviour in flight without too much panic because crashing the copter. also i am not familiar with all the parameters.there are so many.
second alt hold test today. same result:(.
while the copter was falling i noticed no changes in throttle. the props nearly stops during the period as alt hold was switched.
in moment all settings for throttle are default values. i really need some help here because i do not really understand the instructions and/or the background theory behind for tuning this values. http://copter.ardupilot.com/wiki/altholdmode/#Tuning
greetings and thx in advanced
Go through all of the steps in Randy's excellent Arducopter 3.0 pre-flight and maiden flight videos. in particular, make sure your THR_MID value is set correctly.
i have different values to set here because i work with different playloads. my latest test was with 5,5 kg take-off wight. this result in a THR_MID value arround 400. this is dependent from fligt time and lipo voltage here.
in this setup i start hovering with 45% throttle. after 5minust i am at 47-48% throttle after 10 minuts i am at 55% throttle. my lipo have no linear voltage drop.
on last test yesterday i try switching to alt_hold at 47% throttle. if i am right i have +/- 10 persent around the center position. this test caused in a motor shutdown with falling serverals meters. i rapidly have to switch back to stabilised preventing a crash.
next test i throttle up to ~50%. in this case the copter continuously climb. switching in this moment the copter hold a few seconds the position and than rapidly climb up OR shut down the motors and sink to ground. i test this serveral times without an other result:(. falling or climbing. both movents are rapidly. down is nearly a motor shutdown and up is simple full throttle.
i really do'not know how i can improve the THR_MID value. because the battery voltage drop.
i think my vibrations are not to bad. see graph on top.
maybe the problem is not thr_mid value or vibrations. i also perform a apm reset, erase and reload of firmware including a brand new calibration session. no changes. i am currently on 3.0.1.
now i am concentrate my attention to the barometer. i noticed all time i power on my apm a massive alt drift. in both direction. somtimes i power the apm and the alt value continuously falling or rising. starting at zero falling or rising to hundrets of meters. dependently how long the apm is on power. if power is on it will never change the drift direction. it deside on powering if it will fall or sink. you can power apm and it will sink. repower apm 20 seconds later and it will rise. this make really no sense. in console log this also happens with the RAW value. it will sink or rise. but never come to an constant value.
baro console log over 4 minuts. in this case its a sinking val:
all test here i make at home copter was lying on a table. at least i remove the apm and make some tests only apm connected via usb to my computer. all other hardware was disconnected.
is this barometer drift a normal behaviour??? or is my sensor in not good condition. i have a brand new apm2.6 in a side entry housing.
It seems like you're looking in the right place with your barometer issues. That seems like a very large change. I know that temperature and light both significantly effect the barometer. Is it possible that your APM is heating up or cooling down during the test above?
From memory, I think heating will cause the baro to go up and cooling causes it to go down, but I'm not certain about that. If I recall correctly, the curve above could possibly happen if your APM was cooling down during the test.
Mine drifts by maybe a foot or two during flight but no more than that. It sounds to me like the Baro Sensor is having problems. They drift a bit due to temp changes and the like but not that much.
Sorry Scott, I was replying to the original post and must have clicked just a bit after you. I agree it sounds like the Baro sensor and mine has never even came close to drifting that much. Even putting it out in the sun I don't get more than a couple of meters tops.
The same happened to me, and I solved it reducing the LOITER PID to 0,5 as Randy recommended in the 3.0.1 post :
''Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode. You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).''
i connected 3d-robotics and ask them. hopefully they can support me here.
i also plot the corresponding temp drift against the graph on top. the temperature is really rising a bit corresponding to the sink rate. but only a little bit. if i record this log the apm was laying on my desktop. and the environment temperature was nearly constant.
i set my loiter-pid to 0.4. also i reduce rate_roll/pitch p to 0.1. my copter is a little bit over powered and was extremely aggressive with defaults values.
Those two curves seem to have a very strong correlation.
i think my baro ms5611 have real problems with temperature compensation. temperature differences between 3 degree celsius caused over 1500 meters drift. i am unsure what the raw temperatur output from console baro test measured. but i have an calibrated ntc for my multimeter.
so i build a test platform with 3 degree difference. heater was a simple aluminium cooling element with an 10 ohm 10 wats cement resistor connected to my powersupply running on 15V 1A. this heat the cooler arround 5 degree celisus wormer than environment temperature. i simple plug the ntc incide the apm casing and place it on the cooler. during heating i measured massive alt drift down. during cooling i measured massive alt drift up. reading the ms5611datashet and a short look into ardupilot code i found out that ms5611 need a software temperature compensation which is also included in ardupilot.
so no i am sure that i have simple a broken device.