Lifting off with only 2-motors

[Al B]

For research/testing purpose, I need to lift off the quadcopter with only 2-motors. At least 1-2 meters for a few seconds.  However, the Pixhawk triggers an Inertial Nav Failure alarm (see link to video below); which seems to abort the take off.

https://youtu.be/G_BMFVmrnec

The Watt meter/AMPs analyzer indicates that it reaches 12.25A at 100% throttle and according to the MN1806 spec, at that point each motor should be capable of producing 345 to 395 grams; which should be sufficient to lift off a 516g vehicle.

Is there any code or parameter that I need to change to overpass the Inertial Nav Failure?  Or does anyone have any suggestions?

TIA!

[Robert Lefebvre]

I'm going to guess this might be gyro scale-factor error.  If it is, then there's nothing easy you can do right now.  It's a big problem that we need to solve.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Al B]

Thank you, Robert.  When you say, "this is a problem we need to solve"; do you mean at APM Filight Stack level or at the PX4 Flight Stack level?  Cheers!

[Robert Lefebvre]

APM, I'm not sure if PX4 is dealing with it.

I'm not 100% sure that this is the problem.  But we do have issues with continuous rotations.  I'm actually slightly concerned about what it's doing.  Is it disarming?  Or it's going into Land mode?  In the past, it would fail over to DCM. But we've removed DCM now.  I'll be a little concerned if it would go into Land from Acro mode for example.

On 25 March 2015 at 17:31, Al B <cagi...@gmail.com> wrote:

Thank you, Robert.  When you say, "this is a problem we need to solve"; do you mean at APM Filight Stack level or at the PX4 Flight Stack level?  Cheers!

[Al B]

Robert,

It's definitely not disarming. However, you brought a good point regarding DCM.

I connected MP to the quad via the 3DR radios and ran the test again. MP reports "DCM bad heading" as shown here:

https://youtu.be/Db7uMZWdNxE

Is the above normal since you mentioned that DCM was removed?  Is there a way to disable DCM?

[Robert Lefebvre]

Oh, which code are you running?  Sorry, I have Master on my mind where DCM is disabled.  3.2 still has it enabled.

If DCM is failing, there's not much more you can do.  My testing showed EKF gave up after several fast rotations, and hands over control to DCM. I've never made DCM fail, so if you are... that's really not good.  This flight mode is just not going to work I don't think, because of this problem.

The issue is that the gyros have scale factor errors, and we do not measure them.  So every 360 degrees rotation, there's an error that builds up.  In a typical flight, rotation speeds are low, and the compass is used to compensate for the scale factor error.  But with constant fast rotations, the compass can't correct the error fast enough.  

You might be able to turn off this check, and only fly in manual modes.  But if you try an auto mode, loiter, etc. it will be a big problem.

--

[Al B]

I'm running ArduCopter-3.2.1 release.  I'm flying in manual "Stabilize" mode without GPS (i.e. GPS-Denied environment).

Would you mind pointing out how I can turn DCM off? Thanks again, Robert!

[Robert Lefebvre]

There's no way to turn DCM off.  It is the most basic AHRS we have.  And the system is not set up to operate without an AHRS running.  It's a pretty fundamental problem.

The only thing you could do is turn that check off.  Look for the function ekf_dcm_check() I think, and then see what you can do with it.  I can't advise on much more than that.

On 25 March 2015 at 20:40, Al B <cagi...@gmail.com> wrote:

I'm running ArduCopter-3.2.1 release.  I'm flying in manual "Stabilize" mode without GPS (i.e. GPS-Denied environment).

Would you mind pointing out how I can turn DCM off? Thanks again, Robert!

--

[Al B]

Hey Robert,

I disabled the DCM_CHECK_THRESH via Mission Planner and I don't get the "DCM bad heading" message anymore.  Unfortunately, the vehicle still doesn't lift off the ground a bit.

Anyway, thank you again for taking the time and trying to help me to figure this out.  Hopefully Randy or other members have an alternative workaround or suggestion.

[Al B]

The "Relaxed" option didn't make any different either.  MP doesn't list the "Strict" option though.

Two files contain the ekf_dcm_check() method (ekf_check.pde and ArduCopter.cpp), should I change one of them or both?

[Randy Mackay]

     I think i may be missing some background emails so I'm not sure what the issue is.  Perhaps include a dataflash log file and explain in detail the situation.  I see there's a video of a HUD spinning in the yaw direction but it's not clear (to me at least) whether the vehicle is actually spinning.  Some other important details are what board is being used and what is being attempted (I guess two of the vehicle's propellers have been taken off and you're trying to make it takeoff?)

