WP3-16 - Revision history

Grolleaue at 08:34, 10 March 2023

2023-03-10T08:34:45Z

← Older revision		Revision as of 08:34, 10 March 2023
Line 26:		Line 26:
	\|-		\|-
	\| TRL \|\| 7		\| TRL \|\| 7
			\|-
			\| Contact \|\| timothee.gavin at scalian.com
	\|}		\|}

Scalian: /* Design and Implementation */

2022-05-30T13:07:28Z

Design and Implementation

← Older revision		Revision as of 13:07, 30 May 2022
Line 53:		Line 53:

	The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go surveying the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally, the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.		The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go surveying the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally, the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.

	~~=Design and Implementation=~~

	=Reference=		=Reference=

Scalian: /* Detailed Description */

2022-05-30T09:13:31Z

Detailed Description

← Older revision		Revision as of 09:13, 30 May 2022
Line 32:		Line 32:
	=Detailed Description=		=Detailed Description=

	~~[[File:Wp3-16_01~~.~~png\|frame\|center\|EZ_Chains general~~ architecture]]		EZ_Chains is a generic architecture that allows agents to perform collaborative mission as a fleet. The architecture is built for distributed decision, and each agent relies on its (synchronized) copy of the knowledge base to choose the next steps. This knowledge base contains the current mission status, updated with transactions sent by the agents of the system (the transaction is validated by the ground segment, centralizing the consistency process) and the status of each agent, updated periodically.

	EZ_Chains ~~is a generic architecture that allows agents to perform collaborative mission~~ as ~~a fleet. The architecture is built for distributed decision~~, ~~and each agent relies on its (synchronised) copy~~ of ~~the knowledge base~~ to ~~choose~~ the ~~next steps. This knowledge base contains the current mission status, updated~~ with ~~transaction sent by~~ the ~~agents~~ of the ~~system (~~the ~~transaction is validated by the ground segment, centralising~~ the ~~consistency process)~~ and ~~the status of each agent, updated periodically~~.		EZ_Chains can be seen as three main layers, mission management to handle the highest level of information, flight management to handle the flight while ensuring coordination with the rest of the fleet, and finally the low-level interfaces to the autopilot and payload.

	~~EZ_Chains can be seen as three~~ main ~~layers~~, mission ~~management to handle~~ the ~~highest level~~ of ~~information~~, ~~flight management to handle~~ the ~~flight while ensuring coordination with~~ the ~~rest~~ of the ~~fleet~~, and ~~finally~~ the ~~low-level interfaces~~ to the ~~autopilot and payload~~.		The mission management is composed of two main components, the first is the task planner that computes the next best actions to achieve based on the current mission status and actions planned by the other agents. The second component is the task monitor that ensures the execution of the chosen actions, it triggers the other components. It is also responsible for the sanity of the agent, it uses watchdogs to verify the status of the different components and also detect important changes in the mission parameters that forces to reconsider the current planned actions.

	The ~~mission~~ management is composed of two main components, the ~~first is the task planner~~ that ~~computes~~ the ~~next best actions to achieve based on~~ the ~~current mission status and actions planned by~~ the other ~~agents~~. The ~~second component is~~ the task monitor ~~that ensures~~ the ~~execution~~ of the ~~chosen actions, it triggers~~ the ~~other components~~. It is also ~~responsible~~ of the ~~sanity of~~ the ~~agent~~, ~~it uses watchdogs~~ to ~~verify~~ the ~~status~~ of the ~~different components and also detect important changes in~~ the ~~mission parameters that forces~~ to ~~reconsider~~ the ~~current~~ planned ~~actions~~.		The management of the flight is also composed of two main components, similarly a planner and a monitor. The path planner ensures the computation of trajectories that avoid the geo-fences but also reduce the intersection with the other agent trajectories. The navigation monitor triggers the path planner when requested by the task monitor (to perform a given action), but also handles the air traffic management internal to the fleet. It books airspace as segments of the trajectory as the agent progress over its trajectory. It allows preventing collision by stopping one of the agents that would try to use or crossed an airspace already booked. The navigation monitor also verifies the validity of the trajectory during its execution. Indeed, if the mission status changes in the knowledge base, due to the addition of a new geo-fence for instance, the navigation monitor may request a new trajectory. Finally, the navigation monitor talks to the autopilot for the agent to perform the planned trajectory.

	The management of the flight is also composed of two main components, similarly a planner and a monitor. The path planner ensures the computation of trajectories that avoid the geofences but also reduce the intersection with the other agent trajectories. The navigation monitor triggers the path planner when requested by the task monitor (to perform a given action), but also handles the air traffic management internal to the fleet. It books airspace as segments of the trajectory as the agent progress over its trajectory. It allows to prevent collision by stopping one of the agents that would try to use or crossed an airspace already booked. The navigation monitor also verifies the validity of the trajectory during its execution. Indeed if the mission status changes in the knowledge base, due to the addition of a new geofence for instance, the navigation monitor may request a new trajectory. Finally the navigation monitor talks to the autopilot for the agent to perform the planned trajectory.		[[File:Wp3-16_01.png\|frame\|center\|EZ_Chains general architecture]]

	=Contribution and Improvements=		=Contribution and Improvements=

