How the failed Iranian hostage rescue in 1980 can save the Autonomous Vehicle industry
From the wiki — https://en.wikipedia.org/wiki/Iran_hostage_crisis
(I copied and pasted this text because it is correct. No reason to reinvent the wheel.)
Late in the afternoon of April 24, 1980, eight RH‑53D helicopters flew from the aircraft carrier USS Nimitz to a remote road serving as an airstrip in the Great Salt Desert of Eastern Iran, near Tabas. They encountered severe dust storms that disabled two of the helicopters, which were traveling in complete radio silence. Early the next morning, the remaining six helicopters met up with several waiting Lockheed C-130 Hercules transport aircraft at a landing site and refueling area designated “Desert One”.
At this point, a third helicopter was found to be unserviceable, bringing the total below the six deemed vital for the mission. The commander of the operation, Col. Charles Alvin Beckwith, recommended that the mission be aborted, and his recommendation was approved by President Carter. As the helicopters repositioned themselves for refueling, one ran into a C‑130 tanker aircraft and crashed, killing eight U.S. servicemen and injuring several more.[119]
In May 1980, the Joint Chiefs of Staff commissioned a Special Operations review group of six senior military officers, led by Adm. James L. Holloway III, to thoroughly examine all aspects of the rescue attempt. The group identified 23 issues that were significant in the failure of the mission, 11 of which it deemed major. The overriding issue was operational security — that is, keeping the mission secret so that the arrival of the rescue team at the embassy would be a complete surprise. This severed the usual relationship between pilots and weather forecasters; the pilots were not informed about the local dust storms. Another security requirement was that the helicopter pilots come from the same unit. The unit picked for the mission was a U.S. Navy mine-laying unit flying CH-53D Sea Stallions; these helicopters were considered the best suited for the mission because of their long range, large capacity, and compatibility with shipboard operations.
Unfortunately, the authors left out several of the root causes and remedies. Those included the CH-53D was the best available aircraft at the time. But it was not good enough. And there was not a group of pilots trained for missions like this. These issues led to the creation of the MH-53J version helicopter and the creation of a new group of pilots and a training organization. From this the 58th Tactical Training Wing, at Kirtland Air Force Base in Albuquerque, New Mexico, was modified to become a Special Operations Wing. (I worked there from 1992 to 2001)
To train the pilots, especially for extremely risky and precise coordinated missions, simulation was required. This begat the simulation technology that is needed in the air and ground autonomous vehicle world today. (Technology used by aerospace as well as the FAA. It is represented by fidelity levels 6 and above in the FAA Part 60.) The reason this technology is required is the gaming-architecture based systems being used today, despite looking fantastic and doing some of what is needed, have architecture and modeling approach limitations that severely limit its model physics fidelity and proper real-time operations, especially in complex scenarios and when the math models are complicated. (Multiple exact radars in a parking garage for examples. Where they must interact with each other’s third order reflections and even material reflectivity properties.) This technology was eventually licensed to the gaming world. They however could not adopt the deterministic simulation scheduling host architecture or federated modeling because they had to work to existing operating systems that they could not control or replace. As time went on and computer technology improved, they simply adapted to that and did adapt to what Air Force Special Operations was doing. Even with better CPUs, memory, GPUs, busses etc they still wind up dumbing down the physics. This is easy to see when you walk through trees or must switch play areas because the multiple core system still chokes. In operation the simulation host architecture basically micromanages and schedules every task. Federated modelling is breaking models into very small parts or tasks so they can be run at required update rates and in the best order. The sim host schedules them in frames. Some might be at 5hz and some at 3000hz. Order is often determined by the needs of critical threads. This management makes things very efficient. (Performance curves would also need to be created and used to create actual high-fidelity models, especially for sensors. This includes various objects with varying material reflectivity, cross sections etc. All performing in a variety of environmental conditions. This is crucial to modeling the failures zones. Where does that little boy in the wool coat disappear to the sensor? No one I am aware of does this. If this is not done right the system will learn the wrong plan for a given scenario becasue the perception system will have the wrong result for a given object, distance, environmental condition etc. This is the most important engineering area. Not the benign scenarios folks highlight and hype.)
If the ground and air autonomous development world utilized this technology, and it was informed and validated by the real-world, they could create simulation good enough to replace the vast majority of the real-world. This would resolve the time, cost and safety issues driving this industry to bankruptcy, never getting close to SAE L4 and harming human test subjects needlessly.
In the air domain the gaming systems include XPlane, AirSim, Flight Simulator,. Air Sim etc. (On the ground side this is Cognata, rFpro, Carla, MORAI, Adams, RPG Carmaker, Waymo, Nvidia etc.) Coincidentally I also worked for a small simulator company who tried to use XPlane to create FAA Level 6 simulators. The efforts failed so badly the company went bankrupt. These products look great and perform well as long as you don’t require the highest levels of fidelity and real-time. The key issues this company has were never being able to get the flight and engine models to act close enough to the real aircraft and overall real-time performance. The flight and engine model issues stem from there not being enough fidelity in the tunable parameters to modify one characteristic without breaking another.
Note — There are two parts to the simulation and simulator systems. The simulation systems that aid in flight, engine and controls design and basic environmental testing, like what J2 Aircraft Dynamics produces, and the systems that facilitate operations in real-world locations with exact sensors, real-world objects in proper real-time etc. (J2 would also create the flight and engine models the other simulation/simulator system would use. Note-J2 uses X-Plane for basic environments and visuals.)
Please find more information below
The Autonomous Vehicle Industry can be Saved by doing the Opposite of what is being done now to create this technology
Simulation Photorealism is almost Irrelevant for Autonomous Vehicle Development and Testing
Using the Real World is better than Proper Simulation for Autonomous Vehicle Development — NONSENSE
SAE Autonomous Vehicle Engineering Magazine — Simulation’s Next Generation (featuring Dactle)
· https://www.sae.org/news/2020/08/new-gen-av-simulation
My name is Michael DeKort — I am a former system engineer, engineering, and program manager for Lockheed Martin. I worked in Aerospace/DoD/FAA aircraft simulation, as a Sr PM and then the Software Engineering Manager for all of NORAD, as a PM on the Aegis Weapon System, as Lead C4ISR systems engineer for the DHS Deepwater program and the lead C4ISR engineer for the Counter-terrorism team at the US State Department. I am now a Program Manager for Space Force Space Systems Command and CEO/CTO at Dactle.
I was presented the IEEE Barus Ethics Award in congress for Post 9/11 DoD/DHS Whistleblowing Efforts
Industry Participation — Air and Ground Autonomy and eVTOL
- Founder SAE On-Road Autonomous Driving Simulation Task Force
- Member SAE ORAD Verification and Validation Task Force
- Member UNECE WP.29 SG2 Virtual Testing
- Stakeholder USDOT VOICES (Virtual Open Innovation Collaborative Environment for Safety)
- Member SAE G-35 Modeling, Simulation, Training for Emerging AV Tech
- Member SAE G-34 / EUROCAE WG-114 Artificial Intelligence in Aviation
- Member CIVATAglobal — Civic Air Transport Association
- Member Teleoperation Consortium
- Stakeholder for UL4600 — Creating AV Safety Guidelines
- Member of the IEEE Artificial Intelligence & Autonomous Systems Policy Committee
SAE Autonomous Vehicle Engineering magazine editor calling me “prescient” regarding my position on Tesla and the overall driverless vehicle industry’s untenable development and testing approach — (Page 2) https://assets.techbriefs.com/EML/2021/digital_editions/ave/AVE-202109.pdf
