# Test5: Waypoints cycle test

###### tags: `Work` `ITRI`

## 1. Testing scenario original request from Ray

:::info
- Run 3 waypoints in a loop cycle script, and each point position can be modified through the UI parameters, not the script.

- MiR must make a direct detour if there is an obstacle between the first waypoint

- MiR must stop and wait for 3 seconds then make a detour, if there is an obstacle between the second waypoint

- MiR must stop and wait for the user command(detour or keep wait) until the obstacle go away, if there is an obstacle between the third waypoint

:::

## 2. Testing scenario ITRI acutally tried

### 2.1. Requirement and Goal

- **Requirement** : Assume that our customer may want to apply various obstacle avoidance policies in the experimental area.

- **Goal**: Technical Team should evaluate can it apply different obstacle avoidance policies in different route sections.<br>Is this possible or not?<br>If this is achievable, how to make it?


### 2.2. Flowchart of Test5


## 3. Testing Result

### 3.1. Short answer

:a: **<font color="#f00">NO</font>**, based on experiments, it requires a lot of efforts to achieve the goal by drawing many <font color="#0cf">restricted areas</font> on the map to limit the movement of AMR, restricted areas are to prevent AMR to generate detour path, for flexibility, **we should get "obstacle detected" event from MiR100 AMR instead of drawing restricted ares.** Therefore, I personally judge that program code customization is necessary.

### 3.2. Setup our mission
> step 1. set "planner zone" and the parameter "path deviation"(路徑偏差) of the "planner zone"

> step 1.a. draw planner zone

> step 1.b. set path deviation to "0"

> NOTE: planner zone setting parameters

> step 2. set the mission test5

**Setup the script in MiR UI**

**Psuedocode**

while(true) {
    while (true) {
        try {
            move_to_position("Test2_pos2");
            break;
        } catch {
            play_sound("sound_1", 5);
            mirlog(MIRLOG_ERR, "obstacles detected, detouring...");
        }
    }
    while (true) {
        try {
            move_to_position("Test4_pos1");
            break;
        } catch {
            play_sound("sound_1", 5);
            mirlog(MIRLOG_ERR, "obstacles detected, waiting 5 secs and then detour...");
            mir_wait(5);
        }
    }
    while (true) {
        try {
            move_to_position("Test4_pos2");
            break;
        } catch {
            play_sound("sound_1", 5);
            mirlog(MIRLOG_ERR, "obstacles detected, waiting 5 secs and then detour...");
            MIR_USER_RESPONSE_RESULT result;
            result = prompt_user("move and check");
            switch () {
                case MIR_USER_RESPONSE_OK:
                    continue;
                break;
                case MIR_USER_RESPONSE_NO:
                    mir_wait(5);
                    continue;
                break;
                default:
                    continue;
                break;
            }
        }
    }
}

promt_user example :


### 3.3 Conclusion

:::warning

try {
    move_to_position("Test4_pos1");
    break;
} catch {
    // ...
}

Based on the experiment, it can be inferred that the condition for ```try-catch``` to enter the ```catch``` sction is ***"unable to generate a new path."*** Therefore, there are only two ways to enter the ```catch``` section:

- 1. A person stands directly on the target position and prevents the MiR100-AMR from generating a new path to reach the target position.

- 2. Completely block the route leading to the target position, for example by using a giant obstacle.

The conclusion is that in order to design a ***script*** that is more suitable for testing scenarios, it is necessary to be able to receive the event **"<font color="#f00">obstacle detected</font>"**

:::