Problem
KiteUtils.jl's API, docs, and Settings struct are kps3/kps4-specific, making it confusing for other AWE packages like SymbolicAWEModels.jl that depend on it.
Issues
-
Settings is a monolith — general fields (solver, environment, tether) are mixed with ~40 kps-specific ones (cs_4p, rel_nose_mass, h_bridle, kcu_model, etc.). No way to tell which fields matter for your model.
-
Docs and exports assume kps context — kps-specific exports (demo_state_4p, get_particles) are mixed with general ones. No separation in docs or export list.
-
Reference frames need unification — KiteUtils and SymbolicAWEModels use equivalent frames under different names:
- SE ≈ tether frame (should be changed to SE in SymbolicAWEModels)
- KS ≈ body frame (is this body enu frame vs body ned frame? rename to sensor frame, for if a sensor is not on the kite?)
- ENU ≈ world frame (should be changed to ENU in SymbolicAWEModels)
- Document the cad frame
The docs should mark kps-specific frames (NED/EX, EG, W) as such.
-
SysState extensibility — SymbolicAWEModels adds quite some states. It might be a good idea to make the SysState more modular.
Problem
KiteUtils.jl's API, docs, and Settings struct are kps3/kps4-specific, making it confusing for other AWE packages like SymbolicAWEModels.jl that depend on it.
Issues
Settings is a monolith — general fields (solver, environment, tether) are mixed with ~40 kps-specific ones (
cs_4p,rel_nose_mass,h_bridle,kcu_model, etc.). No way to tell which fields matter for your model.Docs and exports assume kps context — kps-specific exports (
demo_state_4p,get_particles) are mixed with general ones. No separation in docs or export list.Reference frames need unification — KiteUtils and SymbolicAWEModels use equivalent frames under different names:
The docs should mark kps-specific frames (NED/EX, EG, W) as such.
SysState extensibility — SymbolicAWEModels adds quite some states. It might be a good idea to make the SysState more modular.