I’ve been running 2.9.1. fine for a while, and now that 3.0.1 is final I spent today upgrading to it.
All the same settings as 2.9.1, but have redone compass calibration and gyro calibration as recommended.
All seems fine under moderate power on takeoff- gets light - controls behaving as expected (though a bit more twitchy and throttle is different), but as soon as the quad actually lifts off, she flips over on her back.
I’ve tried recalibrating serveral times with no change - has anyone else had this behaviour ?
Yeah I also upgraded today to 3.01 and had the same type of behavior - she tries to lift off but flips from front to back belly up on the ground. Thought I’d go thru the setup again tomorrow but seeing that others are having the same issue maybe not - looking forward to other comments…
OK not seeing any helpfull hints on the blog I decided to revert back to 2.9.1b which I did and now shes back to her old self flying just fine.
BTW in the mission planner hardware /firmware sectionshows the “load previous firmware” button incorrectly. its showing the wrong info should be version number but all you see is a hex dump, but it works just fine if you select the 3rd line down.
I’ve done the same as you excerpt I reconfigured everything from scratch with the new firmware. I haven’t experienced any problems with my test flights.
you can check the link on the copter.ardupilot.com downloads page for the binary files (hex files). you’ll find all versions there. download the one you want and use manual update in the mission planner (small link on the bottom right corner of the screen).
Oh yes. I had the exact same issue yesterday and I had to revert back to 2.9.1b just like everyone else. I have been flying for months with no issues on 2.9.1b until I upgraded to 3.0.1. I ran through all the calibrations including compassmot using a 3DR power monitor sensor. I even used anti vibration foam on my APM 2.5+, did a live calibration of the compass and calibrated the gyros. I even recalibrated the ESCs. I have spent 2 days on this. Slowly power up the motors in stabilize mode and on a flat concrete surface, as soon as the is just enough power to lift off…boom, the copter flips over on its back.
I reloaded the old firmware and bingo. I’m flying great again. I don’t know what gives because there seems to be plenty of people flying with rev 3.0.1 and loving the improved stability. But something must be amiss because there are too many reports of the backflip occurring among us experienced APM quadcopter pilots.
For what it’s worth, I zeroed out the flash memory and loaded the “blink” sketch to rewrite program memory. I then reloaded 3.0.1, performed all calibrations, and everything is now working fine. Could be a coincidence, but might be worth a try.
Sorry for the delay in response on this. I had no idea that people were posting support questions here.
My guess is that some parameter is being corrupted as part of the upgrade from 2.9.1b to 3.0.1 but i’m unsure which one.
Can someone who is having this problem do the following?
1. ensure that AC2.9.1b is installed and working
2. go to the advanced parameter list in the mission planner and save your parameters to a file
3. upload AC3.0.1
4. go to the mission planner terminal window and do setup, reset to reset all your parameters to the standard ones
5. do the all configuration again (sorry!)
6. try flying and I think the problem will be gone.
7. to help me know what parameter was the problem please go to the mission planner advanced parameter list and save the paramaters to a file again
8. email rmackay9_at_yahoo.com both parameter files (from steps #2 and #7)
OK. Problem solved for me. Turns out I was loading the firmware for an octo- copter instead of the quad copter. The mission planner icons can be confusing. I have an X-frame quad and I selected the icon for an X-frame octo. The x-frame octo only has 4 arms just like a quad, and all the icons have the same text underneath them, namely version 3.0.1.
So be careful and make absolutely sure you click on the correct icon in the mission planner for your copter. I figured it out by looking at the status tab of the heads up display in MP. Arm your copter and make sure the number of output channels with a value greater than 0 matches the number of motors you have on your copter.
We are finding that some of our tuning parameters are (randomly) changed when we fire up our hexacopter’s the next day. Not sure if the over night power off is implicated because of length of time
The problem involves two different hexacopters , and two different APM 2.5s (bought at different times) with 3.0.1 firmware. We found the issue after successfully flying the machines one day then trying to fly them again the next day. The tuning changes caused all sorts of control issues as you would expect. We now save [b]every successful tuning session [/b]to file so that we can reload it ready for a new day.
We do not trust the parameters anymore and do a full check of the essential flight parameters before every flight - yes! every flight. I’m now trying version 2.9.1 hoping that this is more stable firmware
I had also started getting “low voltage” alarms for the APM. Measurements showed 5.2 volts (which is good).
This alarm means I was unable to ‘arm’ the machine.
Loading 2.9.1 firm ware seems to have fixed it for the moment - time will tell
Has anybody else noticed that “some” parameters change randomly (over night maybe)
I am using the APM Power Module with XT60 Connectors. (It came in a kit with the APM2.5, GPS module etc - if I recall correctly from 3D Robotics).
It provides the APM 2.5 with clean power from a LiPo battery as well as current consumption and battery voltage measurements to the APM 2.5 via the provided 6-pos cable. The on-board switching regulator output is set for 5.3Vdc at a maximum of 2.25A from up to a 4S LiPo battery.
I inspected/checked the wiring and re-seated “all” power connectors - finding no obvious problems.
PLUS I measure between 5.2 and 5.3 volts DC every time the alarm comes up. All on firmware 3.0.1
I use a separate BEC for powering the Spektrum 8 channel receiver. The ESCs are optical isolated types.
Now on 2.9.1 the problem appears to have gone - BUT I need more time to assess if this will hold true -it might return.
NOTE the parameter “corruptions” are not rubbishy random numbers but they are numbers that are either 0.0 or some older or similar value. This is despite the fact that the copter has been flown with the new numbers perfectly. Is it not true that - once the numbers are in the APM they are in basically in forever until explicitly changed by the user?