Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

Question How to make a cargo hovercraft work

Discussion in 'Physics' started by A_Box, Aug 29, 2023.

  1. A_Box

    A_Box

    Joined:
    Feb 3, 2020
    Posts:
    65
    I am making a game where you fly a cargo hovercraft.

    For now the hovercraft is just a rectangle rigidbody with 4 engines placed symmetrically, once for each corner.
    Making the hovercraft hover on its own is simple: each engine applies an upwards force of vehicle_mass * 9.81f / number_of_engines.

    But if i add some cargo (rigibodies on top of the hovercraft), how can i calculate the new forces needed for each engine to keep the vehicle in place, avoiding not only its descent, but also the rotation that happens when the cargo weight is not evenly distributed on its top surface?
    And what if the engines are not symmetrically distributed?

    Seems very complicated, especially considering that you cant implicitly get the mass of the added cargo, and there is no method to get the resulting force applied on a rigidbody (there is a method that gets it but only considers AddForces methods and not forces resulting from collisions).

    I guess the proper way to go would probably make the hovercraft kinematic, and simulate interactions with the enviroment trough scripting, but if you have any tips or ideas please tell me-

    Thanks for reading.
     
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,761
    You can get the mass by reading the mass property. Getting how each individual thing affects something else though isn't easy and you need to look at all the contacts in that contact island (things all touching the hovercraft directly/indirectly) but honestly, unless you're trying to actually simulate such a thing, I'd say animating the thing would be much better. Obviously this all depends on how much smoke/mirrors you need for the game itself.
     
    A_Box likes this.
  3. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,565
    That calculation assumes exactly what you've described: 4 engines placed symmetrically around the center of mass. This is very limited to that case only.

    A better approach would be each engine applying a force proportional to its distance to the ground. Essentially, that's the simulation for a spring: Force = (maxDistance - currentDistance) * stiffness, where you configure the stiffness according to the properties of the value and the expected load. When load is added, more force will be applied to support the additional weight.

    However, this approach doesn't maintain a constant distance with the ground, and each additional load will "compress the spring" further. If the requirement for each engine is keeping a constant distance with the ground no matter the load, then you should use a PID approach. The example above would be the "P" in "PID". If you calculate the error and apply the "I" term, then the engine should be able to calculate the force to preserve a given distance to the ground. Maybe the "D" term wouldn't be necessary, unless you require the engine to rapidly anticipate changes in load/ground distance.

    With the above sorted out, the hovercraft would be able to sustain any load in any distribution with any engine positions, as long as the surface is flat. Each engine individually aims to keep a constant distance from the ground, so an uneven ground would produce banking and inclinations in the horvercraft.

    A possible way to cover this is aspect a separate system calculating the distance each engine should keep from the ground. For example, you could pretend the platform is horizontal, then calculate the distance to the ground from that hypothetically horizontal platform at the positions of the engines. This would result in the ground distance each engine should preserve to keep the platform horizontal in that position over the ground. Configure each engine to preserve such ground distance, and that would preserve the horizontality of the platform also in uneven terrain.
     
    Last edited: Aug 31, 2023
    A_Box likes this.
  4. A_Box

    A_Box

    Joined:
    Feb 3, 2020
    Posts:
    65
    Hello @Edy ,
    I've just looked into the PID approach, i made some tests and it think it's exactly what i need!

    Although if you dont mind, i have some questions i would like to ask you, since you seem knowledgeable in this field.

    First I want to specify that even though i said my vehicle is a hovercraft, instead what i meant is that you should be able to manouver it indipendedtly from the ground distance/surface mesh, so i guess it should act like a "sci-fi space ship on a planet without air".
    Also, i'm using a PI controller (so no derivative, for now), the process variable that i measure is the vehicle vertical speed, and the desired the setpoint is 0, so that the vehicle can hover. The result of the PI controller is used to add a force to the vehicle, so the velocity isn't changed directly.

    I've seen that i can get optimal values for the constants (Kp, Ki) used in the PID controller by loop tuning, but i'm not sure how to go about it:
    How often should i loop tune? Should i loop tune if the gravity or ship cargo changes?

    Also, how long should the time frame used for the integral be? What are the pro and cons of having it long/short?

    Thanks the suggestion and for your time.
     
  5. TFRhythm

    TFRhythm

    Joined:
    Nov 25, 2017
    Posts:
    2
    If it doesn't need to maintain a fixed distance from the ground then I really think PID is over-complicating it.

    Do this but instead of making it proportional to the distance to the ground, have each engine apply:
    • The basic 9.81f force,
    • a force proportional to its own vertical distance from the average height of all the engines (which could be negative, or you could choose to zero out negative values if you prefer), and
    • a force proportional to the vertical distance between the average height and the target height.
    Something simple like this should work fine, while preserving the natural interactions of the ship with the environment. It also gives you a lot of flexibility later in fine-tuning exactly how the ship feels.
     
    Last edited: Sep 6, 2023
    Edy likes this.
  6. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    2,565
    Honestly, I've very little experience in tuning PIDs, other than trial & error. I've learned about PIDs in this page, and made my implementation based on it:
    http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/

    Possibly the part that is most interesting to you is the chapter about on-the-fly tuning changes:
    http://brettbeauregard.com/blog/2011/04/improving-the-beginner’s-pid-tuning-changes/
     
    A_Box likes this.
  7. Maeslezo

    Maeslezo

    Joined:
    Jun 16, 2015
    Posts:
    357
    Edy and A_Box like this.
  8. A_Box

    A_Box

    Joined:
    Feb 3, 2020
    Posts:
    65
    But even if i use proportional forces that increase/decrease based on the engine position, how do i know how much force to apply, considering i don't know the exact mass of the vehicle (because of cargo)?
    That's why i think i need a PID, because it's a systems that "tries" values and corrects them based on the error they generate, and this type of controller only requires a target value (speed 0) and a measured value (current speed).

    Thanks for the suggestion, i've read all chapters of the page, and based my PID on it. Very useful!
    Unfortunately, the part about on-the-fly tuning changes only provides a fix that resolves some problems deriving from tuning the terms while the system is running, but doesn't provide info about how to do the tuning itself.

    Also very interesting, i was implementing the algorithm right now, but some doubts came along...
    Considering that I'm working in unity, with forces, in a possibly dynamic enviroment:
    • Twiddle iterates on one of the 3 terms at the time. If the single change produces a smaller error (so it's a good change), then it's kept, otherwise its discarded; an then it goes on to the next term, untill all 3 are done. I can't calculate beforehand if the change of the single term will produce a better result, and so i must wait for the next fixedupdate after the forces with the new term have been applied to see if the change has yeld positive results or not. This means that even if the PID uses 3 different terms, i can only Twiddle one of them per frame; if i change more terms per frame, even if i get a net positive/negative outcome, i won't know which term is now better and which not.
    • External forces and interactions (bumping into something, adding cargo, ecc...) might make the twiddle algorithm think that a change of terms has produced a better/worse result, which would result in an incorrect updating of terms (altough maybe that's what would happen realistically...)

    This hovering thing seems more complicated that i anticipated, but i'll keep working on it and i'll update the thread if i make any breakthroughs. Thanks for now!
     
  9. faUnity

    faUnity

    Joined:
    Aug 7, 2023
    Posts:
    15
    a good tuto here


    you can go directly to the 7 chapter for the hover physics and scritps
     
  10. A_Box

    A_Box

    Joined:
    Feb 3, 2020
    Posts:
    65
    An update on the hovercraft:
    I ended up using a PI controller since the derivative was causing weird behaviours. One very useful addition to the code was the removal of the Integral windup trough the Clegg Integrator method. This got rid of any oscillation when reaching the desired speed, which made manually tuning the PI controller much easier.
    Now the hovercraft can succesfully reach any desired speed, including zero (hovering midair!).

    The next challenge will be distributing the PI calculated force between the thrusters so that the hovercraft always stands straight and corrects any tilting (that happens due to cargo).