PRE2017 3 Group 17 Test Cases: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
(Added explanations to the tests)
m (→‎Avoiding Obstacles and Actors: Putting examples in table)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Layout with nodes ==
== Layout with nodes ==
Below a couple of very basic initial test layouts can be found. These layouts are used to test the parser, the model and the UI.<br><br>
This page contains test cases and some examples of the model in action from [[:PRE2017 3 Group 17|Group 17]]
Test 1 is simple test to check the basics of loading in an environment and nodes.<br>
 
[[File:Test1.jpg]]<br><br>
 
The test below was created to test an edge-case scenario, where the end node is not reachable. This test also illustrates very well that it is not desired that the drone simply flies back. In this case it is usefull if the nearest node would become the target. How does the drone choose these target nodes, or does the user need to pick a reachable target node for the system.<br>
Below are a couple of very basic initial test layouts can be found. These layouts are used to test the parser, the model and the UI.<br><br>
[[File:Test2.jpg]]<br><br>
*Circles (or Nodes) represent the junctions in a building.<br>
A simple test to see if the optimal path was chosen.<br>
*Solid Circles (or solid Nodes) represent the beginning and end junction of the drone path.<br>
[[File:Test3.jpg]]<br><br>
*Solid lines between junctions (or Edges) represent the paths between junctions on the same floor.<br>
Another test to see if the optimal path was chosen.<br>
*Dashed lines between junctions (or dashed Edges) represent paths between junctions on a different floor. For instance, an elevator shaft or staircase.<br>
[[File:Test4.jpg]]<br><br>
*Other solid lines represent walls. In the case that an edge passes a wall, there is an opening in that wall with sufficient space for a drone to fly through. For instance, a door or large window.
A test to see if boundaries are respected. However, since the drones follow the nodes this test case has less relevance.<br>
 
