Shortly after completing the prototype I realized that the way that Unity simulates drag isn’t suitable for racing games. Unity’s drag is linear, but real aerodynamic drag is quadratic. This means that in Unity, doubling a car’s velocity only subjects it to twice as much force from drag, but in real life doubling a car’s velocity quadruples the amount of force. This is an incredibly important force for real cars, so it should be for hover cars as well. So, I implemented a better drag model based on the formulas from Physics for Game Programmers. To calculate drag using the new formula, I needed values for the car’s drag coefficient, frontal area, and the density of the air that it’s traveling through. These are the values that I used:

  • Drag coefficient: 0.35
  • Frontal area: 3 m2
  • Air density: 1.225
  • Vehicle mass: 2600 pounds

The drag coefficient isn’t terribly impressive for a modern vehicle, and the frontal area is larger than it probably should be, but I’m going to pretend that this is a low-end hover car. The value that I’m using for air density is the density of the Earth’s atmosphere at sea level.

Like A Brick on Ice

To start, I decided to establish some baseline data. I started the hover car off at 60 mph and waited to see how long it would take for it to coast to a stop with only drag acting against it. And I kept waiting. And then I went off to make a drink.

After 15 minutes the hover car was still going around 5 mph and had traveled just over three miles (15,840 feet).

I can’t find any data on how long it takes any real cars to coast to a stop on level ground, but I’d bet that it’s way less than that. This is what happens when a vehicle doesn’t have tires or friction. To be fair, it did shed about half of its speed in the first minute. The problem is that drag just isn’t going to do a whole lot at low speed. I don’t know how long it would take to lose that last 5 mph. I got really tired of waiting.

So, we need to figure out how to stop this thing. The first option that comes to mind is something that was featured in the prototype: air brakes. However, I did cheat a bit in the prototype, because I wanted to get something playable before I spent weeks or months fiddling with the physics. In the prototype an artificial force is applied against the car proportional to the angle of the air brakes. I’d like to avoid magical forces like this for the real game, so let’s see what properly simulated air brakes can do.

I attached another surface to the test car with a drag coefficient of 1.17 and a frontal area of 1 m2. According to my physics book, this should be correct for a flat plate with a 1 m2 surface area. Running the same test as above, it took only 5.5 minutes for the hover car to slow down to around 5 mph, and it had only traveled 1.2 miles, or about 6336 feet.

This is a big improvement, but nowhere near the level of performance that we need. The National Highway Traffic Safety Administration specifies that a passenger vehicle should be able to come to a complete stop from 60 mph in under 216 feet. Which means we still need to shave off at least another 6120 feet.

At high speed the air brakes will probably be super useful. The hover cars may even be able to use individual air brakes positioned on different parts of the car to help with high speed cornering. But I’m not going to worry about that just yet.

Drag isn’t going to get the job done, and we don’t have friction to help us out, so what else can we use?

Using the Hover System

Before we think about adding additional thrusters or systems to the hover car to slow it down, let’s try using the hover system that we’ve already got. The hover system uses four thrusters, with one positioned at each corner of the vehicle. There are two ways that I can think of to use these thrusters for braking and it’s going to be easiest to show them in motion.

Each test starts the vehicle at 60 mph and applies a different braking technique. The red lines show the direction of thrust from each thruster.

This is the first technique and it’s how most quadcopters work. The force coming from each thruster is varied to tilt the car, which in turn directs the thrust away from the direction of tilt. It’s a great technique because the only thing it requires is that you can individually control the thrust output from each of your fans or thrusters, which quadcopters and our hover cars already can.

I based my implementation of this system on a number of papers that I read about quadcopter control systems. The car has a target altitude, target pitch (forward/back) angle, and a target roll (left/right) angle. The system uses a PID Controller for each of those targets, adjusting the angles and altitude according to the direction the car is traveling. It’ll bring the car to a stop no matter which direction it’s sliding in. It can also be used to tilt the car when cornering, which is something that the prototype lacked.

Using this method the car comes to a complete stop in just 532 feet. While that’s a massive improvement over the air brakes, we’re still a few hundred feet away from that 216 feet requirement. Also, that’s just the bare minimum performance, most passenger vehicles are well below that, with many sports cars stopping in just over 100 feet. So, it’s a real neat system and it may still play a role in controlling the hover car, but this can’t be the only braking system we have.

Let’s try something else.

Welp. 119 feet. That’ll do.

This technique is called thrust vectoring, and rather than tilting the car, it changes the angle of the thrusters. This not only gets us below 216 feet, but it puts us on par with modern road vehicles, and that’s without any real tweaking.

The reason why this is so much more effective is obvious when we look at the angles. In the above tilt test, I set the maximum pitch angle for the car to 12 degrees. That’s not a very extreme angle, but even so, the front end was high enough that a driver wouldn’t be able to see forward. The thrust vectoring test on the other hand, set the thrusters to an angle of 45 degrees. That’s a lot more of the car’s thrust being directed forward.

I did look into using the tilt and thrust vectoring systems together, but this doesn’t actually improve performance unless the maximum thrust vectoring angle is very low. I should also mention that the above tests were conducted without the air brakes. I did try bringing those in, but it only shaved off another four feet. I haven’t conducted high speed braking tests yet, but that’s probably where those will make sense again.

I was curious what kind of performance I’d see if I increased the thrust vectoring angle and the maximum thrust of the hover system. With a little bit of tweaking I was able to get the stopping distance under 70 feet.

I’d like to compare thrust values from the hover system to modern jet engines, just to see how absurd these four little thrusters are, but I haven’t been able to find solid numbers for that yet. I’m just going to assume that these thrusters are unrealistically powerful and efficient, but I’m fine with that.

At this time the thrust vectoring system is quite primitive, using the same angle and direction for all thrusters. Once they can be controlled individually, however, we can also use the thrusters for low speed maneuvering and turning.

These results do raise some questions about the design of the hover car, though.

Rethinking Thrusters

The hover car in the prototype video has one large, rear facing thruster, and four small, downward facing thrusters that are invisible to the player (I hadn’t settled on effects for these yet). But does it really make sense to have an extremely powerful stationary thruster facing backwards? This will get us moving, but it can’t help with stopping or turning. If we need the hover system to be incredibly powerful to stop the car, maybe we should just delete that big, static thruster in the back and use the hover system for acceleration as well.

From this point on, I think the hover cars are going to focus on powerful hover systems with highly maneuverable thrusters.

In the next post we’ll address turning, which is going to be even more complicated.