Real Life GTA? Driving A Car In Third Person Is Hard!

Can you drive a car in third person?

Do you fancy yourself an excellent driver in video games featuring a third person view for the driving experience? Ever wonder what it’d be like in real life? [Tom] and [Oli] wanted to find out so they decided to setup this awesome experiment.

They’re using the Bovingdon airfield, which was a Royal Air Force station during WWII — today it stands empty and is a beloved testing ground for many custom vehicles in the UK, like [Colin Furze’s] world record-setting baby carriage. The car chosen for the challenge is a Mazda MX-5 Miata, which we don’t think they care too much about considering the potential obstacles they’ll be hitting!

The driver wears a set of video goggles, and a co-pilot comes along for the ride to help prevent any major collisions. A hexrotor drone is flown by another person who attempts to keep it mostly behind the car in the stereotypical third person view. The video signal is then transmitted down to the driver in real time.

It looks like a blast and definitely isn’t as easy as you might think — despite ultra low latency, both of the drivers felt that they experience lag during the experience.

For a slightly safer experiment, you could always build a third person camera backpack!

23 thoughts on “Real Life GTA? Driving A Car In Third Person Is Hard!

  1. Vision impaired driving is really hard! /s

    Cool experiment using limited experiments. For the record, i hit many objects in GTA 5 while driving. That is with HD and no input lag.

      1. I was refering to the “actual view” at 1.24. That is not HD quality. Also reading on how many gamers are upset when any of the latest two gameconsoles drop below 60FPS, 20 FPS would cause outrage.

  2. Probably wouldn’t be so bad with a higher quality video feed with a somewhat more fixed distance camera instead of a loosely following drone. Definitely preferred the rosterteeth method with a setup on a boom, minus the googles. Having something like Oculus VR with the boom would be great!

  3. The problem I have with this is that video game cameras are fixed behind the car, not wandering all over the place. If there was a pole sticking off the back of the car with a camera on it and the feed was going straight to the goggles, I think this would be much easier.

  4. This is kind of the opposite of R/C car driving, which has latency on controls but not typically on visuals… you’re usually watching your R/C vehicle directly. But you have to deal with a 3rd party view from any angle, and yet serious RCers can drive 35-70mph (real, not scale) with great success.

    The regular analog controllers for R/C give you a 20ms typical latency. When I was designing the first digital R/C controllers at Nomadio, we has this down to 5ms. The second versi p not the controller, the Nomadio React, was also the best controller for computer driving games at the time, with similar low latency through USB drivers.

    When you claim “ultra low latency”, that’s not enough… real numbers are necessary to have any real meaning. For this kind of experiment, you’d have to go to some Intra – Frame only digital encoding to have any chance of having low enough latency to drive a car. Things are much more relaxed, usually, when you’re driving a UAV… you have lots of room, not a 12 ft vehicle lane.. or a 3-4 ft R/C track.

    1. there is no encoding in almost all* FPV setups, they all send analog pal/ntsc video.

      *there is one digitial full hd FPV setup that I know of, but it ..lags :) and is only usable on quadcopters due to tehir tolerance for delay.

  5. Would fitting a spring return to center the steering not solve at least some of the weird lack of feedback described? I would say that the self centering wheel is what makes driving driving using a steering wheel possible in computer games.

Leave a Reply to nobodyCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.