Scalian: /* Contribution and Improvements */

2022-05-30T09:12:34Z

Contribution and Improvements

← Older revision		Revision as of 09:12, 30 May 2022
Line 44:		Line 44:
	=Contribution and Improvements=		=Contribution and Improvements=

	EZ_Chains architecture described above has been designed to allow UAVs to perform collaborative missions. The work carried out during C4D is twofold: (i) ~~generalise~~ the architecture to work with new components and demonstrate its genericity, (ii) extend it to support ~~mort~~ type of agents than just UAVs. The description in the previous section uses the notion of agent (instead of only UAV) to demonstrate that the concepts we use in the architecture actually extend to other types of agents, which demonstrates that the architecture is mostly ready for new types of agents at a formal level.		EZ_Chains architecture described above has been designed to allow UAVs to perform collaborative missions. The work carried out during C4D is twofold: (i) generalize the architecture to work with new components and demonstrate its genericity, (ii) extend it to support more type of agents than just UAVs. The description in the previous section uses the notion of agent (instead of only UAV) to demonstrate that the concepts we use in the architecture actually extend to other types of agents, which demonstrates that the architecture is mostly ready for new types of agents at a formal level.

	In order to ease the work aimed at in C4D, we used the first and second year to integrate new missions and tasks for UAVs. Making the system capable of using a fleet of heterogeneous UAV. It allowed us to focus on ~~realising~~ the demonstration for the UC3 D1 (Logistics, dropping sensors). We aim at using the third year to work on integrating new types of agents and components.		In order to ease the work aimed at in C4D, we used the first and second year to integrate new missions and tasks for UAVs. Making the system capable of using a fleet of heterogeneous UAV. It allowed us to focus on realizing the demonstration for the UC3 D1 (Logistics, dropping sensors). We aim at using the third year to work on integrating new types of agents and components.

	Integrating new types of missions, already required to define new types of agents in the knowledge base. We now have a hierarchy of agents, for instance we have UAV>Dropper, UAV>Surveillance and GCS. To support different agents, at different level of hierarchy, required to improve the internal structure, the relation between the mission status and the periodic updates sent by the agents.		Integrating new types of missions, already required to define new types of agents in the knowledge base. We now have a hierarchy of agents, for instance we have UAV>Dropper, UAV>Surveillance and GCS. To support different agents, at different level of hierarchy, required to improve the internal structure, the relation between the mission status and the periodic updates sent by the agents.
Line 52:		Line 52:
	Once the knowledge base can support different types of agents, the task monitor must take it into account when following the mission progress before triggering the task planner. For instance, in the UC3 D1 demonstration, due to regulatory limitations, we had to ask the fleet to trigger a landing when the surveillance UAV declared its trajectory back to base due to low battery. New behaviour must be created when new hierarchies of agents are added. In the future we would like to add, weather stations as part of the system, they would also require the triggering of conservative actions when the weather becomes too bad.		Once the knowledge base can support different types of agents, the task monitor must take it into account when following the mission progress before triggering the task planner. For instance, in the UC3 D1 demonstration, due to regulatory limitations, we had to ask the fleet to trigger a landing when the surveillance UAV declared its trajectory back to base due to low battery. New behaviour must be created when new hierarchies of agents are added. In the future we would like to add, weather stations as part of the system, they would also require the triggering of conservative actions when the weather becomes too bad.

	The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go ~~survey~~ the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.		The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go surveying the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally, the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.

	=Design and Implementation=		=Design and Implementation=

	=Reference=		=Reference=

Scalian: /* Contribution and Improvements */

2022-05-30T09:10:16Z

Contribution and Improvements

← Older revision		Revision as of 09:10, 30 May 2022
Line 53:		Line 53:

	The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go survey the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.		The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go survey the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.

			=Design and Implementation=

			=Reference=

Scalian: /* WP3-16 - EZ_Chains Fleet Architecture */

2022-05-30T09:03:38Z

WP3-16 - EZ_Chains Fleet Architecture

