Hello,

Long time APM user, but am setting up a large hex with 3DR Pixhawk for the first time.

The hex is trying to flip on takeoff as soon as I spool up.

The log file shows that there is a significant desired roll:


Things I have tried:
1. confirmed multiple times that the motors are in the right channels and spinning the right direction
2. Reloaded the firmware (AC 3.2), confirmed Hexacopter 'x'
3. Redid accelerometer calibration
4. Checked all radio calibration and radio reversing.

If I spool it up in my hands at a very low throttle, the motors respond in the correct fashion to stick inputs and if I twist the frame around.

I have attached a log file. Any help is greatly appreciated!

Views: 928

Attachments:

Reply to This

Replies to This Discussion

Your RCIN and RCOUTs look OK. Your number 2 motor is being commanded to spin a bit faster than your number one, but not a lot more in the absolute sense and it shouldn't be enough to flip it. I'm wondering if you have your ESCs calibrated properly? If one or more ESCs isn't calibrated right at the upper end it can go to full throttle well before the others. But if its low end happens to be OK then when you do a tilt test in your hand at low throttle you wouldn't see a problem.

Another way to see what's happening is to tie the hex down and apply higher throttle levels. But I'd try an ESC recalibration first.

Tom, thanks for your response.

I also tried plugging the other ESCs/motors into the #2 channel on the Pixhawk. Whichever motor is connected there  spins way faster than the others. Thus, it is not an ESC calibration problem. I also connected the motors directly to the receiver to test their calibration: they all behave normally and in sync then.

ESC calibration problem does not explain why the flight controller is giving such a large roll command when sitting level on the ground.

Here is a shot of the motor outputs. Def not right, especially considering this is sitting level on the ground.

Oh, OK. I assumed that was you nudging the stick for roll. If you compare motor 2 of RCOUT with Channel 1 of RCIN they pretty much match so the Pixhawk seems to be wanting to do what it's being asked. So your RC Rx must be feeding something weird to the Pixhawk. You didn't mention how your RC RX was setup. The Desired Roll could be the result of this "something" providing roll pulses.

"If you compare motor 2 of RCOUT with Channel 1 of RCIN they pretty much match so the Pixhawk seems to be wanting to do what it's being asked."

No, RCIN 1 is throttle for me. That is me raising the throttle to take off. When I do, all motors ramp up, but the left motors WAY more and it tries to flip.

If you look at the picture in my first post you will see the Pixhawk is giving a desired roll. That is not a result of the RC inputs, which are all at neutral.

For chuckles I extracted your parameters from your log file and compared them to the parameters I currently have in a Tarot 650 running 3.2 on a Pixhawk. I specifically looked at the accel parameters. They were all reasonably close except for INS_ACCOFFS_Z. Mine was -1.577 and yours was -0.119. As I said, all the other accel/gyro parameters were within 20% or so.

Humm. I think the accelerometer is fine. I am reading 'az' to be -1000 sitting level and the HUD in mission planner is level.

I am thinking there is something simple that is wrong in my setup, but for the life of me I cannot figure it out.

Cheers,

why aren't you running the default channel order? I prefer to change the channel order on the radio rather than APM, have you done the opposite?

Maybe you have found a bug using non standard channel order.

Channel one is normally roll, maybe your throttle is still being mapped to it somewhere in the code.

Also using a non standard channel order without saying what that order is from the start makes it impossible for people to look at RCIN and understand what its trying to do :)

Stu

Stu, i am using an orangeRx with sbus output to pixhawk.

I had to change around the rcmap channels on the pixhawk to make them correct with my DX7s.

Maybe it is some weird bug... but the heli responds to all stick inputs in the correct way. The only problem is that it is also trying to roll right the whole time.

ah ok, that's a pain..can't rewire. I guess the dx7 doesn't support reallocating? its a long shot either way.

Which channel is roll? is it 2 as per my quick google? If so its not 1500 for centre stick, it stats at 1517, try retrimming it to 1500. might be enough to affect things at first throttle up. Actually more than one RCIN is above 1500. Although I don't understand why des roll is a high as it is from that.

your AHRS_TRIM_X is -0.0105 ish Which I make to be about -0.6 degrees roll trim...bugger all though. might be worth retrimming though just in case.

Stu,

You are correct. There is some bug with the RCMAP.

I pulled out the 3DR PPM encoder, removed the SBUS, and set the RCMAP assignments back to default.  Now it works as it should!

I need to escalate this bug to the devs... I would really like to use SBUS from the OrangeRX.

Thanks for the help.

Glad you sorted it, at least you can get flying, hopefully the fix will come soon. the simplicity of sbus wiring is very nice.

Reply to Discussion

RSS

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service