The Godzilla of Field Deployed Robotics
This week is Pittsburgh’s Japanese Film Festival, and the lineup is stacked with kaiju movie classics. A subgenre of science fiction and fantasy films that originated in Japan in the 1950s, kaiju movies feature monsters who wreak havoc on cities and civilizations. Walking out of Monday night’s screening of 1954’s Godzilla, I had an epiphany on the impact these movies have had on my robotics career.
Our title character is a force of nature humanity must grapple with in a difficult way. Rampaging through Tokyo, Godzilla disrupts the lives of thousands and fundamentally changes the landscape of those around him. His energized attacks on the city defeat an escalation of technological defenses the humans throw at him, until there’s an escalation of technology capable of facing the threat. While Godzilla is pushing back against electric fences and traditional armies, humanity weighs what to do with the mythical monster. Some want to study the creature, while others want to end the threat as quickly as possible without any regard for the methods.
This balance is a familiar one when working in field robotics. With vehicles out on the public road, there’s a tradeoff in data collection when issues arise in the field. When I’m in a robot and there’s an issue like a task fault or hardware glitch, my mind races as I trace through the immediate situation leading up to the event.
“We’ve disengaged from autonomy, and I can’t see the in-vehicle HMI, but what could have caused that? The person in the left seat did sneeze, could that have been an accidental disengagement? Maybe it was a camera issue, we just passed a particularly bright reflection from a skyscraper, I wonder if the light from the building hit the sensor in such a way as to overload it? I didn’t feel anything, I wonder if we had an iguana fall on our car? Are we still able to re-engage, and can I reroute the vehicle and see if we can replicate the issue at that particular spot again, it’ll help me narrow down if this is hardware issue or something else like a system latency problem.” This is a lightning flash that goes through my head, and being in the vehicle rapidly condenses the time required to build up the case facts and root cause most issues. Any time I travel for work, I’m engaging with those who operate the robots to understand how they perceive their environment as changing the vehicle.
I desire to understand it all, and through a knowledge of all environmental issues I can better understand the Godzilla-sized monster that is maintaining a fleet of vehicles across multiple sites. With this desire for observation, there’s a balance that always comes in fighting the monster and escalating the weapons thrown against it.
Deployed robots exist in union with the environment in which they’re deployed. As much as I’d love to freeze time and analyze every failure, perceived or real, there’s the constant knowledge that we exist in places where others are just trying to go about their lives. I’ve spent many hours in a parking lot debugging, hoping against hope something will change, and defeatedly limped the vehicle back to the garage when the parking meter expired. In Godzilla, humanity escalates to the use of the “Oxygen Destroyer” to bring an end to the monster, our hero Dr. Serizawa using the device to bring an end to the carnage. This is a perceived end to the threat, and people can continue to go about their lives as they would before the monster was unleashed. A version of an “Oxygen Destroyer” would be to do something like ask our team to reboot the vehicle any time there’s an issue and move on with life, or to only act on issues that rise above a certain threshold of escalation.
The defeat of Godzilla was temporary, and the cost to humanity was great. Similarly, relying on field debug of systems is great in the moment, but a pyrrhic victory against the monstrous amount of issues that occur when booting up hundred of vehicles operating in a broad area of deployment. Everyone wants to be the heroic doctor saving the day, but the better method is in a nuanced approach of understanding what leads to a Godzilla-sized problem, and to put proper tooling in place to be as prepared as possible. Documenting issues as they arise, building tooling to help understand trends in failures, working across teams to triage issues as hardware, software, or training all make a huge difference in fighting the beast that is fleet maintenance. Not properly understanding the difference between issue mitigation and remediation is the “Oxygen Destroyer” that prevents issues from being addressed, and keeps the door open for Godzilla to arise again.
