Copter in SITL rotates uncontrollable along the yaw

ArduCopter Copter 4.6
, ,
21

I can get the copter to spin if it drops for long enough.

> mode guided
> arm throttle
# Right click map: FlyTo Alt 500m
> rc 3 1100
> mode stabilize

By the time the copter starts spinning VZ > 12 m/s which is going to cause issues for the prop aerodynamic model.

At some point the prop blades will stall and the model will cease calculating sensible lift and drag force vectors (both magnitude and direction).

There may be other issues related to output saturation at low throttle, but that would require more detailed analysis.

I’m not sure what use case you are trying to model here? The problem appears when the downward velocity is large and the throttle is reduced so the props are intentionally not generating lift, so flow through the rotor disc is reduced / reversed. Seems an unlikely mission profile?

22

Above I sent two logs with the bug present: one for LiftDrag and one for MultiCopterMotorModel. It is much easier to cause it with LiftDrag. To repeat all your actions is enough to catch the bug, but switch to Acro mode instead of Stabilize. Then, the effect will occur at 50-100m and below.

To recreate with LiftDrag:

  1. mode guided
  2. arm throttle
  3. takeoff 100
  4. rc 3 1150
  5. mode acro

To recreate with MultiCopterMotorModel:

  1. mode guided
  2. arm throttle
  3. takeoff 30
  4. rc 3 1150
  5. mode acro
  6. Pitch greater than 20 degrees
  7. Throttle is close to 10%, but definitely not zero.

In real life, we tested the flight of our copter in Acro and it falls the same way it flew. After that, it easily comes out of the fall using the throttle. The rotation effect is absent both during horizontal fall and during pitch installation, which allows you to perform various aerobatics.

Just as I wrote earlier, I tested this bug with following configurations in Gazebo Harmonic:

  1. Iris + LiftDrag + Ardupilot SITL
  2. Iris + MultiCopterMotorModel + Ardupilot SITL
  3. X500 + MultiCopterMotorModel + PX4 SITL
  4. Our university copter + LiftDrag + Ardupilot SITL
  5. Our university copter + MultiCopterMotorModel + Ardupilot SITL
  6. QuadcopterX-flightaxis + RealFlight Simulator + Ardupilot SITL

All of them have this bug. Please note, that the last configuration is rather different, and have only Ardupilot SITL in common with the other ones. Therefore, I conclude that the problem is more global, i.e. either in SITL, or in simulation, which stops the rotation of the motors at low throttle, as you said, while the real autopilot does not.

Therefore, if possible, please study the logs that I sent above. Also, could you explain how to test your model with <disable_braking>? Perhaps this will solve the problem. As far as I know, LiftDrag works with VELOCITY, while your model requires COMMAND. So, it does not work in the current state - the motor just do not react to the commands:

[Wrn] [JointController.cc:285] Failed to find joint [iris_with_standoffs::rotor_0_joint]
[Wrn] [JointController.cc:285] Failed to find joint [iris_with_standoffs::rotor_1_joint]
[Wrn] [JointController.cc:285] Failed to find joint [iris_with_standoffs::rotor_2_joint]
[Wrn] [JointController.cc:285] Failed to find joint [iris_with_standoffs::rotor_3_joint]

Thank you in advance for your help.

23

Also I made video with graphs and with ordinary IRIS with different plugins.
LiftDrag:

MultiCopterMotorModel:

Also our model:
LiftDrag:

MultiCopterMotorModel:

24

@VasilkovskiiVS - I can reproduce the effect you are seeing. The loss of yaw authority takes effect at different stages of the descent depending upon the model configuration and the attitude at the point the throttle is cut.

It’s difficult to say exactly what aspect of the models are causing the effect - from your comments it appears in Gazebo using different models for prop aerodynamics, and also different flight control stacks. It also appears in Real Flight.

It’s possible that all the physics models used in these simulations have a similar limitation as the angle of attack changes on the rotor disc - it’s very hard to say without detailed analysis and comparison to some very simplified thrust and torque models that are not subject to these effects.

It can be looked into, but I don’t think there are any quick answers that jump to mind.

26

Hello. I am experiencing a similar issue to the one you are currently facing.

I am encountering a similar problem with the Iris drone running SITL in Gazebo, and I still haven’t been able to resolve it. I am giving a 30° pitch angle and 0.5 thrust value with the SET_ATTITUDE_TARGET command. Under normal conditions, the Iris should move forward at a 30° pitch angle, but in the Gazebo environment, after moving forward for a while, it suddenly starts spinning around its own axis. I tried different thrust values, but the result didn’t change, and the same problem persists.

27

@Erenkeskin - really need a log to be able to follow up: ideally a dataflash log and a full description of the environment and all the commands from mavproxy or the program used to control the copter. Videos and screenshots are not that helpful in aiding replication of a particular behaviour.

28

Yes, I completely agree with you, and if you have the opportunity to provide instructions on how to set up <disable_braking>, I will be glad to test this part, as I think that your theory is partly correct. I will also be glad to work with you to improve this modeling system, as I consider it a necessary aspect of developing new systems.

At that moment, I have solved part of the problem by switching to the MultiCopterMotorModel and disabling some of the aerodynamic parameters of the motors, which gave a lower desynchronization of the motors during the fall. So I think that it’s the fastest way to solve it now. But as I said earlier, I will be glad to work on improving this system.

I plan to measure the physical quantities and logs of a real copter in order to fully configure everything and check the operation with the parameters from a real copter, as there is still a problem with this, but this does not apply to this topic.

As the project progresses, I will add to this topic, so please don’t close it yet.

Well, thank you for your theories and thoughts, they helped to improve the system.

29

As @rhys said, we really need more information on how to reproduce your problem at home. At a minimum, what settings and parameters does your Iris have and how did you change its model? And of course, the commands that you use to get this bug.