@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.
@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.
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
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.
Thanks for your answer.
@robin-ecn To answer your question, if you are interested in controlling the torque the same way you do with the bodyrates, you can use the actuator control setpoints in offboard mode. This will not perform as well as running the app inside px4, but will be easier to implement for prototyping
I have a question regarding this quote. The documentation says that velocity and acceleration in a SET_POSITION_TARGET_LOCAL_NED message are used as feedforward terms, which also appears like that in the control diagram. Thus, with the given message I should be able to perform quite dynamic (aggressive) trajectories?