Where is the code for reduced attitude control?

[brunopinto900]

Hello,

I can't find Reduced attitude controller for yaw control in the master branch, this something its not yet completed? I did found the code on a pull request.

Thank you.

[Jaeyoung-Lim]

@brunopinto900 As you can see in the pull request: #35 the implementation never got merged.

If you are interested in continuing the PR, contributions are always welcome

[brunopinto900]

Ah i see. I am working towards drone racing, so i could continue the PR. Also, how hard could it be to perform benchmark? For example, comparing the different controllers available in the repo?

[Jaeyoung-Lim]

@brunopinto900 Not so hard, depending on what kind of benchmark you are looking for. You can just add test cases for different controllers and evaluate them according to your metric.

[brunopinto900]

At the moment, i am mostly concerned about time, how fast the quadrotor reaches the desired attitude (settling time). So it shouldn't be so hard. Have you thought of adding other controllers? I can help with that.

[Jaeyoung-Lim]

@brunopinto900 I have been wanting to add a model predictive controller to this repo, but haven't had time yet.

It would definitely be very interesting if we can have more controllers and also be able to do quick benchmarks between them

[brunopinto900]

Okay, i will implement the reduced attitude controller, taking the PR as base. But why didn't you merged? Did you had any issues? Is there something i need to know?

[Jaeyoung-Lim]

@brunopinto900 The PR got stale while the rest of the code progressed 😄 Also I didn't need it therefore, the code just got obsolete

[brunopinto900]

Hey again, could this be a nice controller to add to this repo?

https://www.youtube.com/watch?v=8OVsJNgNfa0

?

[Jaeyoung-Lim]

@brunopinto900 Why not 😉

[brunopinto900]

Have you tested the reduced attitude controller in the PR? Did it work? Because, in my implementation, the quad crashes every time after takeoff.

[Jaeyoung-Lim]

@brunopinto900 Yes, it was working are you using the PR branch directly? A lot have changed since then in both the simulation side and px4

[brunopinto900]

Yes, i am using it directly. Hmm, but what changed that might cause instabillity? By the way i am not using this function

Eigen::Vector4d geometricCtrl::acc2quaternion(Eigen::Vector3d vector_acc, Eigen::Vector3d heading_vec)

to convert acc2quaternion, i am using the Eigen::Vector4d acc2quaternion(const Eigen::Vector3d &vector_acc, const double &yaw);

Did you test for both?

[Jaeyoung-Lim]

@brunopinto900 I don't remember anymore. We would have to fix it if it is unstable 😄

[brunopinto900]

Experiments also revealed that a yaw Euler angle ψ is not well suited to define a desired rotation about the quadrocopter’s
z-axis. Due to the pitch angle θ, which is only defined in a range of [ −π/2,π/2], jumps in ψ occur if the pitch angle would exceed its range. If these jumps are not considered in the input trajectory, the quadrocopter may rotate unintentionally about its yaw axis.
https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/154099/eth-7387-01.pdf?sequence=1&isAllowed=y
page 20

I think thats what is happening here. Because in simulation, the quad rotates its yaw in an unstable manner. Gotta love control theory xD. What do you think based on your experience?

[brunopinto900]

I did this plot on plot juggler

reference/pose is the desired quaternion calculated by the reduced attitude control scheme (here converted to Euler angles)
reference/traj_pose is the trajectory reference attitude here converted to Euler angles

In the third axis, you see Yaw increasing (its wrapped around [-pi,pi], it just doesn't show). Doesn't matter. However the desired yaw oscillates back and forth!

Looks like, there is a spike in pitch and roll comands around ~10-15 seconds (that corresponds to the time the quadrotor starts to track the circle, after arm&takeoff!).

[mzahana]

@brunopinto900 I know this is an old discussion, but I am facing issue with stability when commanding the yaw angle close to -pi/2 and pi/2. My scenario is simply sending a static setpoint which is a fixed height from the origin, and slowly setting the commanded yaw angle towards -pi/2 or pi/2. The drone rotates well until it gets close to pi/2 or -pi/2 where it starts oscillating and then crashes.
Is there a reasonable explanation of this observation ?

@Jaeyoung-Lim Any comments on that?

[Jaeyoung-Lim]

@mzahana Do you have a log?

[mzahana]

@Jaeyoung-Lim I don't.
Have you tried to use this controller with, for example, a circular trajectory, where the heading angle changes according to the velocity direction, instead of just keeping it =0?

[Jaeyoung-Lim]

@mzahana No, but unfortunately I won't have time to reproduce it in the next weeks. If you can provide a log, I can take a look

[mzahana]

@Jaeyoung-Lim I will try...
Are you referring to a PX4 log file, or a ROS bag file?

[Jaeyoung-Lim]

@mzahana PX4 log (uLog)

[mzahana]

@Jaeyoung-Lim Here is a log file. This is in SITL using gz_x500
https://review.px4.io/plot_app?log=5592c1fc-9e0a-40fd-9cf7-826bac452cd6

[Jaeyoung-Lim]

@mzahana Sorry for the late reply,

You can see that the yaw saturates, and then loses control authority to stabilize the rest of the axis.
Have you tried constraining the maximum yaw velocity on the rate control level?

[mzahana]

@Jaeyoung-Lim Thanks for your reply. Are you referring to the rate controller on PX4?

[Jaeyoung-Lim]

@mzahana Yes

[mzahana]

@Jaeyoung-Lim
I found the the cause of my issue.
I was using the odometry from mavros/local_position/odom to get all the required feedback (position, velocity, orientation) 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 solved my issue.

However, ideally, there should be one topic (odom would be a suitable one) that has all these readings with the same timestamp, instead of taking them from different topics with different time stamps unless they are synced somehow.

[Jaeyoung-Lim]

However, ideally, there should be one topic (odom would be a suitable one) that has all these readings with the same timestamp, instead of taking them from different topics with different time stamps unless they are synced somehow

Not sure if I understand what you mean. Is this a comment about how mavros is sending multiple topics? Or on the geometric controller implementation?

[mzahana]

On the controller's side, all the feedback readings should be synchronized (with the same timestamp). The current implementation does not guarantee that since the readings are coming from different topics.

On the mavros side, all the needed readings are available in the odom topic, but there is some sort of transformation issue that I don't understand yet. That is why the odom topic is not suitable. However, the readings from the pose/twist topics are fine!

[mzahana]

One possible way to sync the different topics is to use the message_filters ROS library.

[akashspacesky]

hi @mzahana! I have tested this implementation both in sim and hardware, where i derived pose from mavros/global_position/local and velocity from mavros/local_position/velocity_local. The uav behaviour is stable, and it is able to track min jerk trajectories well.

I read the discussion above, and wanted to understand what do you mean by "incompatible transformations", is it related to deriving orientation from the msg?(correct me if i'm wrong)

Also, since I'm using two different topics for feedback here, would you recommend to use a time-syncing callback using message_filters library?