Three-wire-kite

[ufechner7]

Is there any possibility to simulate a kite that has 3 wires going from the ground to the kite, so using three ground-based motors, instead of using a control pod in the air? If so, how could one implement this?

[ufechner7]

If you look at the file KPS4.jl you see:

# Array of connections of bridlepoints.
# First point, second point, unstressed length.
const SPRINGS_INPUT = [0.    1.  150.
                       1.    2.   -1. # s1, p7, p8
                       4.    2.   -1. # s2, p10, p8                        
                       4.    5.   -1. # s3, p10, p11
                       3.    4.   -1. # s4, p9, p10
                       5.    1.   -1. # s5, p11, p7
                       4.    1.   -1. # s6, p10, p7
                       3.    5.   -1. # s7, p9, p11
                       5.    2.   -1. # s8, p11, p8
                       2.    3.   -1.] # s9, p8, p9

You could create a copy of this file under a new name, like KPS_3wire.jl, and then change the array of connections to reflect your tether structure... But the kite control unit

"Reference to the KCU model (Kite Control Unit as implemented in the package KitePodModels"
    kcu::KCU = KCU()

would also need to be changed...

If you could provide a drawing of the line and bridle structure you are trying to simulate I could make further suggestions...

[1-Bart-1]

Kite Bridlesystem.pdf

This is the wire-bridle system. The three blocks are the three motors we are using.

[ufechner7]

Thanks for sharing!

I do not fully understand the last page of the pdf. What does "outside" mean? Is that a top view?

Furthermore, would it a valid simplification to assume all three winches are at the same location? Or are they mounted on a platform that can be turned? If so, which distance do the winches have?

[1-Bart-1]

A valid simplification would be that the winches are in the same location. The last page is a side view of the kite, where "outside" is the top surface of the kite, and you can see the red left steering line and the black middle line (you cannot see the blue right steering line as it would be behind the red line). But it looks like I made a mistake with the bridle system on the last page: the black middle line should split between the motor and the kite, as shown correctly on the front view of the kite. Here is an updated version: Kite.Bridlesystem.pdf

[1-Bart-1]

Do you have any guidelines on which parts of KPS4.jl I should change?

[ufechner7]

We should first agree on the name of the new model. What about KPS4_3L? If that is OK for you I can add such a file and class.

[ufechner7]

OK, I created a pull-request: https://github.com/ufechner7/KiteModels.jl/pull/50 As I said before, a new version of:

# Array of connections of bridle points.
# First point, second point, unstressed length.
const SPRINGS_INPUT = [0.    1.  150.
                       1.    2.   -1. # s1, p7, p8
                       4.    2.   -1. # s2, p10, p8                        
                       4.    5.   -1. # s3, p10, p11
                       3.    4.   -1. # s4, p9, p10
                       5.    1.   -1. # s5, p11, p7
                       4.    1.   -1. # s6, p10, p7
                       3.    5.   -1. # s7, p9, p11
                       5.    2.   -1. # s8, p11, p8
                       2.    3.   -1.] # s9, p8, p9

is needed...

Perhaps first a good drawing where all the points and lines have names. Names starting with s are segments, with p are points.

[1-Bart-1]

KPS4_3L sounds good. I will try to create such an image and the corresponding SPRINGS_INPUT.

[ufechner7]

In the branch 3line you can now find a minimal working example mwes/mwe_10.jl which initializes the model KPS4_3L. I did not change any code, though, but you can find the stuff that needs to be adapted:

• in init.jl all methods that work on KPS4_3L
• all the code in KPS4_3L.jl

But before doing that, have a look at the function get_particles in the package KiteUtils... Well, it might work just as it is now if we do not change the kite itself, just let the lines go to the ground instead of to the KCU.

But most likely some changes to KiteUtils are required, too, for the definition of the SystemState and the Logger, I will create an issue in that package...

[1-Bart-1]

For the 3-wire model, I want to implement the aerodynamics a bit differently: C, B and D will be in the middle of equal area parts of the kite, so that C and D are close to the center of pressure of these areas of the kite. The lift force will be perpendicular to the kite, and will therefore be a bit upwards. Does it look like a good idea?

[1-Bart-1]

Or maybe it would be better like this?