Bug #367
open
Incoherence of drag constant in motor dynamics / wrench computation
Added by Martin Jacquet over 1 year ago.
Updated over 1 year ago.
Description
The drag constant used in the motor equation (motor->b) should be the same quantity as the drag coefficient of the motor used to compute the body wrench from the motor speeds.
It seems that there is an unconsistency in these values: in libmrsim, the default drag for the motor and the default allocation matrix G do not seem to match.
Also, in mrsim-gazebo, there are two different default values (ct=1e-5 ; b=5e-4)
The way to fix this is probably to compute the G explicitely from ct, cf and the propeller geometry, using the GTMR model as in nhfc (557e70ba). mrsim-gazebo reads those from the model file, while mrsim-genom3 should use a set_geom similar to nhfc.
Before merging the two constants, I would like to understand the
following discrepancy in the models:
- In the motor model, the friction is 'b.w' (linear in w)
- In the dynamic model, the Z torque is 'Kt.w²' (quadratic in w)
This is puzzling me ... shouldn't those two torques be similar?
Thinking about it, I think the motor model is missing was is called
the 'load torque' in the models, which is precisely the torque in
'Ct.w²' created by the propeller blades.
Furthermore, maybe the 'b.w' term can be neglected, and thus the motor
eq. would become:
dw/dt = -Ct.w² + K/2PI.i
What do you think?
Oh right, I actually assumed the drag coefficient in the motor equation to be the one induced by the air friction, but it should actually be quadratic en w given our models...
If b describes the solid friction internal to the motor, then I believe that both should be considered in our model since the dominant term is function of the motor speed:
Assuming b=5e-4 and ct=1e-5 (current default values), we have
- for w=20Hz: (b.w)/(ct.w²) = 2.5
- for w=1000Hz: (b.w)/(ct.w²) = 0.5
I pushed a number of commits in libmrsim, mrsim-gazebo
and mrsim-genom3 to address (hopefully) all the issues.
- the rotor model has gained a quadratic drag term matching what is
used in the rest of the software and also in the ref. above. The
linear term is kept but set to 0. by default.
If you can test it and it works for you, I'll make a release of those
projects soon.
I did some tests with both mrsim-genom3 and mrsim-gazebo, it seems to work fine, at least for the overall drone behavior.
So, in your opinion we should neglect the viscous friction term b*w? We can probably measure b empirically on the motor (removing the blade) if we can measure the current sent to the motor for rotating in steady state.
Anyhow, I agree that it's most likely less impactful than the aerodynamic drag term.
Martin Jacquet wrote in #note-7:
I did some tests with both mrsim-genom3 and mrsim-gazebo, it seems to work fine, at least for the overall drone behavior.
So, in your opinion we should neglect the viscous friction term b*w? We can probably measure b empirically on the motor (removing the blade) if we can measure the current sent to the motor for rotating in steady state.
Anyhow, I agree that it's most likely less impactful than the aerodynamic drag term.
it depends on the speeds, there is for sure a low enough speed for which is more impactful, if Bangura has it there is probably a reason, the best would be identify from real data and check if it is needed to estimate well the behavior
On Monday 26 Sep 2022, at 15:45, Martin Jacquet wrote:
So, in your opinion we should neglect the viscous friction term b*w?
In the simulator, I think this term is mostly irrelevant.
And if it's not, then it should be considered in the control software
as well :)
We can probably measure b empirically on the motor (removing the
blade) if we can measure the current sent to the motor for rotating
in steady state.
As a first approximation, you can check the current drawn on a power
supply by spinning the rotors (without props). Remove the ~100mA of
the odroid (you can also check that when not spinning the rotors),
divide by 4 and you're done :)
Also available in: Atom
PDF