But, do you find a precise model for mapping thrust into the normalised value? Also, did you try to control the torque?
Currently working on the same. Will update once some result is obtained.
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.
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 http://docs.ros.org/melodic/api/mavros_msgs/html/msg/ActuatorControl.html.
I believe it is useful.
It was me as well.
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
The actuator control message goes through the mixer as you can see here: http://docs.ros.org/api/mavros_msgs/html/msg/ActuatorControl.html
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
@robin-ecn It is because it is a multirotor mixer, geometry of 4+. It is explained in the document
@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?
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.