===== Autonomy levels ===== Why one should worry about a particular autonomy level scale? There are several good reasons for this: * Depending on autonomy level system owner might expect particular performance and functionality, as we do with technology readiness levels (TRLs) or other classification scales; * Different regulations might be applied to systems of different autonomy levels; * Sometimes it is necessary to forecast the potential performance of the autonomous system for mission planning or design purposes. Besides a plain autonomy level definition, several models have been proposed for assessing UMS (Unmanned Systems) level of autonomy and autonomous performance, and these models are briefly discussed in this section. Among the earliest attempt to quantify autonomy is ((http://www.academia.edu/download/41420818/A_framework_for_autonomy_levels_for_unma20160122-29920-mjbf2h.pdf)) work on autonomy model ALFUS. The ALFUS is not a specific test or metric, but rather a model of how several different test metrics could be combined to generate an autonomy level. As it is depicted below ALFUS model uses three dimensions – Environmental complexity, Mission Complexity, and Human independence describe – are used to assess the autonomy of a given UMS ((http://www.academia.edu/download/41420818/A_framework_for_autonomy_levels_for_unma20160122-29920-mjbf2h.pdf)).
{{ :en:av:autonomy_and_autonomous_systems:autonomy:alfus.png?400 |}} Alfus framework
The ALFUS framework provides the capability of estimating the level of autonomy of one robot or a team of robots. However, this methodology still has some drawbacks that prevent its direct implementation. The ALFUS methodology does not provide the tools to ((https://ieeexplore.ieee.org/abstract/document/6942823/?casa_token=AOUV31jSjoMAAAAA:qxSTlUXcPOOb71b6gurGnJJBTUA4iC3ICA9OXSKcFXe-Oj0ti5uD9-d0QIMwE3aFG8rsEB0iC9livQ)): * Decompose the tasks in a commonly agreed-upon, standard way; * Test all possible missions, tasks, and sub-tasks; * Assess the interdependency between the metrics, as some of the subtasks can apply to more than one metric; * Allow metrics to be standardized in scoring scales; this will cause subjective evaluation and criteria to influence the results across different robots, users, or competing companies; * Integrate the metrics into the final the autonomy level. Partially ALFUS drawbacks are tackled by another – non-contextual assessment formally called the Non-Contextual Autonomy Potential (NCAP) ((http://gvsets.ndia-mich.org/documents/RS/2011/A%20Non-Contextual%20Model%20for%20Evaluating%20the%20Autonomy%20Level%20of%20Intelligent%20Unmanned%20Ground%20Vehicles.pdf)). The NCAP provides a predictive measure of a UMS’s ability to perform autonomously rather than a retrospective assessment of UMS autonomous performance relaying on tests performed before the actual application of the system being assessed. The NCAP treats autonomy level and autonomous performance separately. A UMS that fails completely at its mission but does so autonomously still operates at the same autonomy level as another UMS that succeeds at the same mission. Model visualization is provided below:
{{ :en:av:autonomy_and_autonomous_systems:autonomy:ncap.png?400 |}} NCAP framework
As it is said in ((https://ieeexplore.ieee.org/abstract/document/6942823/?casa_token=AOUV31jSjoMAAAAA:qxSTlUXcPOOb71b6gurGnJJBTUA4iC3ICA9OXSKcFXe-Oj0ti5uD9-d0QIMwE3aFG8rsEB0iC9livQ)) the major drawback to these models is that they do not assess, specifically, the mission-specific fitness of a UMS. It might be a case when the user has several UMS assets available for a given mission or task, and the current models do not provide a simple answer for which asset is “best” Furthermore, none of the current model addresses, quantitatively, the impact on the mission-specific performance of changing a given UMS’s level of autonomy. With this need in mind, a metric for measuring autonomous performance is designed to predict the maximum possible mission performance of a UMS for a given mission and autonomy level and is named the Mission Performance Potential (MPP). The major difference of the MPP model in comparison to the mentioned ones is defined by the following assumptions: * not necessarily performance increases gradually if autonomy level increases. It means that ins some particular tasks the performance actually can drop; * performance of the same UMS can vary from mission to mission. It means that the context of the system operation cannot be ignored during the assessment. International Society of Automotive Engineers (SAE, https://www.sae.org/) have defined and explained autonomy levels of autonomous cars:
{{ :en:av:autonomy_and_autonomous_systems:autonomy:sae.png?400 | :en:av:autonomy_and_autonomous_systems:autonomy:ncap.png?400 |}} SAE autonomy levels
The SAE level definitions are more focused on product features to provide both a better understanding of the actual functionality of the automotive product as well as a foundation for legal regulations for each of the autonomy levels. In the context of Unmanned Areal Vehicles the autonomy levels are addressed by a little different classification while having the same number of autonomy levels: According to the Drone Industry Insights (2019. https://dronelife.com/2019/03/11/droneii-tech-talk-unraveling-5-levels-of-drone-autonomy/), there are 6 levels of drone operations autonomy: ^ Autonomy\\ Level | 0 | 1 | 2 | ^ Human\\ Contribution\\ to the Flight\\ Control | {{:en:drones:ludzik_1.png?50}} | {{:en:drones:ludzik_2.png?50}} | {{:en:drones:ludzik_2.png?50}} | ^ Machine\\ (Drone Systems)\\ Contribution\\ to the Flight\\ Control | {{:en:drones:dron_6.png?100}} | {{:en:drones:dron_5.png?100}} | {{:en:drones:dron_4.png?100}} | ^ Flight \\ Automation\\ Degree | None | Low | Partial | ^ Remarks | Remote Control (fully RC). UAVO controls the drone in 100% manually (i.e. operator directly drives control surfaces). | UAVO in Control but the drone has at least one function it controls independently to the human operator (i.e. flight stabilisation). | UAVO is responsible for operation safety. The drone can take over controls given by the operator and modify it (i.e. heading, altitude hold, position hold, "smart" flight modes). | ^ Environment\\ Interaction (i.e.\\ Collision \\ Avoidance) | None | Sense and Alert UAVO ||
Autonomy levels (part 1)
^ Autonomy\\ Level | 3 | 4 | 5 | ^ Human\\ Contribution\\ to the Flight\\ Control | {{:en:drones:ludzik_4.png?50}} | {{:en:drones:ludzik_5.png?50}} | {{:en:drones:ludzik_6.png?50}} | ^ Machine\\ (Drone Systems)\\ Contribution\\ to the Flight\\ Control | {{:en:drones:dron_3.png?100}} | {{:en:drones:dron_2.png?100}} | {{:en:drones:dron_1.png?100}} | ^ Flight \\ Automation\\ Degree | Conditional | High | Full | ^ Remarks | UAVO acts as fall-back: the drone performs autonomous operation under given conditions (i.e. using preloaded flight plan). The Drone can introduce slight modifications to it. i.e. avoid collisions with detected objects. | UAVO is out of control here, the drone performs autonomous flight and is able to use its duplicated systems to remain safe and operable all time. | The drone performs fully autonomous decisions on the way they implement given tasks, using data and possibly AI to plan the flight and modify it. | ^ Environment\\ Interaction (i.e.\\ Collision \\ Avoidance) Sense and Avoid, usually also Alert UAVO | Sense and Avoid, usually also Alert UAVO | Sense and Navigate ||
Autonomy levels (part 2)