Drone unstable when the target yaw is more than 0.7 rad

[anandvgeorge]

Hi all!

I am simulating the iris drone in SITL mode. The geometric controller is given trajectories of type trajectory_msgs::MultiDOFJointTrajectory. It is generated by a mav_local_planner node. The flight looked unstable. I tuned rate and attitude controllers in PX4, and adjusted the gain values of the geometric controller such that the drone hovers at a point. Even after this, whenever a trajectory is given, the drone starts to move and after a point, it flies in unstable manner.

After spending much time, I observed that if the target yaw value is more than 0.7 rad (absolute value), the drone goes unstable. To verify this, I hovered the drone with rate commands, and published yaw values through yawtarget topic. The drone rotates to the desired target yaw. If the absolute value is more that 0.7rad, it loses control and moves sideways. As soon as I set a smaller values (-0.7 to 0.7), the drone comes back to the hovering point and stabilises there. Similar observation is made if I give a trajectory; if I provide a small yaw target by publishing it while the drone tries to follow the trajectory, the drone reaches the goal (of course, not following the given trajectory).

Can anyone explain why this is happening? Or how to fix this problem?

Thanks in advance.

[Jaeyoung-Lim]

@anandvgeorge It is hard to judge what the problem is without looking at a log

[anandvgeorge]

@Jaeyoung-Lim can you please tell which all logs are relevant here? Should I enable DEBUG flag somewhere before uploading the logs? The output of geometric controller process doesn't show any errors or warnings though.

[Jaeyoung-Lim]

@anandvgeorge I am talking about the flight log in uLOG format: https://docs.px4.io/main/en/log/flight_log_analysis.html

[anandvgeorge]

Thank you for clarifying. Here is the log - https://logs.px4.io/plot_app?log=5d320854-89e9-48dd-b006-bc1b37f7294b. I have changed the yaw a few times. After final change, the drone drifted so much and later crashed to the ground. So, data after time 11:40 would probably not be useful.

[Jaeyoung-Lim]

@anandvgeorge Thanks for sharing the log.

The current implementation does not deprioritize yaw control. However, if you are flying a multicopter the control authority of yaw is quite limited, saturating yaw controls and potentially compromising attitude control performance on other axes.

This is a well-known problem for quadrotor control (e.g. https://youtu.be/6YEMxFgToyg)

You can try to address the problem in two ways

• You can be mindful of what references you send to the vehicle to not result in large error to references, especially in the yaw axis
• You can try to decrease the maximum yaw rate reference that the controller will use for the angular rate controller on the px4 side.

[anandvgeorge]

@Jaeyoung-Lim thank you for the explanation.

I gave yaw values such that the error to reference is 0.1 rad (just after launching the geometric controller node and the drone hovers at 3m above starting point). The drone became unstable after 0.7 rad. Interestingly, when I launch sitl_trajectory_track_circle.launch, as the drone flies, if I give yaw input, regardless how big the value is, the drone changes the yaw and still tracks the circle. The only difference I can see here is the trajectory_publisher node sends controller_msgs/FlatTargetmessages to geometric_controller. Would that affect the controller somehow?

I haven't tried reducing the maximum yaw rate, I will try that also.

Edit: One more thing I noticed is, when the drone is just hovering as mentioned above, the controller is actually not supplied with new messages (FlatTrget or the MultiDOFJointTraj types). Maybe this could be another reason. I will check this also and update here.

[anandvgeorge]

Hey @Jaeyoung-Lim . Just an update. I am really not sure if this issue is related to this controller. If the drone is in POSITION mode and when the yaw is more than 0.7 rad, the drone moves in a similar way. When the yaw is higher, there are setpoint inputs to attitudes and rates. Probably coming from pixhawk's controllers. Have you seen such an issue before? Or any clue what would be causing this? (Bad tuning maybe?).

I will debug the issue and update here. Also, closing this issue, will reopen if a similar problem is seen after fixing this issue.

[mzahana]

Hi @anandvgeorge
I have the same issue that you described. Have you solved it?

I also mentioned it in issue https://github.com/Jaeyoung-Lim/mavros_controllers/issues/186

@Jaeyoung-Lim Any comments on this?

Thanks

[anandvgeorge]

Hi @mzahana . From my observation, this issue was happening whenever I gave odometry input to pixhawk through /mavros/odometry/out topic. When I stopped giving odometry input via mavros, this issue was gone. Even when the drone is in POSITION or HOLD mode, and if the VIO input is present, this above behaviour was seen.

I could not give VIO input properly to pixhawk by following the documentation, I tried in both simulation and on a real drone, the values were not proper when inspecting through GCS. Probably I miss some key parts while doing it (probably some frame transformations). Since I could control the drone directly with the geometric controller without publishing VIO to mavros, I stopped trying to fix it.

[mzahana]

@anandvgeorge Thanks for your reply. Actually, in my case, this is happening in SITL (simulation). So there is no VIO in this case, which is weird.

[anandvgeorge]

In the SITL simulation, I took the pose of the drone from Gazebo and published it as odometry to mavros. When I stopped that and use that odometry values directly in geometric controller, the issue was gone. So, my issue was never with the geometric controller, rather incorrect VIO input to mavros, which affected drone flights in normal PX4 modes (ALTITUDE, HOLD etc.).

[mzahana]

@anandvgeorge I found the the reason, at least for my case. I was using the odometry from mavros/local_position/odom and it seems to have some sort of incompatible transformations.

Then, I used position and orientation from mavros/local_position/pose and linear velocity from mavros/local_position/velocity_local

This solve my issue.