Thanks to help in another thread, I’ve now got to the point where I can arm my hex and control the motors via my transmitter. Yesterday I powered up until it was light on its feet, and found the ‘elevator’ control was reversed, which I fixed in the transmitter.
Today I tried to fly again but (a) the copter seems not to have enough power to get off the ground, even at close to full throttle and (b) when it’s very light on its feet it seems that it’s not stabilised – it attempts to fall over in random directions. I’ve attached the .bin file from today’s effort, in case anyone can pinpoint a specific issue with my rig. Compass and mag have been calibrated in Mission Planner, and there’s no error messages.
I’ve flown quads for several years, and have one with the same MT2216-610 motors, ESCs, 1045 props, and 3S 4000mAh 30C LiPo as this hex, but running iNav. It hovers at half stick, and weighs 1022g with battery. This hex weighs 1608g with battery (i.e. 57% heavier) but, of course, has the extra 50% motors, so I would have thought it would fly at something not far above half stick.
Any thoughts please?
Edit: I’ve just remembered that hardware can’t be the issue, for this hex did fly quite successfully a couple of years ago using an Omnibus board and iNav, with the same battery, motors, ESCs, and props. I only changed to Pixhawk and Ardupilot in order to learn a new skill and, hopefully, to have a more flexible and reliable system so I can start meaningful photography.
The craft is not flying in this log. No motor outputs. Which motors exactly? Are you sure this flew at this weight on 3S power?
Also, the “basics” include setting the Initial Tuning Parameters before 1st flight. Yours are at default.
Alt>A plug-in menu after connecting to Mission Planner.
Thanks Dave. That’s odd, it wasn’t flying, in that it didn’t get off the ground, but the motors were responding to throttle input and did throttle-up. Yes, it did fly previously in Omnibus/iNav form, and climbed to a great height at a rate of knots – out of control in loiter mode – which is why I switched to Pixhawk/Ardupilot!
What’s the ‘Alt>A plug-in menu’? I’ve connected to MP, pressed Alt>A, and all it does is highlight the ‘Flight Data’ pushbutton. I’ve Googled and found the Basic Tuning instructions, so I’ll go through them and report back. Don’t hold your breath though, it will take me a while.
Bother! Installation seemed to go okay, but when MP 1.3.74.1 loads I get this error message and it then shuts down. I think I’ll uninstall, and then install from scratch tomorrow after. I’ve saved my parameter files.
I’ve installed the latest non-beta version of MP, 1.3.74. Don’t tell anybody but, on taking the props off so I could reconfigure/tune the copter, I realised that it had on 4 normal props and 2 reverse props Replacing the prop on motor #1 with the correct one cured the take-off problem.
There must be some clever stuff going on in Arducopter, for yesterday with the wrong prop on one motor, none of the motors seemed to want to spool up fully. Today, with the correct prop, they all spooled up normally, and the copter lifted off at about half throttle. So now I can get on with the tuning process …
Alright! I think the tuning Plug-in is in the latest stable version of MP but if not install Beta. Ardupilot features lead stable Mission Planner sometimes by a considerable time frame…
Either way you should still start with the initial tuning parameters. I manually tune but always from that base plus the Dynamic Notch Filter. A good process to follow:
Set the Initial Tuning parameters.
Make a hover flight (maiden) to determine Dynamic Notch filter parameters.
Set those parameters and make another hover flight to see if they are good.
Then tune whether it’s Auto Tune or manual.
Thanks, I’ve already gone through the initial tuning. Not enough room in my garden to fly safely, so I’m just waiting for a chance to go to the flying field to checkout the copter’s basic behaviour before looking at further tuning.
Had a good 5-minute hover yesterday in stabilised mode. A bit too twitchy for my liking, so I’m going to tune it before the next flight, and slight drift to the right, so I plan to implement the ‘Save Trim’ feature using CH7. Used less than half of my 3S 4000mAh LiPo, so I’ll be increasing flight time to 7 minutes next time.
Had a good two 7-minute flights today. I had reduced the sensitivity parameter after last week’s test, and it felt just right to me today. I then used the first battery to compensate for the right drift using the Ch7 ‘Save Trim’ feature, and got it steady as I could considering the light breeze that was blowing. For the second battery I took it up to about 15ft height and switched it to loiter mode, and it just sat there with about +/- 3ft accuracy laterally and, so far as I could determine, no vertical movement.
Next week, based on battery useage today, I’ll be extending flight times to 10 minutes, and then checking out the RTL mode.
There is no expectation of no drift when flying in Stabilize or AltHold mode even when it’s windless. I think it’s a waste of time to attempt to trim this. Perform a good accelerometer calibration and call it good. That’s why the Note in the Wiki says “this procedure is not necessary”.
I saw the note “It is nearly impossible to get rid of all drift so that your copter remains completely motionless without any input.”, and accept that. But before I did the Save Trim routine I was conscious that I was holding a bit of left aileron all the time. After Save Trim I still had to stir the sticks a bit to hold the model in a steady hover in Stabilise mode, but it was no longer biased towards the right.
Replacing the prop on motor