Once this is known we translate the nodes towards the assigned slot in each step.
When you say "which nodes are rotationally reachable", what does that imply for formations? A node will be assigned a slot and has to move towards it while trying to avoid obstacles.
Happy to take a look if you file an issue on Ketu with details.
Here, position is essential, while SpinStep is orientational. Each node (e.g., drone) is assigned a target slot in space. Movement is needed — so SpinStep alone wouldn’t currently manage this. It might help decide orientation steps, but not positional navigation or collision avoidance.
Possibilities Going Forward:
We could extend SpinStep toward SE(3) traversal, or write a complementary module. That would involve:
-Pairing quaternions with positional vectors -- which is an awesome upgrade to the SpSt library.
-Defining a traversal condition based on both angular distance and spatial proximity.
-Possibly adding constraints (like occupied/available slots) and collision checks.
Such an approach could lead to a formation coordinator, where:
-Each drone is a node.
-Target positions + orientations define “goal nodes.”
-You route through “pose-space” rather than just physical space.
I'm a little swamped right now. In the days ahead i will be taking a closer look at how to integrate SpinStep with Ketu. It's gonna be fun.
All the best!
SpinStep is primarily a traversal framework, not a constraint solver. It operates on orientation-based logic, where each node has a quaternion, and traversal occurs by stepping into child nodes whose orientations fall within a defined angular threshold from the current orientation.
So instead of computing a path toward a goal state, SpinStep says: “Given my current rotation, which nearby nodes are rotationally reachable?” It’s useful when the orientation itself is the condition for progression, like in:
At the moment, it doesn’t compute transformation sequences to reach a goal state — i.e., it’s not a solver or planner. But I agree: the quaternion logic could be extended to track both rotational and translational progression, especially if you define formations as goal orientations + positions.I'd be happy to open an issue on Ketu with a concrete idea — possibly describing how formation transitions could be modeled as quaternion steps through orientation "nodes," - each drone is a node - and how that might be used to route coordination logic.
Thanks again for the openness.