Question How to make a cargo hovercraft work

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.

 

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.

 

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.

 

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.

 

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/

 

Tuning the PID parameters is quite tricky.

Here's an interactive algorithm you can use from Sebastian Thrun that he calls "Twiddle"

Here's a nice diagram of the same algorithm
https://medium.com/@carola.amu/pid-controller-for-autonomous-vehicle-151d90e49855

 

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!

 

a good tuto here

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

 

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).