• Jan,

    Airfoil TMD data. I assume everything is in radians.

    "Attached Center" is that the AOA of the middle of the Cl/Alpha curve, or is it the AOA at which Cl = 0?

    For exemple I have an airfoil -7 +14 thus a range of 21deg (to put in radian) so "attached range" is 21deg

    The "center" of that curve is at 4deg AoA with Cl of 0.5, is that my "attached center" value, or is it the AOA where Cl =0 (-1deg in this case)?

    Also in your graphs on the wiki, for the attached range, the upper graph (alpha) shows that it goes between - and + (thus the number is the full range) on the graph below (with airfoil pict) it is represented as half (once between 0 and minus, and one between 0 and plus). I assumed it's the former.

    Stall range is also represented twice, but I believe that is probably correct.

  • The full linear range of the airfoil goes from -AttachedRange - AttachedCenter to +AttachedRange - AttachedCenter.

    The AttachedCenter shifts the center of the attached range but I think the sign is counter-intuitive here... I have not checked the code but it feels like that more negative values shift the range towards a more positive angle. I think of it like:

    aoa += AttachedRange

    if ( aoa > -AttachedRange && aoa < AttachedRange )

    -> cl = Cl0 + aoa * ClAlpha

    To the left and to the right of that you add the StallRange angle to get the stalled region.

    The angle for cl=0 is not defined in the airfoil parameters, you have your ClAlpha 2 pi slope and your Cl0 lift at zero angle of attack instead.

    AttachedRange is 0.5 * ( max - min ) and AttachedCenter is -0.5 * ( max + min ).

    So for you that is

    0.5 * ( 14 - (-7) ) = 0.5 * 21 = 10.5 degrees attached range

    And -0.5 * ( 14 + (-7) ) = -0.5 * 7 = -3.5 degrees attached center.

    If I did my maths right. It's before the first coffee ^^

  • OK Thanks.

    So attached range is indeed the value in the positive region, and same in the negative region, thus 1/2 of the maximum span 1/2(max -min) [0.5(14-(-7)) or 1/2*21 or 10.5]

    The attached center is the offset of the real center, compared to the mathematical center.

    Here the math center is at -10.5 from max or +10.5 from min

    But the real center is with 14 to max and -7 to min, so I have to move the center by the distance between my max and min

    or 1/2 (|max|-|min|). So here 1/2 (|14| -|-7|) or 0.5 (14-7) or 3.5

    And I give it a negative sign to move the center below the math center, so -3.5

    Which indeed gives me an upper of 3.5 + 10.5 = 14

    and a lower range of -10.5 - (-3.5) or -7

    Here with more exact values:

  • Okay guys, some updates, since I had time to test the new airfoils that ussiowa gave me.

    First, I had to tweak the CG so that the flying is stable (like in your story, I have experimented, and I didn't rely on theory ;) ). After some tweaking, I was able to observe some stable flying behavior. However, I couldn't experiment much, since I somehow wasn't able to steer the glider.

    I hooked up the pitch and roll input from the simulator to a linear joint, and to the graphics. The graphical part works, because when I steer the glider, I actually see the pilot's graphics pitching/rolling. However, I am dubious that the linear joint is working because steering doesn't have an effect on the flying behavior... So I have to fix this...

    Does anyone know if there is a way to debug the rigidbodies while in the simulator ? I would really like to be able to verify that the pilot's rigidbody pitches/rolls when I control the plane in the simulator.

    Anyway, thank you guys for your involvment in the project !

    Antoine

  • I hooked up the pitch and roll input from the simulator to a linear joint, and to the graphics. The graphical part works, because when I steer the glider, I actually see the pilot's graphics pitching/rolling.

    You don't have to animate the graphics if you already simulate it in the physics!

    Just attach your pilot graphics to your rigidbody that is moving in the physics....

    In Aerofly FS we only animate things that do not have physical properties.

    For example: almost all of the landing gear parts are not animated. Only the locking mechanisms are actually an animation, the test is pure physics simulation and thus always looks physically correct. That includes gear contraction, gear retraction, wheel deformation, gear bending, wing bending as the gear hits the ground and what not.

    Similarly if you hinge your pilot in the physics you can expect it to collide with the ground correctly (if you attach a collisionhull) and the center of mass moves correctly and the graphics always moves with it.

  • Well the question could be as to whether the CG of the group of rigidbodies is dynamically calculated or not?

    If it is, then at least we know the physics dynamics of the masses could be correct, yet somehow the "plane" is not reacting properly. We can continue investigating that way.

    If the CG is calculated once only (at load up or something similar, which could be very possible with a regular aircraft since it is not expected to change during flight (except Concorde and other limited exceptions)), then we'd have to find another way to simulate that part. We can introduce "virtual" control surfaces that would move from the dynamic standpoint (ailerons, rudder and elevator), but that would not exit graphically. That way the "plane" would react properly, and the graphics would be proper as well (only pilot moving).

  • Okay guys, some updates, since I had time to test the new airfoils that ussiowa gave me.

    First, I had to tweak the CG so that the flying is stable (like in your story, I have experimented, and I didn't rely on theory ;) ). After some tweaking, I was able to observe some stable flying behavior. However, I couldn't experiment much, since I somehow wasn't able to steer the glider.

    Antoine

    Remember that the positions of the CG with the pilot and without are fundamental to the behavior. I'm thinking that the CG without should be at 25% MAC (I will tell you what that is in a few minutes, I have to calculate), and that the CG of the pilot itself should be located like a normal human being.

    Provided that the suspension of the control bar is at the right point, then it should work somewhat.

    I don't know yet about "joints" but I'd think that a rotating joint at the point of control bar suspension would be more accurate (to the reality) than a linear one. But linear may work too.

  • Yes of course it is :)

    Neat! Sorry for questioning, I guess I'm too used to old sims and low computing power, where everything had to be "simplified" to fit the computing power and time.:)

    So great, that makes things easier for us in a sense, all we have to do is model the reality correctly.

    Jan, any input on this CG location. I'm thinking the CG of the glider is at 25% MAC and then the addition of the pilot moves it forward enough to create the static margin in essence. Or could it be that the glider itself has the static margin (CG forward from AC) in that it would fly "empty" correctly, and then the pilot is loaded at that particular CG (except lower of course) and then its motion laterally and longitudinally from the neutral point is what steers the glider?

  • OK so MAC (Main Aerodynamic Chord) is at 215.86 cm from center line and is 142.20 cm.

    That means that the Aerodynamic Center (AC) for that wing is at 131.58 cm from the nose of the wing (25%).

    Antoine that should be the starting point for the CG of the empty glider. I would expect that the CG point for all together in flight be around 125.4 cm from the nose and in the horizontal plane (20% of MAC or a 5% static margin).

    These should be good numbers to start and should provide a flyable system. We can fine tune later.

    The vertical position of the CG is whatever it is vertically from that point (125.4 from the nose, center line)

  • Thank you all for your responces, and sorry for the delay, I am pretty busy these days ;)...


    Yes of course it is :)

    That's some good news ;), it means that there is an error coming from my side. For now I have animated the graphics and the physics separately, so that's probably a bad pattern according to your answers. This also explains why I see the graphics moving but no behavior change. I will make sure that the graphics follow the physics, so that I can be convinced that the masses are actually moving.

    OK so MAC (Main Aerodynamic Chord) is at 215.86 cm from center line and is 142.20 cm.

    That means that the Aerodynamic Center (AC) for that wing is at 131.58 cm from the nose of the wing (25%).

    Antoine that should be the starting point for the CG of the empty glider. I would expect that the CG point for all together in flight be around 125.4 cm from the nose and in the horizontal plane (20% of MAC or a 5% static margin).

    These should be good numbers to start and should provide a flyable system. We can fine tune later.

    The vertical position of the CG is whatever it is vertically from that point (125.4 from the nose, center line)

    Thank you very much for your calculations, you rock !! I didn't have time to dig into your results, but I will definitely use your values to position the pilot relative to the wing.

    Again, thank you guys so much for your involvment <3

    Antoine

  • Hello !

    I hope you're still doing fine in this weird 2020 :P. I finally had some time to work on the project, and I made some progress, so I wanted to give you some signs of life !

    I used your aerodynamic calculations, ussiowa, and they are quite good, even though there are probably some things that we could improve. Now the hangglider is flyable, and it can be controlled using only mass transfer. Here is what I have noticed, and what I should improve:

    • The computation for the CG and the MAC seem to give a pretty "tail
      heavy" behavior, where the glider has a tendency to pitch up. I have tried to move the pilot forward and it gave some better results (I moved it about 50cm forward, which is a lot!). Maybe that behavior could be coming from the aerodynamic of the wing as well.
    • The hangglider seems to roll pretty slowly (pitch is fine however). It
      takes about around 5 seconds to roll to a 45° angle with the pilot leaning to the right pretty heavily. That might be caused by the pretty big wingspan. Beginner gliders have a smaller wingspan as well, so that's maybe the reason why. And additionaly, some gliders have elevators as well, so I will try to add some elevators to see if the behavior is better.
    • I have added a vertical stabilizer to the glider (which is invisible) to prevent it from "sliding". Without that stabilizer, the glider is uncontrollable, starts turning in all sorts of directions, and it seems to be because of that "sliding". With the stabilizer, the glider is now very stable (and it could be another reason for the slow rolling).
    • Moving the pilot around makes the glider "jiggle". I added a "servoclassic" with the speed set to "2.0" to smooth out the pilot movement and try to mitigate that problem. It is better, but still present. I think this is due to how the rigid body system works, where the impulses that are applied to the bodies are causing those jerks.
  • Hi

    Glad to see your making progress, it's not easy at times as I know all to well.

    With regard to the roll, I have noticed this too with my Apache, I'm thinking it could be caused by my joystick and not from the sim so something to check before you join the madness of chasing a problem that isn't there.

    Have you read the Wiki concerning the ServoClassic. there are more inputs you could apply. Of course you need a degree in maths to understand it =O

    Steve

  • If 125.4 is "tail heavy" (whatever that means in a no tail aircraft), move it slowly forward (move both, the hanging point, and the CG of the empty glider).

    I'm still assuming that the hanging point of the control system is at the CG of the empty aircraft. When laid on the ground, the aircrafts always rest on their rear, which may mean that it is forward from the empty aircraft CG (not sure on this one). If and when you have access to a real one, check where the CG is in relation to the hanging point of the control system. It's easy just lift it up by the hanging point and check if it balances or fall forward or backward. then find that equilibrium point. If there is a distance, use that for the model (and let me know what it is).

    If the glider behaves worse, or still has a tendency to pitch up, I will change the Cm (pitching moment) of the airfoil. I used the real data, but for Cmbase I had to improvise (see post 44 above).

    I wouldn't mess with elevators yet, The more parameters and variables you introduce, the harder it will be to tune.

    Also the more we stray from real aircraft, the more trouble we're getting into since the physics engine is real and exact.

    Try increasing the pilot weight to see what happens.

    Hangliders do not strike me as having a fast rolling rate IRL, but I don't really know. If you know it's different, then so it is.

    I don't know anything about servoclassic (when I'll get a minute I'll look at it, ("degree in math" from Steve got my curiosity and interest picked up :P). However I can tell you one thing, the movement of a pilot on the control bar is heavily "dampened" by nature, and has 0 elasticity, so that should probably be taken into account, and if the slide has any elastic property and no or small dampening, then it could be the cause.

    The motion should be only affected by the control (joystick), gravity should not affect that motion at all (to simulate the fact that the pilot will adjust the strength in his arms to compensate for gravity change and so on).

    If somehow the current modelisation moves a moveable "object" along a slide, banking will create an adverse motion just by effect of gravity on that object and slide, that is not what we want, and it may be the source of periodic "instability" (which is what I think you mean by "jiggle", don't hesitate to use the French term if it's easier for you to describe)

  • Regarding the slow rolling, I think that it might be ok. I have never flown a hangglider, but I fly a paraglider, so I occasionally fly with some hanggliders. I think that the hanggliders that I have flown with had where more beginner-friendly ones. That means that they have a way smaller wingspan, which probably means that they're easier to roll (that seems intuitive to me, but I don't know if that intuition transfers to reality :) ). Also, beginner hanggliders are lighter than other ones (since pro hanggliders have a solid leading edge, as opposed to just tubes and fabric), meaning that the pilot-to-glider ratio is higher, so when the pilot moves, it has more impact on the center of gravity of the whole system.

    Anyway, I will try to tweak the masses a little bit, to adjust the pilot-to-glider ratio, and see if that changes something. Regarding the horizontal position of the center of gravity, I will keep adjusting it until it feels stable.

    I am happy to read your post larrylynx , and to see that I am not the only one having a hard time understanding TMD files^^ (even though I have some solid geometry and math background). Maybe there should be a course "MA-101 - writing TMD files" at university :D.

    I will keep you updated about the progress that I managed to make, but don't be disappointed if it isn't soon, because I am very busy at university right now ;).

    Antoine

  • Hello guys !

    I am making some good progress with the hangglider, it is now flyable ! I have tried to reduce the wing span a little bit (not in the graphical part yet), and it is way more controllable !

    I have a few more questions that I couldn't find an answer myself:

    • I have added some wheels to the glider so that it can actually land. I have added them at both sides of the speedbar, like it is usually done, and it works great. For the other critical spots of the glider (like the tail of the keel and the wing tips), I have tried to add collision_spheres. Unfortunately, it doesn't seem to work, since they were able to traverse the ground. I would ideally like them to act like in real life, where they would scrape the ground and slow the glider down. Since it didn't work that way, I have for now replaced the collision_spheres by wheels (which works, but the glider doesn't slow down when touching the ground).
    • I would now like to allow the speedbar to be grabbed with the mouse or with the VR hands. The speedbar should be translated in two axes (left-right or front-back) to actuate the glider. I have read the documentation about the different virtual controls, but I am not sure that any of them would fit. control_cylinder seems to be the closest fit, but I don't think that it can be used for translational controls, am I right ? If anyone knows about a potential solution, it is very welcomed !

    Other than that, I hope that you are doing great ! I personally have some days off, so I can be a bit more productive working on the virtual glider :) . Unfortunately, though, the weather and the Covid do not allow me to fly my real paraglider, so I guess I'll have to wait ^^...

    Cheers !

    Antoine

  • Hi

    What you need for a mouse action point is contained in the controls.tmd file. I would suggest looking at the jungmeister as it is simple and sort of works with what you have. Each aircraft should have a aircraft tmd and a controls tmd. The latter is not always needed unless you want to interact with it by mouse.

    Copy the controls.tmd from the jungmeister and place in your aircraft folder, open it up. The only section you will need for the moment is 187 to 226 as this deals with the stick or bar in your case, the rest can be removed but do observe the file correct structure. Unless you have other mouse input areas this should be all you will need for your controls.tms file.

    Again from the jungmeister, the lines that you need from the jungmeister.tmd are 899 to 946 and 1874 to 1899. I normally like to make a temporary file, copy in the controls section, dynamics section and graphics section entries. This way it's normally a small file to look at and follow the flow, saves bouncing back and forwards in the tmd files ( which can get very big on more complex stuff). Once your happy with the flow, copy the entries into the relevant tmd and cross your fingers. If the dreaded red cube appears it's much easier to look at your small file to try and track down the error.

    Forgot to add, do remember to change the pivot points to reflect your model and also the geometry list.

    Steve

    Edited once, last by larrylynx (January 26, 2021 at 2:46 PM).