-Randy

[Randy Mackay]

    ..and just after sending, I found the background emails.. sorry about that.

    Ok, so what's happening is that the very fast rotation is causing DCM and/or EKF to lose their estimate of the heading and the EKF check or DCM check is triggering?  In stabilize mode though this shouldn't matter as it will not trigger a LAND in non-GPS modes.

     My guess is that the attitude controller is reducing the power sent to the motors because the body is spinning so quickly.  I.e. it's fighting against the yaw error by slowing the motors so maybe try reducing the Yaw Rate gains to zero on the MP's extended tuning screen.  This will mean that the attitude controller won't look at the yaw error at all and the motor outputs will probably be higher.

     A dataflash log would still be interesting to look at.

     This is really great that you're looking into this.  I've never heard of anybody trying this before with arducopter.

-Randy

[Al B]

Hi Randy,

I did what you suggested and tried to reduce the Yaw Rate gains to zero, but MP only allowed to lower them to the same gain that Pitch and Roll rates are set.  Unless you meant to set the Stabilize Yaw to 0 as well; which is currently at the default 4.500

I attached the logs as you requested so I hope they help to figure this out.  Thank you!

Before:

After:

[Robert Lefebvre]

That's a good point about the gains Randy.

Al, use the Full Parameter List to adjust those parameters.  That should let you set it to whatever you want. I suggest trying to reduce the Imax before you touch the P.

--

[Al B]

Randy's suggestion indeed made a big difference.  The vehicle is now able to lift off (video link below).  It'd be great now if I could keep it in the air a little bit longer so let me know if I should tweak any other parameters for that.

I'm attaching the latest logs in case you want to take a look at them.  Thanks you, both!

https://youtu.be/Sk3ORq3wKIU

[Robert Lefebvre]

Wow, that's not bad.  So have you made changes to the code to facilitate this?  Or is this standard code?

[Al B]

No, I haven't changed a single line of code.  I'm just using the pure 3.2.1 release.

I was not expecting such good result either so I'm quite impressed how well it performed and handled.  I just wish I could keep it a little bit longer in the air.

[Robert Lefebvre]

Is it crashing due to lack of power, or loss of control?

That's really amazing it flies that well already with standard code.

On 26 March 2015 at 14:44, Al B <cagi...@gmail.com> wrote:

No, I haven't changed a single line of code.  I'm just using the pure 3.2.1 release.

I was not expecting such good result either so I'm quite impressed how well it performed and handled.  I just wish I could keep it a little bit longer in the air.

--

[Randy Mackay]

Al B,

     Very impressive results!  that's quite an eye opener and really gives hope that we could potentially handle motor failures much better than we currently do.

     Theoretically you could control the position of the vehicle better if simple-mode was enabled.  You can do this from the flight mode setup screen on the mission planner.

     I'm not sure what your next steps are but here are some ideas to making it perform better:

• Need to get the heading more accurate.  We do some averaging of the last few compass readings which may be part of the cause.  When it's spinning very quickly that averaging will lead to the heading being behind it's actual heading.  Not sure how to fix that but it could be to completely remove the averaging and instead just use the latest.  Another more complicated method would be to merge the heading into the EKF on every compass reading.
• The gyros may be saturating.  It would be good to check this and if they are we could increase the maximum range.
• The gyro scaling may be incorrect at high rotation rates.  This could be corrected but would require a fancy calibration routine in which we rotate the vehicle at a known rate, capture what the gyro returns and calculate a scaling factor.
  
• there will be a delay between when we send a command to the motor and when it actually responds.  That will lead to the roll correction always being a little too late and will mean it wobbles.  You could fix that by modifying the attitude control so it projects it's attitude in X milliseconds and corrects for that instead.
  

-Randy

[Robert Lefebvre]

Definitely talk to Jonathan Challinger about the compass mag filtering problem.  He's already been looking at that, understands that problem well.  Might even have the fix already.

[Al B]

Thank you, Randy for those ideas/pointers.  Quick questions.

I actually ran all the tests with the Stabilized "super-simple-mode" enabled, do you think it will be better to switch to just "simple-mode" instead?

Also, will it make any difference to switch to AltHold mode as soon as it lifts off?

