Hi,
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?
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.
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.
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.
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.