High-level design of behaviour tree

[chantalzhang]

Sub-issue to #37. Aim to have this completed by January 20th.

Create an initial high-level, visualized design of the behaviour tree for navigation task to present to the team for feedback before implementation. Since we do not have the handbook for 2026 yet we will first focus on very simple navigation (forward, backward, etc.).

The long-term goal being to replace the existing state machine for the Robosub AUV mission.

The goal for this sub-issue is to produce a clear diagram for simple navigation that the team can review and iterate on, and that can be translated into py_trees nodes later (or another library).

Acceptance Criteria

• A visual behaviour tree diagram on basic navigation is created that is readable and presentable
• Translations:
• X: Forward / Backward
• Y: Left / Right
• Z: Up / Down
• Rotations:
• Roll: rotation about X (tilt left/right)
• Pitch: rotation about Y (nose up/down)
• Yaw: rotation about Z (turning left/right)
• Design nodes must be translatable and implementable, using pytrees or other libraries

Implementation

Approach:

1. Review last year's task descriptions, leaving out 3.2.4 Task 3 - Drop a BRUVS (Bin) and 3.2.5 Task 4 - Tagging (Torpedoes) because the rest of it already ensure a lot of points at comp. This is only to familiarize with possible tasks for 2026 comp.
2. Design the basic navigation as listed above in the acceptance criteria.
3. We will design failure handling and timeouts for tasks in a later issue when we get the handbook. E.g. immediate surfacing if the battery is low or a leak has been detected via root-level Selectors, or if fail to finish task in x seconds, then move on to next task using a custom Decorator or a Fallback sequence. So we can explore these ideas and start brainstorming too.

I'll probably use excalidraw for this, we can use something like draw.ioonce we get the tasks out and want to draw a more complete behaviour tree

[chantalzhang]

v1

[chantalzhang]

Version 2 changed parallel to sequence. some thoughts as to why:
changed parallel to seuqnece because it’s a sequence because one thing clearly depends on the other: you only want to rotate if the yaw is actually wrong.
the yaw check is basically a gate, and if it says “yes this needs fixing” then you move on to the rotate action, which is exactly how a sequence works.
you still get continuous feedback because with memory set to false the condition is rechecked every tick, so if the yaw becomes fine or overshoots, the sequence stops the rotation immediately.
a parallel would mean both run no matter what, which doesn’t make sense here since rotation shouldn’t happen unless the condition is true