Very interesting. I’ve been working on a small library called SpinStep — it's a Python-based quaternion traversal framework that steps through trees based on orientation thresholds, rather than positional hierarchy. I designed it with spatial decision-making in mind, and while it's still early-stage, it might complement Ketu’s orientation handling or be interesting for modeling formation logic.
Totally open-ended — no expectations at all. Just thought I’d share it in case it aligns with any future ideas you’re exploring.
I like the idea. I"m not able to understand how quaternions alone
can be used to navigate through space without a position translation vector.
The uses cases in the docs for drone control and manipulating kinetic arms with multiple degrees of freedom look promising though.
What does SpinStep provide?
- Is it a traversal framework for quaternions?
- Or it is a constraint solver that computes a series of transformations to make each node in a scene comply with a final end state
If it can be used for translating nodes as well via quaternions I would be interested in implementing a formation coordinator for it.
If you have an idea of what quaternion transformation will help achieve in Ketu and what the end state looks like please do create an issue on the Repo.
I'll see if I can implement it using the concepts in SpinStep.
Please excuse the delayed reply. Thanks for the thoughtful question — really appreciate you taking a close look.
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:
Animation state machines
Scene graph logic
Robotics command routing
or potentially drone formations
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.
Formations in Ketu rely on knowing where nodes need to be placed and which slots in a formation are not filled.
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.
I wonder what would it take to have the decision-making code (planning/movement.cpp) be Lua, not C++. That would allow to experiment with algorithm variation very quickly, e.g. just updating a file with Lua code, without recompiling and restarting.
I don't have any experience with Lua but looking around I think it should be easy to load the formation coordinator / node implementations as Lua files that can be hot reloaded without re-compiling.
Very interesting. I’ve been working on a small library called SpinStep — it's a Python-based quaternion traversal framework that steps through trees based on orientation thresholds, rather than positional hierarchy. I designed it with spatial decision-making in mind, and while it's still early-stage, it might complement Ketu’s orientation handling or be interesting for modeling formation logic.
Totally open-ended — no expectations at all. Just thought I’d share it in case it aligns with any future ideas you’re exploring.
https://github.com/VoxleOne/SpinStep
I like the idea. I"m not able to understand how quaternions alone can be used to navigate through space without a position translation vector.
The uses cases in the docs for drone control and manipulating kinetic arms with multiple degrees of freedom look promising though.
What does SpinStep provide? - Is it a traversal framework for quaternions? - Or it is a constraint solver that computes a series of transformations to make each node in a scene comply with a final end state
If it can be used for translating nodes as well via quaternions I would be interested in implementing a formation coordinator for it.
If you have an idea of what quaternion transformation will help achieve in Ketu and what the end state looks like please do create an issue on the Repo. I'll see if I can implement it using the concepts in SpinStep.
Please excuse the delayed reply. Thanks for the thoughtful question — really appreciate you taking a close look.
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.
Formations in Ketu rely on knowing where nodes need to be placed and which slots in a formation are not filled.
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.
Cool!
One suggestion, your language can be more specific, I had a hard time figuring out what was going on. You know this will be for drone formations, so:
"Every simulation is modelled as a scenario. You can add multiple nodes to your world in a scenario."
A scenario is a single formation? or Multiple formations (with the transitions encapsulated)? Nodes are just drones?
I realize you might be adopting the language from some ROS framework, but for you specific situation you can make it so much easier to read!
Thanks, I updated the description in the README to make it more clear. Feel free to create an issue on the repo if anything is unclear!
I wonder what would it take to have the decision-making code (planning/movement.cpp) be Lua, not C++. That would allow to experiment with algorithm variation very quickly, e.g. just updating a file with Lua code, without recompiling and restarting.
I don't have any experience with Lua but looking around I think it should be easy to load the formation coordinator / node implementations as Lua files that can be hot reloaded without re-compiling.
Great suggestion! I've created an issue to keep track of this. https://github.com/sushrut141/ketu/issues/8
I will definitely look into this once Ketu gains more traction. REPLit like behaviour would help more people try things out.