[[File:Test5.jpg]]<br><br>
{|
A circular test case. Also a boundary case, depending on your implementation of an algorithm can get stuck on searching for the optimal path, since there are always combinations that cannot be scouted.<br>
|-
[[File:Test6.jpg]]<br><br>
| style="float: left;" | [[File:Test1.jpg|thumb|alt=Test1.|Testcase 1|upright=1.0|right|Test 1: Any Path]]
A very besic test case to make us think about difference in floors and how this will be implemented.<br>
| Test 1 is simple test to check the basics of loading in an environment and nodes. Any path without self-loops from the start to the goal will be the shortest path.
[[File:Test7.jpg]]<br><br>
|-
Also a test case with mulitple floors, however, this time there are multiple paths:
| style="float: left;" | [[File:Test2.jpg|thumb|alt=Test2.|Testcase 2|upright=1.0|right|Test 2: Unreachable]]
*Stays on the same level, but has more nodes
| The test below was created to test an edge-case scenario, where the end node is not reachable. This test also illustrates very well that it is not desired that the drone simply flies back. In this case it is useful if the nearest node would become the final destination. "How does the drone choose these new final destinations", or "does the user himself need to pick a new reachable final destination for the system" are interesting questions that can be considered in this case.
*Different level, but with less nodes
|-
This test case is made to make us think about how we want to handle different floors. Do we always require the absolute shortest flight path, or do we take energy into account? (since lifting a heavy object requires more force than keeping it on the same level<br>
| style="float: left;" | [[File:Test3.jpg|thumb|alt=Test3.|Testcase 3|upright=1.0|right|Test 3: Manhatten Distance]]
[[File:Test8.jpg]]
| A simple test to see if a path can be found. In this case the path length from the final node to the destination node is larger than the [[wikipedia:Taxicab_geometry|Manhattan Distance]] between these nodes.
|-
| style="float: left;" | [[File:Test4.jpg|thumb|alt=Test4.|Testcase 4|upright=1.0|right|Test 4: Manhatten Distance Hallway]]
| Similar to Test Case 3 in the sense that the path distance from start node to end node is larger than the Manhattan Distance. This time this scenario is applied to a larger and more realistic building: one with a hallway.
|-
| style="float: left;" | [[File:Test5.jpg|thumb|alt=Test5.|Testcase 5|upright=1.0|right|Test 5: Boundaries]]
| A test to see if boundaries are respected. However, since the drones follow the nodes this test case has less relevance.
|-
| style="float: left;" | [[File:Test6.jpg|thumb|alt=Test6.|Testcase 6|upright=1.0|right|Test 6: Circular Building]]
| An example of how a circular building consists of nodes. Also a boundary case; depending on an algorithm's implementation it can get stuck on searching for the optimal path, since there are always combinations that cannot be scouted.
|-
| style="float: left;" | [[File:Test7.jpg|thumb|alt=Test7.|Testcase 7|upright=1.0|right|Test 7: Multiple Floors]]
| A basic test case of how a path can be found on a building with multiple floors.
|-
| style="float: left;" | [[File:Test8.jpg|thumb|alt=Test8.|Testcase 8|upright=1.0|right|Test 8: Changing Floors]]
| Also a test case with mulitple floors, however, this time there are multiple paths:
*Stay on the same floor, but fly a longer path.
*Switch floors, but take a shorter path.
This test case is made to make us think about how we want to handle different floors. Do we always require the absolute shortest flight path, or do we take battery life into account, since lifting a heavy object requires more force than keeping it on the same floor.
|-
|}
 
== Avoiding Obstacles and Actors ==
The drones should avoid actors and other obstacles. In case they detect one, they will pass that information to the model and ask it an alternative path to fly.
These tests were performed in the [[:PRE2017 3 Group 17#Create_simulation|main test building]], rather than is multiple separate buildings as well. The main test building provided enough scenarios to test the drone-obstacle-human interaction and was already available once this testing-stage was reached, which is why smaller test cases like the ones above were not made for this part.
 
{|
|-
| [[File:17gifModel1.gif]]
| This is an example for how the simulation reacts to a "new" wall.
What you see is that once the wall is detected the transition is colored blue to show that this transition is permanently closed.
|-
| [[File:17gifModel2.gif]]
| This is an example for how the simulation reacts to a worker.
The transition is locked as shown by the green color but after a little while it times out and goes to black.
Once it is black another drone can go over them to check if it is clear.
|-
| [[File:17gifModel3.gif]]
| This is example of the model preferring to stay inside the building.
The red lines are transitions which are outside so the model would rather go inside even though the distance is longer.
|-
|}

Latest revision as of 15:55, 5 April 2018

Layout with nodes

This page contains test cases and some examples of the model in action from Group 17


Below are a couple of very basic initial test layouts can be found. These layouts are used to test the parser, the model and the UI.

  • Circles (or Nodes) represent the junctions in a building.
  • Solid Circles (or solid Nodes) represent the beginning and end junction of the drone path.
  • Solid lines between junctions (or Edges) represent the paths between junctions on the same floor.
  • Dashed lines between junctions (or dashed Edges) represent paths between junctions on a different floor. For instance, an elevator shaft or staircase.
  • Other solid lines represent walls. In the case that an edge passes a wall, there is an opening in that wall with sufficient space for a drone to fly through. For instance, a door or large window.
Test1.
Test 1: Any Path
Test 1 is simple test to check the basics of loading in an environment and nodes. Any path without self-loops from the start to the goal will be the shortest path.
Test2.
Test 2: Unreachable
The test below was created to test an edge-case scenario, where the end node is not reachable. This test also illustrates very well that it is not desired that the drone simply flies back. In this case it is useful if the nearest node would become the final destination. "How does the drone choose these new final destinations", or "does the user himself need to pick a new reachable final destination for the system" are interesting questions that can be considered in this case.
Test3.
Test 3: Manhatten Distance
A simple test to see if a path can be found. In this case the path length from the final node to the destination node is larger than the Manhattan Distance between these nodes.
Test4.
Test 4: Manhatten Distance Hallway
Similar to Test Case 3 in the sense that the path distance from start node to end node is larger than the Manhattan Distance. This time this scenario is applied to a larger and more realistic building: one with a hallway.
Test5.
Test 5: Boundaries
A test to see if boundaries are respected. However, since the drones follow the nodes this test case has less relevance.
Test6.
Test 6: Circular Building
An example of how a circular building consists of nodes. Also a boundary case; depending on an algorithm's implementation it can get stuck on searching for the optimal path, since there are always combinations that cannot be scouted.
Test7.
Test 7: Multiple Floors
A basic test case of how a path can be found on a building with multiple floors.
Test8.
Test 8: Changing Floors
Also a test case with mulitple floors, however, this time there are multiple paths:
  • Stay on the same floor, but fly a longer path.
  • Switch floors, but take a shorter path.

This test case is made to make us think about how we want to handle different floors. Do we always require the absolute shortest flight path, or do we take battery life into account, since lifting a heavy object requires more force than keeping it on the same floor.

Avoiding Obstacles and Actors

The drones should avoid actors and other obstacles. In case they detect one, they will pass that information to the model and ask it an alternative path to fly. These tests were performed in the main test building, rather than is multiple separate buildings as well. The main test building provided enough scenarios to test the drone-obstacle-human interaction and was already available once this testing-stage was reached, which is why smaller test cases like the ones above were not made for this part.

17gifModel1.gif This is an example for how the simulation reacts to a "new" wall.

What you see is that once the wall is detected the transition is colored blue to show that this transition is permanently closed.

17gifModel2.gif This is an example for how the simulation reacts to a worker.

The transition is locked as shown by the green color but after a little while it times out and goes to black. Once it is black another drone can go over them to check if it is clear.

17gifModel3.gif This is example of the model preferring to stay inside the building.

The red lines are transitions which are outside so the model would rather go inside even though the distance is longer.