Implement the input functions for RamAirKite

[ufechner7]

The following functions are not yet defined for RamAirKite:

• set_depower_steering!(s::AKM, depower, steering)
• set_v_wind_ground!(s::AKM, height, v_wind_gnd=s.set.v_wind; upwind_dir=-pi/2)

[1-Bart-1]

set_depower_steering!(s::AKM, depower, steering)

I will implement this function based on:

depower = 0.5tether_length[2] + 0.5tether_length[3] - tether_length[1]
steering = tether_length[2] - tether_length[3]

[ufechner7]

Well, but depower must be between 0 and 1, and steering between -1 and 1.

So you need to divide these values by max_depower_length and max_steering_length or whatever names you want to choose for these (kite specific) parameters.

[1-Bart-1]

Please keep in mind that this cannot be used for actual control, as it directly sets the tether lengths, so it ignores the winch model. I can add a parameter in the mtk model that disables the winches when you use this function.

[1-Bart-1]

So you need to divide these values by max_depower_length and max_steering_length or whatever names you want to choose for these (kite specific) parameters.

I can normalize with the chord length of the kite.

[ufechner7]

Please keep in mind that this cannot be used for actual control, as it directly sets the tether lengths, so it ignores the winch model. I can add a parameter in the mtk model that disables the winches when you use this function.

    KitePodModels.on_timer(s.kcu)
    KiteModels.set_depower_steering!(s, get_depower(s.kcu), get_steering(s.kcu))

In the next_step! function, the KitePodModel calculates feasable values of actual depower and steering values, based on the set_depower and set_steering values that are inputs of the KitePodModel. We could do something similar for your model, and then it could be used for control.

[1-Bart-1]

I don't like that, because that would mean that a controller is used inside the KiteModels package. I would rather keep the control completely separate in a different package for better modularity. So I think set_depower_steering should be in the KiteControllers package if you need it there. I don't need it for my controller for example, so why should it be in KiteModels then?

[ufechner7]

that would mean that a controller is used inside the KiteModels package.

Not true. Currently, the controller for the KCU is in the KitePodModels.jl package. And I also have a controller in the WinchModels package to be able to use speed control for the force control winch. I agree, it is a trade-off.

WinchControl should happen in the WinchControllers package. If we add position control to the WinchControllers package, steering and depower control could easily be added to KiteModels, and most of the control would still stay in one of the controller packages.

[1-Bart-1]

I would prefer to add the steering and depower control to WinchControllers.jl. And use the next_step! function in KiteModels.jl with the model inputs, which are the set torques. Steering and depower are not model inputs, they are setpoints, which is an input for a controller.

[ufechner7]

Well, KiteModels could depend on WinchControllers, as it depends on KitePodModels (which actually include simple controllers). I find it more intuitive to test any of the models with set values for steering and depower instead of testing it with set points for the torques.
But to implement the two missing input functions of the model, no controller whatsoever is needed. Only if we want to call set_depower_steering!() from within the next_step!() function we would need a controller. But that should be a separate issue.

[1-Bart-1]

So what exactly do you expect set_depower_steering! to do?

[ufechner7]

Step one is to calculate these values correctly:

depower = 0.5tether_length[2] + 0.5tether_length[3] - tether_length[1]
steering = tether_length[2] - tether_length[3]

But we need to divide them by max_depower_length and max_steering_length. Shall I add these two parameters to the Setttings?