# Human vs. AI Pilots: Palmer Luckey Weighs In #shorts *Du Cavendish* · https://www.youtube.com/watch?v=7D2fu54HNF8 ## Summary Palmer Luckey discusses how human pilots and autonomous systems differ, arguing that human pilots work within industry constraints that discourage aggressive evasive action, while robots act maximally safe. He describes how simulation demonstrations, like collision avoidance in GPS jamming scenarios, convinced skeptics of autonomous safety systems. He also stresses that exercises must be realistic, overloaded, and full of unexpected worst-case scenarios, and that early testing is essential because late fixes can be non-viable. ## Key points - Human pilots work within industry constraints and avoid aggressive evasive maneuvers to keep passengers comfortable and keep their jobs, while a robot would take maximum evasive action at the first sign of trouble. - Simulations showing collision avoidance, such as the recent GPS jamming scenario that took out medevac pilots, convinced people that autonomous safety systems can save every person in the sim. - Many exercises are too scripted and easy, and should instead include unexpected scenarios like enemy fire, offline support systems, degraded stability augmentation, or aircraft overdue for maintenance. - Luckey's systems often fail in worst-case scenarios because his team are 'computer kids', and systems that work in a science fair project can fall apart in real conditions. - Testing early in the design phase is essential, because fixes discovered too late may be totally non-viable, such as replacing an unworkable tablet UI after 5 years of development. - Luckey dislikes touchscreens and values tactile feedback, joking that Steve Jobs 'ruined technology' despite respecting him. ## Notes ### Human pilots vs. autonomous systems - Human pilots work within industry constraints, like a chauffeur: everything must be smooth, and trouble shouldn't show until it has to. - A charter helicopter pilot won't take aggressive evasive action at the first sign of trouble because it leads to bad reviews and job loss; a robot will. - Fighter pilots love to fly, but more than that, they want to win. ### Seeing is believing - Demonstrating autonomous capability in simulations convinced people, especially collision avoidance. - Example: recent GPS jamming took out medevac pilots; many pilots put in that situation would have controlled flight into terrain, but integrated safety systems meant every person in the sim lived. ### Realistic, overloaded exercises - Exercises should be realistic, representative of actual workflow and workload, and ideally overloaded. - Scripted exercises hide reality: unexpected enemy fire, support systems offline, loss of stability augmentation in a rotorcraft, or no maintenance for 3 weeks in wartime. - Luckey's daily flyer is a Eurocopter EC120; he can fly it hydraulics out, but wouldn't want to in a high-workload situation, at night in the weather, or overseas without his emergency suit. ### Early testing - Systems that work great in the lab or sim often fail at real-world edge cases. - Luckey admits a lot of his company's stuff totally fails in worst-case scenarios because his guys are 'computer kids'. - Test early in the design phase; if you wait too long, fixes may be non-viable — e.g., discovering a control tablet is unworkable after 5 years of development. ### Touchscreens and tactile feedback - Touchscreens are challenging in high-workload environments. - Luckey hates touchscreens, loves tactile feedback, misses his Blackberry, and jokes that Steve Jobs 'ruined technology' despite respecting him. ## Transcript [00:00] Who cares? >> That's true. The human's not in the thing makes it unsafe. >> So, a lot of pilots, they're not trying to do the maximally safe thing. They I'm not saying pilots are unsafe. Remember that pilots are working within industry constraints. Like, a guy who flies a bizjet or a charter helicopter operation, he is flying within the same constraints as a chauffeur, right? He You got to approach everything smooth. You If something's going wrong, you don't want it to show until it has to, right? You You are not going to want to take aggressive really aggressive evasive maneuvers at the first sign of trouble. If I'm a robot, that's what it's going to do. It's going to see the first sign of possible trouble and do [00:36] the most evasive action. Your charter helicopter pilot is not going to do that because you're going to get really bad reviews and you're going to lose your job really fast. I think just the way that you look at these things are very different between human pilots and unmanned pilots. My experience has been that a lot of like let's take like fighter pilots, for example. Yes, they love to fly, but more they want to win. >> Well, I think I think with our autonomous systems, it really was like seeing is believing, right? Like, we demonstrated the capability and now everyone's on board. The collision avoidance. >> Well, you run the missions and you run the mission simulations. And also with human pilots, you run them in [01:07] simulators. You're like, "Okay, let's see you not hit the terrain in this situation, right? Your GPS is out. Look at this recent GPS jamming scenario where where it took out the medevac pilots." Like, so put a lot of pilots into that same situation and they're going to they're going to have a they're going to controlled flight into terrain for sure. And maybe a few of them will avoid it. And then you integrate that with some of these safety systems and all of a sudden every person in the sim lives. And I think that does convince people. We need to show people more of that stuff. >> So, I got a follow-on now. I've seen things that work great in the sim, they work great in a laboratory environment. [01:38] And this is not just autonomy, this can be sensors. I've done a lot of helmet queuing type of things. Work great in the sim, you get in the real flight environment, you get to some of those edge cases, it's a lot more challenging. >> You need to have exercises that are that are realistic and representative of your actual workflow and workload and then ideally overloaded. One of the big flaws of a lot of exercises, and including ones that we're part of is that they have this nice scripted thing and here's how it's all going to go and it's all very easy. Like you have a bunch of beyond visual line of sight engagements. Oh, we've picked it up. We passed the queue and my I've got I've got to fire my weapon. [02:11] It's going to pick up the track. Great, it all works. Well, what happens when actually there was a bunch of stuff that you didn't expect and now it is shooting at you. Also, a bunch of your support systems are offline. Maybe you've actually lost some of your stability augmentation system in your rotorcraft. Maybe because it was shot or maybe just because the combat cadence maybe we're in the middle of the third week of the war and you haven't been back to actually get properly maintained in 3 weeks and so it's just total and not working anymore. Like now what is it like to do it? Or one of my favorite ones like I most my daily flyer is a Eurocopter EC120. I love I love it. I know it's a little underpowered and [02:45] I'd rather be flying an MD500 but there's things that I like about it. >> [laughter] >> Like I can fly a hydraulics out. >> Mhm. >> I really would not want to be flying a hydraulics out in a high workload situation with a lot of other stuff. >> in the weather flying at night. >> night in the weather or and it worse maybe at night in the weather and I didn't even expect to be at night in the weather. Right? So or worse, I end up overseas and I'm not wearing my emergency suit and I'm thinking, "Okay, what risk do I want to take? How far like I want to be able to auto rotate to the coast if I lose my main power. Maybe my chip light is on. I know that I've only got so much time left on my engine." Unexpected scenarios should be [03:19] part of these exercises. We should be We should be putting people into the worst case scenarios and then seeing how this stuff works out. And I'll be honest, a lot of our stuff totally fails to work when you get in those scenarios because my guys are computer kids, right? And like we work we have a lot of veterans here and we try to work custom with the customers to understand these problems but it's very easy to develop a system that works great in the science fair project scenario and then you put it into something real and it all falls apart. And so I >> This is why I'm all about early test. I early test as soon as we can when we're in the design phase so that we can find the problems and fix the problems. [03:49] >> That's right. If you wait too long, sometimes the fixes are just totally non-viable. Like to use an extreme example, what if you were considering voice controls and it reads out over the radio and everyone gets to hear it versus a dedicated tablet for controlling something. What if you find out that the tablet's just completely unworkable in high workload environments? The only fix at that point is try to make the UI on the tablet better. It's very hard to say, "Well, that's was 5 years of development down the drain. We're just going to rip this out and start from >> Well, touchscreen is one of those examples touchscreen can be challenging and >> I hate touchscreens. They're so bad. They're so bad. Don't even get me [04:22] started. Steve Jobs, I I like the guy, but man, he ruined technology. >> I miss my Blackberry. >> Absolutely. >> I love tactile feedback. I really do. I have a whole >> That's a huge thing. >> It's so critical. >> It's the tactile feedback. That's like a very specific example of what I'm talking about. I've got this whole anti-Steve Jobs and I remember I respect Steve Jobs to death.