I will try as well.
Thank you very much for your help:grinning:
I found the following link:
(Static) Thrust = f(RPM).
I think it should be reasonable to calculate RPM = f(Thrust) given that equation.
(S)He also explains the derivation of the equation.
@BossHater: how did you come up with your equation?
throttle = throttle + (a_cmd - a_curr) *k
Is there any scientific background to that or is it a fit using some data?
I don’t want to sound rude, just wondering…
I thinks his approach is more like a P controller…It is not based on the model
@robin-ecn The only thing you need to figure out is the scaling factor between the normalized thrust and the acceleration. This is hardwawre dependent on what kind of mootrs / voltage you are using.
A good guess can be made with the hover throttle. For example, if your drone hovers at a normalized thrust value of 0.5, that means the normalized thrust value of 0.5 is going to be close to accelration value of 9.8m/s^2.
This way, the normalized thrust values can be mapped to the actual acceleration.
My bad, it obviously is…
Still, maybe a function would do better?
I think it could be better to find the exact mapping. Maybe this How are pwm values set after controllers outputs are calculated for quadrotors? would be useful for you.
Thanks man.
But we are not sure the mapping is linear, right? I am not sure about that. That is why I am stepping inside of the px4 and mavros codes trying finding out the exact relation.
@robin-ecn The actuator commands corresponds to the PWM values commanded on the ESCs. The nonlinearity is not that high and I believe the performance will not be too bad even if you assume that it is linear. Given that the thrust values will not vary too much around the hovering value of the thrust commands.
Even if you manage to model the nonlinearity between the pwm and thrust generation, this will no longer hold when the drone starts to move dynamically as the thrust generated by the rotors will vary on the load and speed.
There are a lot of people testing motors and measuring thrust vs pwm values on benches so this could be a good reference for you
Thanks so much for you reply. I agree even with the correct model, it is not the case when the drone moves dynamically.
Check the actuator_control in mavros mavros_msgs/ActuatorControl Documentation.
I believe it is useful.
@robin-ecn are you by chance talking about this topic (Control Multicopter via thrust f and moments M)?
It was me as well.
Hi, Jaeyoung.
I have a question. When you said “The actuator commands corresponds to the PWM values commanded on the ESCs.”, you mean “actuator_control provided by MAVROS are actually the PWM of the motors”?
Now I am trying to control the motors directly, do you have some good reference on that.
Thanks very much
@robin-ecn You can look into how the mixer works : https://dev.px4.io/en/concept/mixing.html
The actuator control message goes through the mixer as you can see here: http://docs.ros.org/api/mavros_msgs/html/msg/ActuatorControl.html
Hi, Jaeyong.
In order to control each motor directly, I have read the webpages that you recommand and thank for that.
Now my idea is I receive the pose information from mocap in my conputor and I compute the required force and torques to track a trajectory. Then, I can mapping the force and torques into angular velocity for each motor. Then I just need to send those commands to /actuator_control.
I still have two questions in terms of mixer for quadrotors.
(1) I need to write a new simple mixer using tag M instead of R?
(2) I find the quad+x.main.mix to understand how the mixer maps the roll, pitch, yaw and thrust into the actuator commands. But there is only one line
R: 4+ 10000 10000 10000 0
I can not understand how this is transformed to the actuator_control.
Could you give me some help? Thanks
@Jaeyoung-Lim yes, is it possible to find out how those roll, pitch, yaw and thrust commandes are transformed into actuator commandes, like PWM?
This is because I try to understand how this works before writing my mixer file. Maybe it is not necessary?
@robin-ecn So the purpose of a mixer file is to use actuator commands without knowing how exactly the geometry of the drone is. If you want to look into the multirotor mixer you can look here
The attitude controller simply commands angular moments and thrust and this translates to the actuator inputs according to the geometry of the mixer. This enables same attitude controller be applied to various airframes.
Hello everyone,
I am also trying to send thrust and attitude values to the drone with setpoint_raw but I end up with a problem which I think is related to the mode. The problem is that when I arm the drone and then publish a setpoint_raw message, it activates a failsafe saying: no RC and no Offboard. I am currently in the Offboard mode and I wanted to ask you which mode I should use to send thrust commands and not position commands. Thank you in advance.
@pedro27 You need to be sending setpoints before you arm the drone and before you enter offboard mode