Skip to main content
Planning lets you inspect a route before executing it. Complete Chapter 1 first. This chapter adds semantic search and authored coordinates to the saved-mission workflow. Download this guide as a notebook

1. Connect and localize

Start in a project folder with a GRID development session:
Keep that CLI process running. Use its workspace .venv Python environment (or select that kernel if you use the downloadable notebook). Run the snippets in order in one Python session. Set your registered robot name and use the numbered selectors. The robot must have navigation enabled.
Choose a completed map, start navigation, and check the viewer against the robot. Keep home for the return trip later in this guide.

2. Find a destination in the map

find() searches semantic objects already captured in the map. It does not inspect the live camera, resolve local editor waypoint names, or find a saved mission. Change the label to something present in your map.
Results are Waypoint objects in server order, not sorted by distance or confidence. An empty list is a valid outcome. Inspect the coordinates and choose the intended match instead of assuming the first one is right.

3. Plan and inspect

plan() uses the current localized pose as its start. It returns a Path without moving the robot. Select the match you inspected above.
path.waypoints are the requested or adjusted stops; path.route is the dense route between them. Planning may move a target to reachable free space, so inspect the returned coordinates as well as the target you supplied. You can also pass one map-frame (x, y) pair, a Waypoint, a list of targets, or a sparse Path. Passing a semantic string directly selects its first match. The type reference shows each accepted form.

4. Run the reviewed route

This next snippet moves the robot. If it has moved since planning, plan again: a dense route is validated and executed, not automatically rebuilt from a new start. Check the terminal result before continuing. This example uses blocking=True explicitly. It is also the default. The notebook cell stays busy until the mission ends. Another cell, including one containing nav.cancel_mission(), cannot run during that wait. To cancel, interrupt the running cell. The remote client requests cancellation; check that the physical robot stopped. Use the e-stop if stopping cannot be confirmed.
For a one-step operation, move_to(target) plans and drives immediately. Use the separate plan / run_mission steps when you need a review point.

5. Author several stops

Copy verified XY coordinates from the mission editor. Fill STOPS with (x, y) pairs in metres; do not copy coordinates from a different map. This produces a fresh plan and leaves execution to you.
After reviewing it, execute tour with the same guarded run_mission pattern above. A sparse Path contains stops; a dense Path also contains route. plan(existing_path) replans its waypoints from the current pose. Python Waypoint has no heading field today; use a saved editor mission for a final heading requirement. UI route optimization and clearance settings belong to the editor, not extra arguments to nav.plan().

6. Return to the starting location

Build a new route to the original XY position. This does not restore the original heading. Reversing an old dense route would assume the robot’s current position and the environment are unchanged.

7. Cancel, stop, or restart

Choose the operation that matches your intent. Do not run both just to cancel a mission. retain_localization means retain initialization data, not keep tracking the robot. Neither cancellation nor restart resumes the old mission. Read results before stop() clears the current run.

Cancel from a separate notebook cell

For this workflow, replace the blocking execution in step 4 with nav.run_mission(path, blocking=False) after the same route review and RUN prompt. Do not execute both versions. The start cell returns while the robot continues moving. Then a separate cell can request cancellation:
Check that mission_running becomes False and confirm the robot stopped. A cancellation request alone does not prove stopping. Do not start another mission while the current one is active. A slow sensor or network call can still keep the kernel busy and delay cancellation. Chapter 3 shows a complete non-blocking observation loop with cancellation cleanup.

Stop navigation and start it again

The blocking runs above have already ended before this example can run. Use this when you want to stop the navigation services, then initialize them again. It is not an emergency stop cell for an earlier blocking call.
To change maps use set_map(new_map_id) after start. That stops the active runtime and any mission, switches maps, and localizes again. Never reuse a path or coordinates from the previous map.

8. Finish

Shutdown releases the shared Nav instance and affects other clients attached to it. Collect results first, then release navigation before the borrowed robot. Run this cleanup even after an earlier step fails. If a connection failure prevents stopping motion, use the robot’s e-stop.
Next, observe while navigating or add per-mission recording and constraints.