Robert asked early if it was crashing due to lack of power, or loss of control.  Actually, it's not too difficult to control it while it is spinning, but for some reason I cannot keep it up and starts to come down like if it is in Land mode.

I attached a second set of logs in my previous post so maybe you can take a quick look at them to see what forces it to land.  However, I have the feeling that it might be caused by what you already pointed out, either the gyros getting saturated or the gyro scaling incorrectly at high rotation rates.

Our goal is to create algorithm that allows the pilot to control the quadrocopter despite the complete loss of a motor/propeller and bring it down for a soft landing.

[Andrew Zaborowski]

Hi everyone,

I'm new here.  I think there may be some theoretical problems with keeping a quad in the air with only two props.  There are two scenarios that should be distinguished:

* Hover with just two props -- difficult to do.  What I see in the video is the quad spins up two props starting at zero yaw rate. The props generate lift at that time.  They also generate yaw torque so the quad's body starts spinning faster and faster. Whatever your motor's maximum RPM is, the quad's body is getting closer and closer to that RPM.  At some point the props will still be rotating fast in relation to the body but not in relation to the air and will stop generating lift.  In your video the presence of the two motors with no props helps a little because as these motors spin up they generate a tiny amount of torque in the opposite direction.  But this torque is only present while the motors accelerate and they can't accelerate for too long.

  You could run these two motors in opposite directions (with SimonK you can reverse direction in-flight) and that would help some but you won't have any stability in the axis of the no-prop motors and you'll flip.  Now at one point I had someone point at the ETH-Zurich "Atheltic power of quadcopters" TED video and say: but this guy flies with just two props! I suspect the trick is that he cuts the prop blades off at a small distance from hub but no completely, so these mini-props can still be used for leveling the quad even though they don't add any lift.

* Second option is if your goal is to only soften the landing.  This may be a little easier if you let the quad drop unpowered until low altitude and then with no yaw rate spin the two props up as quickly as possible to brake the quad in Z axis while spinning the body up.

Cheers

[Al B]

Thanks Andrew for the feedback.

The goal is definitely to only soften the landing at this point.  Unfortunately, Mission Planner keeps reporting "Gyros not healthy" after we run our tests.

So, as Randy pointed out, it seems that the gyro is getting saturated or scaling incorrectly and we are trying to address that right now.

[pritam....@gmail.com]

Slightly off but I had a motor failure few days back and the quadcopter crashed from about 50feet in air. But the crash was more of hard landing. One landing gear hit ground before the other and still didn't break.

But from the discussion that I have seen so far in this thread, I think I agree with Randy, there can be a possibility of improvement here. In my case if the copter could somehow detect that one motor has failed, it could have sacrificed attitude control for softer landing.I could visually see that the landing was hard because it was slowing motor down a lot to maintain attitude. Unfortunately I don't have a video, I wasn't expecting a crash :-).

Regards,

Pritam

--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

pritam

[Randy Mackay]

Al B,

    Definitely stick with simple mode instead of super-simple.  Super-simple will rely on the EKF position which would go bad because of the bad heading and high accelerations.

    AltHold mode would be good to try.  it should ramp up the throttle faster than a human pilot could to keep the vehicle in the air.  The only issue is that the altitude estimate might also go bad because of the high rotation of the vehicle - maybe it'll be fine, but it's not something we've tested for sure!

     Good point by Andrew.  The vehicle's downward thrust will drop as the vehicle's yaw rotation rate climbs.  I've had a chat with an ETH person and they provided two bits of info:

• there will be wind drag as the vehicle spins quickly which slow the rotation and will essentially be converted to downward thrust.
  
• a 3rd motor is required and the best case downward thrust will end up being the thrust that that 3rd motor.  So ideally the vehicle (with 3 motors) can produce downward thrust which is 1/4th the normal thrust.  Assuming the copter hovers at 50% throttle, it won't be possible to keep the copter flying but it should be possible to slow it's descent.

-Randy

[Al B]

Randy,

For our next set of tests, we'll use simple mode and AltHold.

However, this time we'd like to run the tests while the vehicle is in the air with all four motor normally running.  Then, while it is in AltHold mode (at an altitude of ~10 meters), we need to shutdown one of motor and immediately reduce the throttle of the opposite one. So, where within the ardupilot code should we place this algorithm?

Also, Mission Planner keeps reporting "Gyros not healthy" after we ran our previous tests.  How can we increase the maximum range to avoid that?

Thanks again everyone for your input and comments.  I'll post new videos with the results.