Position trajectory to MC position control

I have a few questions about the position control.
My goal is to send a real-time reference trajectory from the companion computer to the position control. My trajectory consists of position, velocity, acceleration and jerk.

My questions:

  • Are velocity,acceleration and jerk used in the position/attitude control for the feedforward?
  • Is the SET_POSITION_TARGET_LOCAL_NED message supported, i.e. if I send that message with a certain frequency, is like a trajectory is passed directly to the position/attitude control? Or is it used more like a waypoint?

@tuloski You need a seperate controller in order to follow a trajectory. I am doing it by using offboard control setpoints using mavros.

It is still in a work-in-progress, but hope it helps.


Ok thanks.
But if I need to use a different controller I’ll implement mine: https://ieeexplore.ieee.org/document/7458128/ :slight_smile:

Even though the works from Lee and Scaramuzza are very good.

But now what would happen if I send the SET_POSITION_TARGET_LOCAL_NED?

@tuloski The project is intended to implement different controllers, so contributing to the repo will be also cool.

As long as you don’t have position setpoints dynamically moving, the quad will follow the trajectory.

The video below shows position setpoints sent to a quad at 100Hz using mavros. However, this approach will fail when your trajectory is dynamic.

It will fail because the controller is not able to handle it? What do you mean by dynamic? Aggressive?

I see, but I prefer to implement low level controllers on the micro and in a real-time environment such as the px4, because on ROS there is no timing guarantee, especially for quick attitude control.

@tuloski I mean by dynamic trajectories of having high velocity / accelrations.

If you send a position setpoint, the position controller assumes that your target position is static. Once your target position starts to have relatively large accelerations, your position controller will not be able to properly track the setpoint.

1 Like

@Jaeyoung-Lim Is it possible to implement geometric controller in mc_att_control_main.cpp? If it is impossible, can you tell me why we need seperate controller? Actually, I want to change the control algorithm of firmware from PID to geometric one.

@chmi0611 It is possible.

However, if you are testing out controllers or in development, it is better to have it running OFFBOARD as you can always shut down the setpoints published from the flight controller and regain control of the vehicle.

You probably need to change mc_pos_control and mc_att_control, the flighttask (where the setpoint is coming) and probably other parts (I didn’t check all the code).

@Jaeyoung-Lim you can test everything in gazebo simulator with SITL.

@tuloski You are right on that point

@tuloski @Jaeyoung-Lim

Hi, guys. Thanks for comments.

Currently, I’m trying to modify mc_att_control_main.cpp and mc_pos_control_main.cpp.

I read those pages but still not sure about thrust and torque.

As Jaeyoung said, it would be okay to normalize thrust but the problem is torque.

Can you tell me the relationship between _att_control and torque?

Or is it okay to use normalized torque as _att_control?

I still didn’t understand how the output of att_control is mixed into pwm output.
I think the normalized wrench is bullsh!t. Every serious controller outputs force (thrust) and torques. IMO the output of the controller should be a not-normalized wrench and then the mixer should be in charge of transforming the desired wrench in actuators output (for example knowing the pwm to thrust curve).

@chmi0611 which controller are you trying to implement? If needed I should have somewhere the Simulink code and the C code generated from simulink about the controller I developed and linked a few posts before.

@chmi0611 I am not sure what you want to know about the realsionship between attcontrol and torque?

If you want more information on the controller, the controller diagram might help you understand how the controller works.

The scale of the torque may change depending on your airframe. However, this will not (until some extend) change the stability of your controller and can be also tuned by the PID values.

@tuloski I’m trying geometric tracking controller same with Jaeyoung.

@Jaeyoung-Lim I mean, is it okay to use torque as att_control.

In the diagram, it seems that derivative of body rate vector is att_control.

But when I read this page (https://dev.px4.io/en/concept/mixing.html), it should be attitude, not a derivative of rate vector.

I get confused.

Hello @Jaeyoung-Lim ! I wanted to implement trajectory tracking in SITL. I found this tutorial https://404warehouse.net/2016/08/10/trajectory-following-with-mavros-on-raspberry-pi/. I wanted to implement trajectory tracking without geometric controller. I needed your advise regarding this, as in which page should I refer to for trajectory tracking

@Vrinda If you don’t want to run a external controller, you can use the setpoint_position/local using mavros as shown in this tutorial

Yes @Jaeyoung-Lim, I will do as you suggested. Thanks much !

Could you please explain a little how we can use torque as att-control? Actually, i am trying to control a drone with the thrust force and torques directly instead of the normlised thrust value and the body rate.

I have not done this. But just a suggestion. You can compute angular acceleration from torque (I don’t know how you will compute inertia of your drone), and from angular acceleration you can compute the desired body rates. I may be wrong.

@robin-ecn The question is off-topic of this thread. Please create a new topic