← Older revision		Revision as of 09:03, 30 May 2022
Line 27:		Line 27:
	\| TRL \|\| 7		\| TRL \|\| 7
	\|}		\|}



			=Detailed Description=

			[[File:Wp3-16_01.png\|frame\|center\|EZ_Chains general architecture]]

			EZ_Chains is a generic architecture that allows agents to perform collaborative mission as a fleet. The architecture is built for distributed decision, and each agent relies on its (synchronised) copy of the knowledge base to choose the next steps. This knowledge base contains the current mission status, updated with transaction sent by the agents of the system (the transaction is validated by the ground segment, centralising the consistency process) and the status of each agent, updated periodically.

			EZ_Chains can be seen as three main layers, mission management to handle the highest level of information, flight management to handle the flight while ensuring coordination with the rest of the fleet, and finally the low-level interfaces to the autopilot and payload.

			The mission management is composed of two main components, the first is the task planner that computes the next best actions to achieve based on the current mission status and actions planned by the other agents. The second component is the task monitor that ensures the execution of the chosen actions, it triggers the other components. It is also responsible of the sanity of the agent, it uses watchdogs to verify the status of the different components and also detect important changes in the mission parameters that forces to reconsider the current planned actions.

			The management of the flight is also composed of two main components, similarly a planner and a monitor. The path planner ensures the computation of trajectories that avoid the geofences but also reduce the intersection with the other agent trajectories. The navigation monitor triggers the path planner when requested by the task monitor (to perform a given action), but also handles the air traffic management internal to the fleet. It books airspace as segments of the trajectory as the agent progress over its trajectory. It allows to prevent collision by stopping one of the agents that would try to use or crossed an airspace already booked. The navigation monitor also verifies the validity of the trajectory during its execution. Indeed if the mission status changes in the knowledge base, due to the addition of a new geofence for instance, the navigation monitor may request a new trajectory. Finally the navigation monitor talks to the autopilot for the agent to perform the planned trajectory.

			=Contribution and Improvements=

			EZ_Chains architecture described above has been designed to allow UAVs to perform collaborative missions. The work carried out during C4D is twofold: (i) generalise the architecture to work with new components and demonstrate its genericity, (ii) extend it to support mort type of agents than just UAVs. The description in the previous section uses the notion of agent (instead of only UAV) to demonstrate that the concepts we use in the architecture actually extend to other types of agents, which demonstrates that the architecture is mostly ready for new types of agents at a formal level.

			In order to ease the work aimed at in C4D, we used the first and second year to integrate new missions and tasks for UAVs. Making the system capable of using a fleet of heterogeneous UAV. It allowed us to focus on realising the demonstration for the UC3 D1 (Logistics, dropping sensors). We aim at using the third year to work on integrating new types of agents and components.

			Integrating new types of missions, already required to define new types of agents in the knowledge base. We now have a hierarchy of agents, for instance we have UAV>Dropper, UAV>Surveillance and GCS. To support different agents, at different level of hierarchy, required to improve the internal structure, the relation between the mission status and the periodic updates sent by the agents.

			Once the knowledge base can support different types of agents, the task monitor must take it into account when following the mission progress before triggering the task planner. For instance, in the UC3 D1 demonstration, due to regulatory limitations, we had to ask the fleet to trigger a landing when the surveillance UAV declared its trajectory back to base due to low battery. New behaviour must be created when new hierarchies of agents are added. In the future we would like to add, weather stations as part of the system, they would also require the triggering of conservative actions when the weather becomes too bad.

			The task planner is improved to allow new mission decomposition, indeed each new agent has its own goal and types of actions it can achieve. For instance, again with the surveillance UAV, it required the definition of new goals called Point of Interest (POI), where the UAV had to go survey the area border and cycle though all those POI. The definition of those POI, a goal only corresponding to the surveillance UAV, had to be incorporated in the knowledge base. Additionally the task planner, for the surveillance UAV, could not reason with the strategy used by the droppers, it required to redefine how such a mission is completed.

Scalian: /* EZ_Chains Fleet Architecture */

2022-05-30T08:55:38Z

EZ_Chains Fleet Architecture

New page

=WP3-16 - EZ_Chains Fleet Architecture=
{|class="wikitable"
| ID|| WP3-16
|-
| Contributor || SCALIAN
|-
| Levels || Functional
|-
| Require || Interface with autopilot, communication link with other drones in fleet
|-
| Provide || Mission planning and monitoring for fleet missions, Flight planning and guidance taking into account the other UAVs
|-
| Input
|
* Mission status
* Periodic updates of other UAVs
* UAV position and attitude from autopilot
|-
| Output
|
* Mission updates
* Periodic updates on current UAV
* Commands to the autopilot
|-
| C4D building block || Mission Management, Flight Guidance, Flight Planning
|-
| TRL || 7
|}